Re: [lamps] struggling with CSRAttrs

[Corey Bonnell <[e-mail]>]

Hi David,

One comment on the encoding of the subjectAltName, copied below:

 

SEQUENCE {
          OBJECT IDENTIFIER subjectAltName (2 5 29 17)
          [0] {
            BOOLEAN TRUE
            }
          OCTET STRING, encapsulates {
            SEQUENCE {
              [2] 'domain.example'
              }
            }
          }



I don’t think the critical BOOLEAN should be tagged above. RFC 5280, section 4.1 [1] defines Extension as:

 

Extension  ::=  SEQUENCE  {

        extnID      OBJECT IDENTIFIER,

        critical    BOOLEAN DEFAULT FALSE,

        extnValue   OCTET STRING

                    -- contains the DER encoding of an ASN.1 value

                    -- corresponding to the extension type identified

                    -- by extnID

        }

 

Given this ASN.1 definition, I believe the correct encoding of the subjectAltName would be:

 

SEQUENCE {
          OBJECT IDENTIFIER subjectAltName (2 5 29 17)
          BOOLEAN TRUE
          OCTET STRING, encapsulates {
            SEQUENCE {
              [2] 'domain.example'
              }
            }
          }



Thanks,

Corey

 

[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.1

 

From: Spasm <[e-mail]> On Behalf Of David von Oheimb
Sent: Tuesday, August 2, 2022 6:45 AM
To: Michael Richardson <[e-mail]>
Cc: LAMPS WG <[e-mail]>
Subject: Re: [lamps] struggling with CSRAttrs

 

Here are further things to clarify, which I happened to come across yesterday
when tweaking the OpenSSL implementation <https://github.com/openssl/openssl/pull/18931>  of X.509 extensions in PKCS#10 CSRs (and certs).

It is common practice for PKCS#10 objects to contain just one X.509 extension attribute with a single set element,
although this appears not explicitly required by RFC 2986 <https://www.rfc-editor.org/rfc/rfc2986>  (at least I did not find this there),
and the value of this attribute is a sequence of actual extensions: 

        Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

defined in RFC 5280 section 4.1 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.1> , which also makes clear that X.509 certs can bear only one such list:

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        ...
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

As mentioned on July 19 (see other email below), the CsrAttrs syntax gives quite some needless

freedom how to represent multiple X.509 extensions (and potentially other types of attributes).

 

I believe we should clarify that 

*	There MUST be at most one attribute describing X.509 extensions,
i.e., one bearing the OID extensionRequest (1.2.840.113549.1.9.14) as its type.
*	The set in such an X.509 extension value MUST contain exactly one element.
*	The value of such an attribute MUST be of type Extensions, i.e., a sequence of Extension.

In this light, I've just updated the example to reflect the type SEQUENCE OF Extension
and extended it with two (non-critical) extensions to make it more general/educative:

SEQUENCE {
  SEQUENCE {
    OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14)
    SET {
      SEQUENCE {
        SEQUENCE {
          OBJECT IDENTIFIER basicConstraints (2 5 29 19)
          OCTET STRING, encapsulates {
            SEQUENCE {}
            }
          }
        SEQUENCE {
          OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
          OCTET STRING, encapsulates {
           SEQUENCE {
              OBJECT IDENTIFIER serverAuth (1 3 6 1 5 5 7 3 1)
             }
            }
          }
        SEQUENCE {
          OBJECT IDENTIFIER subjectAltName (2 5 29 17)
          [0] {
            BOOLEAN TRUE
            }
          OCTET STRING, encapsulates {
            SEQUENCE {
              [2] 'domain.example'
              }
            }
          }
        }
      }
    }
  }

Moreover, we might specify what an empty list of X.509 extensions means,
such as to express that no X.509 extensions should/must be used in the CSR.

 

    David

 

 

On 31.07.22 19:40, David von Oheimb wrote:

Hi Michael et al.

On 29.07.22 20:45, Michael Richardson wrote: 

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

Well, this definition is semantically identical to the original one.
So better not rename the two fields of the Attribute structure, i.e., we
should stick with 'type' and 'values',
in particular since there may be attributes that are not X.509
extensions.

I found it clearer, but if you object to this rename, then I'll go with your preference.

Let's keep the original field names.
Also because this underlines the important fact that we do not change the ASN.1 syntax at all,
which is critical for bits-on-the-wire compatibility, but we just clarify its use and interpretation.

I've just made a pass on lamps-rfc7030-csrattrs.mkd in the GitHub repository.
Its new version contains various suggestions for improvements here and there.
Also updated the subjectAltName example to be of the more usual form of a dNSName
and inserted two questions/remarks:

   (TODO: Do we want to allow an empty extnValue (which is of type OCTET
   STRING), which would mean that the client is told to include an X.509
   extension of the given type and fill in the concrete value itself?)

   (TODO: Note that this mechanism does not support telling the client
   to include in the CSR a specific subject DN, simply because there is
   no OID for this.  I think we should better make this clear, or we
   have to define such an OID if setting a subject name should be
   supported.)

I also corrected the spelling of my (co-author's) name in presentations/ietf114-lamps-csrattrs.{fodp,pdf}.

    David

 


On Tue, 2022-07-19 at 20:58 +0200, David von Oheimb wrote:

Hi Michael, Sean, et al.,

 

on Sun, 2022-07-10 at 22:18 -0400, Michael Richardson wrote:

 

Sean, sorry to be asking this with less than 24h to ID cut-off.

I didn't want to post an updated ID until I had example code that produced

what I *thought* you are suggesting.  Moving a SEQ/SET around isn't that

hard... only now I've confused myself.

 

We had:

 

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

 

   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER,

                         attribute Attribute }

 

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {

        extType  ATTRIBUTE.&id({IOSet}),

        extAttr  SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})

   }

 

Well, this definition is semantically identical to the original one.
So better not rename the two fields of the Attribute structure, i.e., we should stick with 'type' and 'values',
in particular since there may be attributes that are not X.509 extensions.


According to  <https://datatracker.ietf.org/doc/html/draft-richardson-lamps-rfc7030-csrattrs> https://datatracker.ietf.org/doc/html/draft-richardson-lamps-rfc7030-csrattrs
the only thing that is "changed" is the clarification that the attributes may contain entire X.509 extensions.

So BTW I believe we can and should claim that this is bit-on-the wire compatible with RFC 7030.

 

 

with the understanding that extAttr could be a SET of Extensions.

 

Better also state that in this case the type/extType field MUST bear the value extensionRequest (1.2.840.113549.1.9.14).

 

 

Each Extension is given by:

 

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

 

The Extensions structure is only needed within certificates (where there is just one extensions field).
All needed here is the Extension structure - there are already more than enough of those sequences and sets around 

 

   Extension  ::=  SEQUENCE  {

        extnID      OBJECT IDENTIFIER,

        critical    BOOLEAN DEFAULT FALSE,

        extnValue   OCTET STRING

                    -- contains the DER encoding of an ASN.1 value

                    -- corresponding to the extension type identified

                    -- by extnID

        }

 

 

1) I'm not sure why I need a SET of a Sequence, unless your intent was that

   extAttr could be an *Extension* ??  I'm gonna go with yes here, but I

   didn't code that yet.

 

In my view, the set-valued 

 

               extAttr SET SIZE(1..MAX) OF ATTRIBUTE.&Type( <mailto:%7bIOSet%7d%7b@type> {IOSet}{@type})

(or better, as in the original definition in 7030):

               values SET SIZE(1..MAX) OF ATTRIBUTE.&Type( <mailto:%7bIOSet%7d%7b@type> {IOSet}{@type})

 

is not really needed because multiple attributes can be given anyway using multiple attributes, and each of them may then have a different type.
If multiple values are given as a set within a single attribute, all its elements must have the same type.
So in practice I suppose that for all attributes the SETs given within each of them usually will have just one value element.

 

 

2) I think that extnID would be things like subjectAltName,

   i.e. OID: 2.5.29.17

 

Right.

 

 

But, if so, what is extType for this?

 

The (ext)type is needed to provide the information, using "extensionRequest", that an X.509 extension is being given in this attribute.

 

 

 

ASN1 that I have right now, where I've put subjectAltName in twice:

 

obiwan-[projects/pandora/fountain](2.6.6) mcr 10396 %dumpasn1 tmp/csr_bulb1.der

  0  84: SEQUENCE {

  2  82:   SEQUENCE {

  4   3:     OBJECT IDENTIFIER subjectAltName (2 5 29 17)  <--- WHAT GOE, uS HERE?

Replace this by                         extensionRequest (1.2.840.113549.1.9.14)

 

 

  9  75:     SET {

 11  73:       SEQUENCE {   <--- SEQUENCE here might be undesired.

SEQUENCE here is fine, as demanded by the Extension structure.

 

 13   3:         OBJECT IDENTIFIER subjectAltName (2 5 29 17)

 18   3:         [0] {

The "[0] {" (and the closing 2}") is likely superfluous/wrong here.

 20   1:           BOOLEAN TRUE

       :           }

 23  61:         SEQUENCE {

 25  59:           [0] {

 27  57:             UTF8String

       :               ' <mailto:[e-mail]> [e-mail]'

       :               'ample.com'

       :             }

       :           }

This encoding of a SAN appears strange to me - which flavor of GeneralName are you aiming at?

 

       :         }

       :       }

       :     }

       :   }

 

- David