Subject: [lamps] rfc7030 CSR clarification ideas

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Oct 2021 19:26:22 -0400

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Oct 2021 19:39:38 -0400

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

Russ

> On Oct 27, 2021, at 7:26 PM, Michael Richardson <[email-masked]> wrote:
>