Re: [lamps] struggling with CSRAttrs

[Corey Bonnell <[e-mail]>]

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), 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.

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

Thanks,

Corey

[1] https://datatracker.ietf.org/doc/html/rfc8994#section-6.2.2.1

 

 

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  <mailto:[e-mail]> <[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] <mailto:[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] <mailto:[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