<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 protected]"
]
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 protected]
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 protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
