[lamps] Questions on draft-ietf-lamps-rfc7030-csrattrs-01

[Esko Dijk <[e-mail]>]

Hi all,

Looking at the document draft-ietf-lamps-rfc7030-csrattrs-01 and my interpretation of CSR attributes so far I notice some differences.

For example we had used a CSR attributes response as in the example below:

SEQUENCE (5 elem)
  OBJECT IDENTIFIER 2.5.4.3 commonName (X.520 DN component)
  OBJECT IDENTIFIER 2.5.4.5 serialNumber (X.520 DN component)
  OBJECT IDENTIFIER 2.5.4.10 organizationName (X.520 DN component)
  OBJECT IDENTIFIER 1.2.840.10045.4.3.2 ecdsaWithSHA256 (ANSI X9.62 ECDSA algorithm with SHA256)
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
    SET (1 elem)
      OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic curve)

Hex: 30 30 06 03 55 04 03 06 03 55 04 05 06 03 55 04 0A 06 08 2A 86 48 CE 3D 04 03 02 30 15 06 07 2A 86 48 CE 3D 02 01 31 0A 06 08 2A 86 48 CE 3D 03 01 07

So this looks simple to me; a list of OIDs that the client must be including in its CSR (with its own specific value chosen by the client: it’s name, serial, etc.).
And one attribute is used to denote a (key,value) pair to specify the client must use a particular type of curve for ecPublicKey. So the ‘set’ here is size 1 which means only 1 choice is available for this value of the property 1.2.840.10045.2.1 .

Now we have the draft currently not mentioning even the above use of OIDs in the sequence, and saying the for the attribute the ‘type’ has to be 1.2.840.113549.1.9.14.
This is really hard to understand, coming from a background of above example use.

So the above example is incorrect according to draft-ietf-lamps-rfc7030-csrattrs-01?
Now I don’t want to redo all discussions that led to this draft but for someone who didn’t follow these discussions it is hard to see the logic in the outcome of it.  It does not clarify for me.  And so much more complex than I thought.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: [e-mail]