[lamps] Fixed the RFC 8994 / ACP Subject Alternative Name example - Re: struggling with CSRAttrs

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

Hi Corey et al.,

many thanks for helping us getting the ACP SAN example right.

On 04.08.22 15:20, Corey Bonnell wrote:
>
> Hi David,
>
> > (BTW, there is an erroneous self-reference to Section 6.2.2 within 
> itself.)
> > In this section I miss a definition which OID(s) to use for 
> acp-node-name etc.
>
> The errant section number reference should be 6.2.2.1 [1] (one of us 
> should file an errata on this),
>
> [1] https://datatracker.ietf.org/doc/html/rfc8994#section-6.2.2.1
>
Nice that you filed this erratum right away: 
https://www.rfc-editor.org/errata/eid7071


> which defines “id-on-AcpNodeName” as:
>
> id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
>
> …
>
> id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on 10 }
>
> AcpNodeName ::= IA5String (SIZE (1..MAX))
>
> -- AcpNodeName as specified in this document carries the
>
> -- acp-node-name as specified in the ABNF in Section 6.2.2 
> <https://datatracker.ietf.org/doc/html/rfc8994#section-6.2.2>
>
> Given this definition of the value type, the example will also need to 
> be updated to use IA5String instead of UTF8String.
>
Ah, now I found it in in RFC 8994, too, and corrected the ACP SAN 
example as follows.

               [0] {
                 OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 10'
                 [0] {
                   IA5String
             'fd89b714f3db00000200000064000000+area51.research'
             '@acp.example.com'
                   }
                 }

I've added to our repo a little script and config using OpenSSL for 
producing the extended and corrected example ASN.1 encoding:

openssl req -config csr.cnf -reqexts req_extensions -new \
-key <(openssl ecparam -genkey -name prime256v1) -subj /CN=test -out 
csr.pem
echo -e "\nExample CSR including extensionRequest attribute in text form:\n"
openssl req -in csr.pem -noout -text
openssl req -in csr.pem -outform der -out csr.der
echo -e "\nExample CSR including extensionRequest attribute in ASN.1 DER 
form:\n"
dumpasn1 csr.der

with this csr.cnf:

[req_extensions]
basicConstraints = CA:FALSE
extendedKeyUsage = serverAuth
subjectAltName = critical, @alt_names

[alt_names]
otherName = 
1.3.6.1.5.5.7.8.10;IA5String:[e-mail]
DNS.0 = domain.example


Side note:
Now I wonder why the rather uncommon and cumbersome otherName choice has 
been taken for ACP.
Looks like implementation support for otherNames is not the best.
Since an IA5String should be used for ACP that looks like an email address,
one might have chosen instead the simpler and well supported GeneralName 
choice 'rfc822name':

    GeneralName ::= CHOICE {
         otherName                       [0]     OtherName,
         rfc822Name                      [1]     IA5String,
         dNSName                         [2]     IA5String,
         x400Address                     [3]     ORAddress,
         directoryName                   [4]     Name,
         ediPartyName                    [5]     EDIPartyName,
         uniformResourceIdentifier       [6]     IA5String,
         iPAddress                       [7]     OCTET STRING,
         registeredID                    [8]     OBJECT IDENTIFIER }


> As a more general note, I highly recommend using Russ’s excellent 
> pyasn1-alt-modules package as a reference for ASN.1 definitions when 
> it’s difficult to find them in RFC prose: 
> https://github.com/russhousley/pyasn1-alt-modules/blob/master/pyasn1_alt_modules/rfc8994.py#L34
>
Really very helpful!
One can simply replace the RFC number to get the declarations also for 
other RFCs.

Cheers,

     David



> *From:* Spasm <[e-mail]> *On Behalf Of *David von Oheimb
> *Sent:* Thursday, August 4, 2022 8:31 AM
> *To:* Michael Richardson <[e-mail]>
> *Cc:* LAMPS WG <[e-mail]>
> *Subject:* Re: [lamps] struggling with CSRAttrs
>
> On 03.08.22 22:14, Michael Richardson wrote:
>
>     David von Oheimb<[e-mail]>  <mailto:[e-mail]>  wrote:
>
>          > 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'm okay with that.
>
> Glad to hear.
>
>          > 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:
>
>     Why did you change the RFC8994/ACP example from a real acp example name to domain.example?
>
> I did so because I did not pay attention that this SAN example had 
> special relevance,
> but also because its ASN.1 encoding was flawed:
>
>  31 59:           [0] {
>  33  57:             UTF8String
>        :               '[e-mail]'
>        :               'ample.com'
>        :             }
>
> and because the dNSName variant is much more common.
>
> So I've just re-added the otherName variant, while correcting its 
> ASN.1 encoding
> and keeping the other SAN that I had added, with a dNSName value:
>
> SEQUENCE {
>           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
>           BOOLEAN TRUE
>           OCTET STRING, encapsulates {
>             SEQUENCE {
>               [0] {
>                 OBJECT IDENTIFIER '??? TODO'
>                 [0] {
>                   UTF8String 'fd89b714f3db00000200000064000000'
> '[e-mail]'
>                   }
>                 }
>               [2] 'domain.example'
>               }
>             }
>           }
>
> Note that the otherName choice is defined (e.g., in 5280) as
>
>     OtherName ::= SEQUENCE {
>          type-id    OBJECT IDENTIFIER,
>          value      [0] EXPLICIT ANY DEFINED BY type-id }
>
> so you need to include an OID in the 'type-id' sub-field that gives 
> the specific SAN sub-type,
> governing the interpretation and type of the 'value' sub-field.
> I could not find any such OID in 
> https://datatracker.ietf.org/doc/html/rfc8994#section-6.2.2
> which says (among others):
>
>         Example:
>
>         Given an ACP address of fd89:b714:f3db:0:200:0:6400:0000, an ACP
>
>         domain name of acp.example.com, and an rsub extension of
>
>         area51.research, then this results in the following:
>
>           acp-node-name      = fd89b714f3db00000200000064000000
>
>                                [e-mail]
>
>           acp-domain-name    = acp.example.com
>
>           routing-subdomain  = area51.research.acp.example.com
>
>         The acp-node-name in Figure 2 is the ABNF definition ("Augmented BNF
>
>         for Syntax Specifications: ABNF" [RFC5234  <https://datatracker.ietf.org/doc/html/rfc5234>]) of the ACP Node Name.  An
>
>         ACP certificate MUST carry this information.  It MUST contain an
>
>         otherName field in the X.509 Subject Alternative Name extension, and
>
>         the otherName MUST contain an AcpNodeName as described in
>
>         Section 6.2.2  <https://datatracker.ietf.org/doc/html/rfc8994#section-6.2.2>.
>
> (BTW, there is an erroneous self-reference to Section 6.2.2 within 
> itself.)
> In this section I miss a definition which OID(s) to use for 
> acp-node-name etc.
>
>     Is there a reason not to include the line numbers from dumpasn1?
>
> Actually there are two reasons:
>
>   * those numbers are byte offsets and lengths, which are not
>     important here and just add clutter
>   * the numbers would be very cumbersome to keep consistent when
>     adapting the example
>
>     In the actual content, it goes from having the critical value shown, to
>
>     having:
>
>     +        OCTET STRING, encapsulates {
>
>     +          SEQUENCE {
>
>     +            [2] 'domain.example'
>
>     +            }
>
>     +          }
>
>     +        }
>
>     which I don't understand at all.  Is this a different dumpasn1 version?
>
> No, the 'critical' bit is before the 'value' field,
> thus it is shown just above the "OCTET STRING, encapsulates {"
>
>     if not, what are the actual bits on the wire changes?
>
> The tag "[0]" that had been placed with the 'critical' bit was wrong:
>
> [0] {
>             BOOLEAN TRUE
>             }
>
> so I corrected this to
>
> BOOLEAN TRUE
>
> See also the emails by Corey and me in this thread of Aug 2nd.
>
>          >    (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?)
>
>     Yes, I thought we allowed exactly that before, as:
>
>               Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
>
>                           value = macAddress (1.3.6.1.1.1.1.22)
>
>     in RFC7030.
>
> Good point that this effect could already be achieved by such a type 
> of CSR attribute
> that is different from the "new" approach using a CSR attribute of 
> type extensionRequest.
> Yet IMO the new approach is more adequate because there the (request 
> for an) extension
> is in the context of the extensionRequest attribute, rather than "out 
> of place" in some other attr,
> where its OID is harder to understand and to process without this context.
> So I'd suggest stating that any such to-be-filled-in extensions SHOULD 
> be placed inside
> the CSR attribute of type extensionRequest with an empty OCTET STRING 
> as the extnValue.
>
>          >    (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 don't understand.
>
>     Telling the client to include a specific subject is exactly the problem we
>
>     are dealing with... or are you making a distinction here between subject DN
>
>     and subjectAltName?
>
> There is a clear distinction between
>
>   * a cert/CSR subject, which is (essentially) mandatory and is a
>     (Distinguished) Name and
>   * the Subject Alternative Names (SANs) optionally given as X.509
>     extension values.
>
> as can be deduced also from the following declaration from RFC 2986 
> (PKCS#10)
>
>     CertificationRequestInfo ::= SEQUENCE {
>          version       INTEGER { v1(0) } (v1,...),
>          subject       Name,
>          subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
>          attributes    [0] Attributes{{ CRIAttributes }}
>     }
>
> noting that any SANs are (indirectly) part of the 'attributes' field 
> value.
>
> As I wrote on March 9th 
> <https://mailarchive.ietf.org/arch/msg/spasm/KSBlnRVVTcgpEAM8eA_uEssHY2I/> 
> and April 5th 
> <https://mailarchive.ietf.org/arch/msg/spasm/PqCEDBk_Vd59bDDxb7hVDg41PKM/> 
> and likely already before,
> while SANs can be expressed as part of an extensionRequest CSR attribute,
> a regular subject field so far cannot be expressed in a CsrAttrs 
> structure.
> This is because no OID has been defined that could be used, e.g., in 
> the 'type' field of a CSR attribute
> and the CsrAttrs structure does not have any other field where a 
> subject Name could be placed.
>
>     David
>