Re: [lamps] struggling with CSRAttrs

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

On 03.08.22 22:14, Michael Richardson wrote:
> David von Oheimb<[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