[lamps] rfc7030 CSR clarification ideas

[Michael Richardson <[e-mail]>]

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