Re: [lamps] EST CSRATTRS specifying the SAN

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

On 05.07.21 20:37, Michael Richardson wrote:
> David von Oheimb <[e-mail]> wrote:
>      > would have been more apparent.
>
> well, you just used ASN.1 we didn't understand to explain other ASN.1 we
> didn't understand :-)

My point is that we don't actually need to understand its details - it 
is sufficient to exploit the analogy to regular PKCS#10 CSR attribute 
encoding.


> What I took away was that my interpretation was not quite right for getting a explicit value.

Yep.


>      > Further, RFC 7030 section 4.5.2 does not cover the fact that names and
>      > name components in a CSR may be part of not only various X.509
>      > extensions such as SAN (which are to be encoded via the extra
>      > indirection of the extensionRequest OID) but also of the subject
>      > field/attribute of type (Distinguished)Name.
>
> Could you construct an example? Perhaps we could slip it in as errata.

I fear that RFC 7030 does not support expressing requested contents of 
the subject field.
For any X.509 extension values, just take excerpts from a DER encoded 
X.509 request constructed using, e.g,. OpenSSL.
For instance,

         Requested Extensions:
             X509v3 Key Usage:
                 Digital Signature

gets encoded as:

417  28:       SEQUENCE {
419   9:         OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14)
430  15:         SET {
432  13:           SEQUENCE {
434  11:             SEQUENCE {
436   3:               OBJECT IDENTIFIER keyUsage (2 5 29 15)
441   4:               OCTET STRING, encapsulates {
443   2:                 BIT STRING 7 unused bits
        :                   '1'B (bit 0)
        :                 }
        :               }
        :             }
        :           }
        :         }


>      > At least a more comprehensive example would have been very helpful to
>      > clarify the details of the intended encoding, and likewise any serious
>      > reference/example implementation, for instance in Cisco's libEST, which
>      > has remained extremely sketchy regarding the csrattrs topic.
>
> Are there examples in libest that we can use?
> Is there unit test code in there that could be exercised to validate other examples?
No, the libEST repo just contains the same minor example given in the RFC,
and the example client does not make proper use CSR attributes received.


> Are we back to redoing this in JSON?
CMP Updates also uses ASN.1, but we define a more straightforward and 
more capable structure for cert request templates,
also exploiting the structural analogy to cert attribute/extension 
templates used in regular CMP+CRMF cert requests:

https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates#section-2.16 
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates#section-2.16>
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.4.3 
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.4.3>
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#appendix-A 
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#appendix-A> 
(example)


On 05.07.21 21:41, Russ Housley wrote:

> This proposed "isomorphic" definition:
>    CsrAttrs ::= SEQUENCE {
>          oids          SET OF OBEJECT IDENTIFIER
>          attributes    SET OF Attribute{{ IOSet }}
>     }
>
> Does NOT produce the same bits on the wire as the structure defined in 
> RF 7030.
>
> Further, the use of SEQUENCE in RFC 7030 was to avoid the need for the 
> sort that is imposed when DER encoding SET.

Sure; "isomorphic" is a semantic/mathematical term, which deliberately 
abstracts from any representation and its issues.
As pointed out above, I gave the analogy just as an aid for obtaining 
example encodings of EST CSR attribute items.

     David