Re: [lamps] rfc7030 CSR clarification ideas

[Russ Housley <[e-mail]>]

GeneralName is very flexible, and it is extendible through OtherName.

Russ

> On Oct 27, 2021, at 7:26 PM, Michael Richardson <[e-mail]> wrote:
> 
> Subsequent to posting draft-richardson-lamps-rfc7030-csrattrs-01 on Monday,
> David has clarified a few options with commit:
>  https://github.com/mcr/lamps-rfc7030-csrattrs/commit/01f6949b880dd6269d5e886113486d056a42ebc1
> 
> in a number of the proposals, an explicit "Name" field is included in the attributes.
> 
> My understanding from RFC5280, is that the SubjectAltName is an extension and
> it is not contained with a "Name" object.  In particular, section 4.2.1.6 of
> RFC5280 says:
> 
> 
>   GeneralName ::= CHOICE {
>        otherName                       [0]     OtherName,
>        rfc822Name                      [1]     IA5String,
>        dNSName                         [2]     IA5String,
>        x400Address                     [3]     ORAddress,
>        directoryName                   [4]     Name,
> 
> so in fact a "Name" is allowed inside a SubjectAltName, and not the other way
> around.
> 
> Pretty much all of the cases where we think that a Registrar needs to specify
> a name to the client, it's some kind of SubjectAltName.  Often rfc822Name
> or otherName (in the case of RFC8994/ACP).
> 
> So I think that we could consider all the options that David and others have
> proposed, if we included a GeneralName rather than a Name?
> 
> Are there use cases (particularly given draft-ietf-uta-rfc6125bis-03 aka
> draft-ietf-uta-use-san aka draft-rsalz-use-san) where we actually will need
> to specify the SubjectDN... GOING FORWARD?
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
>