Eliot has suggested that: https://datatracker.ietf.org/doc/html/rfc7030#section-4.5.2 does not appear to allow the returned CSR Attributes to contain a value. Please correct me if I'm understanding the problem wrong.
RFC8994 assignment of IPv6 ULA can not, as far as I can understand, work without assigning a value. The Registrar must allocate a prefix for the new ACP node, and this has to go into the CSR in order for the CA to sign it. (Yes, the Registrar has to *check* that the CSR contains the right value along the way too. Yes, if the Registrar is ALSO the CA, then it can shortcut, but that's not in general true) My unit testing code is at: https://github.com/AnimaGUS-minerva/fountain/blob/master/spec/models/csr_attributes_spec.rb I found the ASN.1 code in section 4.5.2 beyond my understanding, so I muddled through, since fortunately, there was an example. 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}) } What I think that this says is that one can have: a) a Sequence of stuff. b) the stuff is either an OID. c) or the stuff is a SEQUENCE [ type, value ]. The complicated &id... is just saying that when you have some attribute type "FOO", then you can have the things that would be valid as values. I'm actually rather amazed at this level of meta-programming. (Can CDDL do that?) An example is provided: MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ BgcrBgEBAQEWBggqhkjOPQQDAw== %echo 'MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJBgcrBgEBAQEWBggqhkjOPQQDAw==' | base64 -d | dumpasn1 - 0 65: SEQUENCE { 2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7) 13 18: SEQUENCE { 15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 24 7: SET { 26 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34) : } : } 33 22: SEQUENCE { 35 9: OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14) 46 9: SET { 48 7: OBJECT IDENTIFIER '1 3 6 1 1 1 1 22' : } : } 57 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3) : } At 2, we have the OID "challengePassword", which tells the client that this attribute should be included (that's [b]). At 13-26, we have an attributed, ecPublicKey, with a *value* secp384r1. This tells the client what kind of things to sign with. (that's [c]) At 33, we have extensionRequest with oid value 1.3.6.1.1.1.1.22. (also [c]) Finally, at 57, we have just the attribute ecdsaWithSHA384, which is telling the client to use SHA2-384. In order to get this all right, I used the example above, made sure I could decode it, and then made sure that I could encode exactly that. I have an example building the subjectAltName rfc822Name (yes, my code hasn't caught up to otherName as specified in RFC8994 yet) which is: obiwan-[projects/pandora/fountain](2.6.6) mcr 10263 %dumpasn1 tmp/hellobulb0.der 0 32: SEQUENCE { 2 30: SEQUENCE { 4 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 9 23: SET { 11 21: SEQUENCE { 13 19: [1] { 15 17: UTF8String 'he...@example.com' : } : } : } : } : } I don't know what the [1] is actually, but possibly that's the rfc822Name. Yup, it is: # rfc822Name [1] IA5String, <-- this one So, I think that I'm entirely within spec for CSR Attributes, and I'd like to understand more from Owen and Eliot as to what problems they are having with CSR Attributes. Eliot has suggested we do it all in JSON (CBOR?), and I would certainly be happy with that. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima