Clarification of RFC7030 CSR Attributes definition

2.1. Current EST Specification

The ASN.1 for CSR Attributes as defined in EST section 4.5.2 is:¶

   CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

That section also states the following:¶

   the values indicating the particular
   attributes desired to be included in the resulting certificate's
   extensions

This has been interpreted by some implementations as meaning that the CSR Attributes response can only include values for the attribute OIDs that the client should include in its CSR, and cannot include the actual values of those attributes. This is further reinforced by the example:¶

   Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
                      value = macAddress (1.3.6.1.1.1.1.22)

This example illustrates that the 'value' specified is an attribute OID, for example the macAddress OID, and not the value (such as "10-00-00-12-23-45") of the attribute itself.¶

There is no clearly documented mechanism with supporting examples that specifies how a CSR Attributes response can include a value for a given attribute such as SubjectAltName.¶

EST section 4.5.2 also states the following:¶

   The structure of the CSR Attributes Response SHOULD, to the
   greatest extent possible, reflect the structure of the CSR
   it is requesting.

This statement aligns closely with the goal of this document. Additionally, EST Extensions [RFC8295] Appendix A has an informative appendix that outlines how a full CSR can be included in the CSR Attributes response.¶

3.1. Option two: Extend CSR structure to allow values:

This ASN.1 needs fixing.¶

   CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER,
                         attribute Attribute,
                         value Value }

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        extType  ATTRIBUTE.&id({IOSet}),
        extAttr  SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
   }

   Value { ATTRIBUTE:IOSet } ::= SEQUENCE {
        extType  ATTRIBUTE.&id({IOSet}),
        type     ATTRIBUTE.&Type({IOSet}{@type}),
        value    OCTET STRING
   }

This would just add a value to the SEQUENCE:¶

     OBJECT challengePassword
     SEQUENCE
       OBJECT subjectAltName
       SET
         OBJECT someACPgoo
     SEQUENCE
       OBJECT id-ecPublicKey
       SET
         OBJECT secp384r1
         OBJECT ecdsa-with-SHA384

For example:¶

  0  30: SEQUENCE {
  2  28:   SEQUENCE {
  4   3:     OBJECT IDENTIFIER subjectAltName (2 5 29 17)
  9  21:     SET {
 11  19:       [1] {
 13  17:         UTF8String 'hello@example.com'
       :         }
       :       }
       :     }
       :   }

3.2. Option three: explicit content for the key specification

The following options support complete and unambiguous specification of¶

• CSR ingredients optionally including values to use,¶
• the type of the public key, which is given in the form of a public-key algorithm,¶
• and the hash algorithm to use for the self-signature.¶

CSR ingredients may be the subject DN, any X.509 extensions, and special attributes like a challenge password.¶

For specifying the type of keys allowed in CSRs, they use a to-the-point KeySpec type. It can be defined for instance as¶

   KeySpec ::= CHOICE {
                   keyAlg AlgorithmIdentifier,
                   rsaKeyLen INTEGER
   }

The keyAlg type use used to specify public-key alorithms and can include parameters, such as the name of an elliptic curve. The rsaKeyLen choice allows specifying the size of RSA keys, which it is not possible using values of type AlgorithmIdentifier.¶

The keySpec could also be sequence of such specs, such that the server can give several key types from which the client can choose, e.g., EC keys on certain curves and/or RSA keys of certain sizes.¶

Stick for syntactic backward compatibility with¶

    CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

Each OID given in AttrOrOID must occur only once.¶

Plain OIDs are used mostly for challengePassword.¶

Attributes are used mostly for any X.509 extensions, subject DN, key spec, and hash alg, while defining new generally usable OIDs for¶

• a subject DN of type Name¶
• a key spec of type KeySpec¶
• a hash alg spec of type AlgorithmIdentifier¶

to be given on demand as attribute IDs of type ATTRIBUTE.&id({IOSet}).¶

3.3. Option four: explicit members for unique attributes

Define a new and more to-the-point type, which does not require new OIDs:¶

   CsrAttrs ::= SEQUENCE {
        oids      SEQUENCE OF OBJECT IDENTIFIER,
        attrs     SEQUENCE OF Attribute,
        subject   [0] Name OPTIONAL,
        keySpec   [1] KeySpec OPTIONAL,
        hashAlg   [2] AlgorithmIdentifier OPTIONAL

   }

Each OID given in oids or attrs must occur only once.¶

The oids are used mostly for requiring a challenge password.¶

The atttrs are used mostly for requiring certain X.509 extensions.¶

This is, typically just challengePassword and extensionRequest are used.¶

3.4. Option five: more specific structure, simpler extensions

Define a new fully to-the-point type, which does not require any (direct) OIDs:¶

   CsrAttrs ::= SEQUENCE {
        subject               Name OPTIONAL,
        extensions            SEQUENCE OF Extension,
        challengePassword     BOOLEAN,
        keySpec           [0] KeySpec OPTIONAL,
        hashAlg           [1] AlgorithmIdentifier OPTIONAL

   }

4.1. Use a new MIME type

The client can signal that it supports the new attribute format by using an Accept: header in the transaction. This acts as a signal to a server that it can/should return the attributes in the new format.¶

4.2. Use a new end point of the new format

Clients that want to use the new format would use a new end point, such as "csrvalues" which would only support the new format. A client which supported both would have to try both "csrvalues" and then fall back "csrattrs" if the EST server did not support the new format. Some uses (such as [RFC8994]) require the new format, so if it was not suppored, that would be a protocol error.¶

4.3. Insist new format is upwardly compatible with old format

ASN.1 encoding is self-describing, and some formats proposed above could possibly be parsed by legacy clients without a problem.¶

4.4. Return new format to new clients only

The Registrar may know which clients are which by the kind of authentication that they do. An [RFC8994] client which has just performed a [RFC8995] enrollment would be assumed to require the new format only. A client which authenticates with an LDevID for a renewal would be strongly identified, and the Registrar could be programmed whether to return new format, or legacy CSR attributes.¶

6.1. RFC8994/ACP subjectAltName with specific otherName included

TBD¶

6.2. EST server requires public keys of a specific size

TBD¶

6.3. EST server requires a public key of a specific algorithm/curve

TBD¶

6.4. EST server requires a specific extension to be present

TBD¶

7.1. Identity and Privacy Considerations

An EST server may use this mechanism to instruct the EST client about the identities it should include in the CSR it sends as part of enrollment. The client may only be aware of its IDevID Subject, which includes a manufacturer serial number. The EST server can use this mechanism to tell the client to include a specific fully qualified domain name in the CSR in order to complete domain ownership proofs required by the CA. Additionally, the EST server may deem the manufacturer serial number in an IDevID as personally identifiable information, and may want to specify a new random opaque identifier that the pledge should use in its CSR. This may be desirable if the CA and EST server have different operators.¶