Re: [lamps] struggling with CSRAttrs

[David von Oheimb <[e-mail]>]

Russ, Corey,

On 02.08.22 15:24, Russ Housley wrote:
>
>> 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.
>>
> Those all make sense to me.

thanks for your confirmation.


> Recall that the syntax for Extension is:
>
> 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
>    }
>
> I suggest an additional bullet:
>
>  * An extnID object identifier MUST appear at most once in 
> the extensionRequest attribute.

Good point, added.

Even if for instance multiple SANs need to be given, this can be 
accommodated easily, e.g.,

551  72:         SEQUENCE {
553   3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
558  65:           OCTET STRING, encapsulates {
560  63:             SEQUENCE {
562  12:               [2] 'www.good.org'
576  12:               [2] 'any.good.com'
590  13:               [1] '[e-mail]'
605  12:               [1] '[e-mail]'
619   4:               [7] C0 A8 00 01
        :               }
        :             }
        :           }


On 02.08.22 15:10, Corey Bonnell wrote:
>
> 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'
>               }
>             }
>           }
>
[...]
>
> 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'
>               }
>             }
>           }
>
Right, thanks. I had already questioned Michael's original example in 
this regard:

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

but did not check thoroughly so far.
Fixed the example in the repo accordingly.

Cheers,

     David


> *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({IOSet}{@type
>     <mailto:%7bIOSet%7d%7b@type>})
>
>     (or better, as in the original definition in 7030):
>
>     values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type
>     <mailto:%7bIOSet%7d%7b@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 "}") is likely superfluous/wrong here.
>
>          20   1:           BOOLEAN TRUE
>
>                :           }
>
>          23  61:         SEQUENCE {
>
>          25  59:           [0] {
>
>          27  57:             UTF8String
>
>                :              
>         '[e-mail]
>         <mailto:[e-mail]>'
>
>                :               'ample.com'
>
>                :             }
>
>                :           }
>
>     This encoding of a SAN appears strange to me - which flavor of
>     GeneralName are you aiming at?
>
>                :         }
>
>                :       }
>
>                :     }
>
>                :   }
>
>     - David
>