Re: [lamps] struggling with CSRAttrs

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

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
> 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})
> (or better, as in the original definition in 7030):
> values SET SIZE(1..MAX) OF ATTRIBUTE.&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
>>        :               '[e-mail]'
>>        :               'ample.com'
>>        :             }
>>        :           }
> This encoding of a SAN appears strange to me - which flavor of 
> GeneralName are you aiming at?
>
>>        :         }
>>        :       }
>>        :     }
>>        :   }
>
> - David