Re: [lamps] is the CSRattr ASN.1 broken or not ... Re: New Version Notification for draft-richardson-lamps-rfc7030-csrattrs-02.txt

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

On Tue, 2022-04-05 at 14:18 -0400, Michael Richardson wrote:
> 
>     >> b) We picked the wrong kind attribute to request macAddress
> from the
>     >> client. I cannot remember if it’s supposed to be naming
> component or
>     >> an actual extension?
> 
>     > Apart from the two possibilities I just gave, I do not see how
> else,
>     > given given the CsrAttrs syntax,
>     > one should have requested a macAddress X.509 extension where the
> value
>     > is to be filled by the client.
> 
> It's a good question.
> I liked the notion that it's an empty content, but then... is an empty
> content ever valid?

I'd say yes, in the following sense: 
It's syntactically valid, and semantically it makes clear that the
server did not provide a value, 
which conveys the requirement that the value shall be filled in by the
client.

Here is a new thought, an alternative way of giving in a clean way both
the option to provide X.509 extensions with values and others without
values:

Have two OIDs for attribute types requiring the inclusion of X.509
extensions,
* one (likely) being extensionRequest (1.2.840.113549.1.9.14) and
* a second one that likely needs to be newly defined.

One of these two OIDs would be followed by a structure of the existing
type Extension (which contains the actual extension value) to be
included in the CSR, 
and the other one would be followed just by an OID stating the type of
an X.509 extension to be included in the CSR, with the client filling in
its value.

Also this solution does not require changes to the CsrAttrs type
declaration given in RFC 7030.

 David