Re: [lamps] strugling with CSRAttrs

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

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