Subject: [Anima] lack of clarity on CSR attributes required for ACP use of BRSKI

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Jan 2019 21:11:26 -0500

<With my implementor hat on>

I am trying to construct and decode a correct CSR attributes that a BRSKI
Registrary should return to a Pledge in the /csrattr request.

The ACP document says that it should ask for a subjectAltName extension,
and it should contain an rfc822Name value that contains the prefix assigned
to the ANIMA ACP node.

I read RFC7030 section 4.5.2:
    https://tools.ietf.org/html/rfc7030#section-4.5.2

CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

And I see that it's a sequence of objects, each object is either an OID,
or an attribute.   I looked through the example and decoded it with my code,
and was able to process it in my code confirming my understanding of this
level.  But RFC7030 has do subjectAltName example, unfortunately.
(OpenSSL has no CSR attribute objects that I can see)

Attributes have a type, followed by a *SET* of whatever attribute one
expects.

https://tools.ietf.org/html/rfc5280#section-4.2.1.6 defines subjectAltName:

   SubjectAltName ::= GeneralNames
   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,   <-- this one
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

So I should see:
   [
     [ subjectAltName-OID,
        < -- a *SET*
           [ <- Sequence of GeneralNames
             CHOICE[1]-"[email-masked]"
           ]
           XXX
     ]
   ]

There could be another option for the subjectAltName CSR at XXX
(i.e. another GeneralName Sequence).

I feel far from confident that I've got this right.
Here is the asn1parse output from what I've produced:

obiwan-[projects/pandora/dtls-fountain](2.5.1) mcr 10527 %openssl asn1parse -in tmp/csr_bulb1.der -inform der
    0:d=0  hl=2 l=  72 cons: SEQUENCE
    2:d=1  hl=2 l=  70 cons: SEQUENCE
    4:d=2  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
    9:d=2  hl=2 l=  63 cons: SET
   11:d=3  hl=2 l=  61 cons: SEQUENCE
   13:d=4  hl=2 l=  59 cons: cont [ 1 ]
   15:d=5  hl=2 l=  57 prim: UTF8STRING        :[email-masked]

I don't quite understand 13. I think it's the representation that the
CHOICE(1) was made, but in the OpenSSL objects, that part is the tag of the
ASN1Data object.

%xxd -p tmp/csr_bulb1.der
304830460603551d11313f303da13b0c3972666353454c462b6664373339
6663323363333434303131323233333434353530303030303030302b4061
63702e6578616d706c652e636f6d

There seems like an awful lot of space for making a lot of mistakes.
I would like to add some examples to draft-ietf-anima-autonomic-control-plane.
I don't think we ever want other than rfc822Name SANs, and I don't think we
ever want more than one.

I would strongly suggest that maybe we want to do this with CBOR instead.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-