Subject: An alternative ASN.1 format

From: Pekka Nikander <[email-masked]>
Date: Tue, 10 Jun 2003 10:23:08 +0300

We are now implementing the CGA draft, and we had
a brief off-line discussion with Tuomas about some
details on the ASN.1 encoding.  Basically, we would
like to have the beginning of the ASN.1 DER encoding
to be fixed, making it easier to handle the most
common case.

Basically, the following modifications would be needed:

   1. In the CGA draft, have the auxParameters first and
      the public key only after that:

                CGAParameters ::= SEQUENCE {
                  auxParameters  CGAAuxParameters,
                  publicKey      SubjectPublicKeyInfo }

                CGAAuxParameters ::= SEQUENCE {
                  modifier       OCTET STRING (SIZE 12),
                  routingPrefix  OCTET STRING (SIZE 8),
                  collisionCount INTEGER (0..2) }

   2. Define a fixed value for the actual public key algorithm
      used, taking pcks-1 from RFC3279, and defining that there
      MUST NOT be any parameters.

   3. Define that the RSA key MUST be at least 1024 bits
      long, basically making sure that the corresponding
      ASN.1 DER encoding always exceeds 127 bytes, requiring
      the "long" length DER format.

   4. Change the main draft accordingly.

Opening up the ASN.1 encoding gives the following
data structure:

    SEQUENCE {                          // SendKeyInformation
       SEQUENCE {                       // CGAParameters
          SEQUENCE {                    // auxParameters
             OCTET STRING (SIZE 12),    // modifier
             OCTET STRING (SIZE 8),     // routingPrefix
             INTEGER (0..2)             // collisionCount
          } OPTIONAL,
          SEQUENCE {                    // publicKey
            SEQUENCE {                  // algorithmIdentifier
              OBJECT IDENTIFIER,        // algorithm
              ANY OPTIONAL,             // parameters
            },
            BITSTRING                   // subjectPublicKey
          }
       } OPTIONAL,
       SEQUENCE {                       // signerInfo
         SEQUENCE {                     // algorithmIdentifier
            OBJECT IDENTIFIER,          // algorithm
            ANY OPTIONAL,               // parameters
         },
         BITSTRING                      // subjectPublicKey
       } OPTIONAL
    }

Assuming these changes, we got the following binary format.
This is fairly easy to implement, and also recognize
if the format does not match the expected one, and kick
such things to the user level.

30 82 LL LL                                        // SendKeyInformation
    30 82 LL LL                                     // CGAParameters
       30 1b                                        // auxParameters
          06 0c MM MM MM MM MM MM MM MM MM MM MM MM // modifier
          06 08 RR RR RR RR RR RR RR RR             // routingPrefix
          02 01 CC                                  // collisionCount
       30 82 LL LL                                  // publicKey
          30 0b                                     // algorithmId
             06 09                                  // algorithm
                   2a 86 48 86 f7 0d 01 01 01       // RSA
                                                    // NO parameters
          03 82 LL LL                               // subjectPublicKey
             PK PK PK PK ..... PK PK PK             // Bit string

--Pekka Nikander

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Jun 2003 22:21:05 +0300

>                  collisionCount INTEGER (0..2) }

Ok.

>      MUST NOT be any parameters.

Ok.

>      the "long" length DER format.

I'm very much in favor of a simplified format. But I'd like
to understand the 1024 bit requirement better. Does that mean
that the key has to have 1024 significant bits, or are upper
zero bits allowed? Would there be situations where we'd like
to have e.g. RFC 3041 addresses that use a short RSA key?
Or is 1024 already short enough?

--Jari