Re: [lamps] struggling with CSRAttrs

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

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