Hi, > See one example of Authority Key Identifier available at: > http://www.pkiglobe.org/aki_ski.htm > the length of Authority Key Identifier is 20 bytes, also seems it uses text > readable format, i.e.,PEM rather than > binary encoded format, which aligns with idevid-issuer example (i.e., > base64encodedvalue==) in the section 5.2 of RFC8366.
Yes it can be rendered in whatever text format; converted to PEM, or base64 encoded. Because we use the constrained-Voucher format (of draft-ietf-anima-constrained-voucher) we use the pure binary format; see "idevid-issuer" in Section 8.1.1 and 8.2.1 and Section 5.1 of RFC 8366. This is binary encoded directly using YANG-to-CBOR without further encodings like base64. With YANG-to-JSON encoding rules, it is base64 encoded String, and this is the Section 5.2 example. > [Qin]: Do you propose to add more attributes or fields in the AKI? E.g., add > cryptography methods, see cryptograph methods example in > https://asecuritysite.com/encryption/sigs4 No new attributes, only those already defined in RFC 5280 Section 4.2.1.1. A CA generating certificates MAY include the named fields 'authorityCertIssuer' and/or 'authorityCertSerialNumber' , in addition to 'keyIdentifier'. Although it is normally not done and not necessary. So only Option 1 removes these fields 'authorityCertIssuer' and/or 'authorityCertSerialNumber' ; while Option 2 and 3 keep them in if present. (Note that the field 'keyIdentifier' is always there, due to the IEEE 801.1AR requirements for the IDevID certificate.) > It seems we will completely remove the “issuer” from authorityKeyIdentifier > for some reasons. The "issuer" / 'authorityCertIssuer' is often not present; but we don't propose to remove it if present - Option 2 and 3 keep it in. (Only Option 1 ignores it completely keeping only the 'keyIdentifier') So I don't think there's a concern here. Regards Esko -----Original Message----- From: Qin Wu <bill...@huawei.com> Sent: Friday, September 24, 2021 11:44 To: Esko Dijk <esko.d...@iotconsultancy.nl>; sp...@ietf.org Cc: anima@ietf.org Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? Hi, Esko: -----邮件原件----- 发件人: Esko Dijk [mailto:esko.d...@iotconsultancy.nl] 发送时间: 2021年9月23日 22:44 收件人: Qin Wu <bill...@huawei.com>; sp...@ietf.org 抄送: anima@ietf.org 主题: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? Hi, > [Qin]: Yes, I confuse with the option2 and 3, 1. first, I didn't see 2 > bytes 04 18 appeared in the below 26 bytes example encoded data 2. > Second I think ox18 standard for length of encoded data which is 24 bytes. > 3. Since the 'SEQUENCE' is included in the encoded data, why not choose > option 2? 1. Indeed for Option 3, the idevid-issuer field bstr would contain 26 bytes: 041830168014D5039FC78A4DC0468760191FD71B1534C2D88428 Option 2 is 24 bytes: 30168014D5039FC78A4DC0468760191FD71B1534C2D88428 Option 1 is 20 bytes: D5039FC78A4DC0468760191FD71B1534C2D88428 [Qin]: Thank for clarification. See one example of Authority Key Identifier available at: http://www.pkiglobe.org/aki_ski.htm the length of Authority Key Identifier is 20 bytes, also seems it uses text readable format, i.e.,PEM rather than binary encoded format, which aligns with idevid-issuer example (i.e., base64encodedvalue==) in the section 5.2 of RFC8366. 2. Sorry, not quite sure what you meant here! [Qin] Thank, I think you clear my confusion on the encoded data format. In this case the data inside the octet string ('payload') is 24 bytes but it could be another value depending on how the CA encodes its Authority Key Identifier ext, e.g. how it is hashed / how long the hash is, and what other of the optional fields are included in the AKI. [Qin]: Do you propose to add more attributes or fields in the AKI? E.g., add cryptography methods, see cryptograph methods example in https://asecuritysite.com/encryption/sigs4 3. Option 2 and 3 are quite similar I think. In the Constrained-BRSKI draft + interop work we have just selected Option 3, though. This was based on the feeling that Option 3 was closest to the present RFC 8366 definition. The size was not really an argument here because the field is used always in the non-constrained network leg Registrar -> MASA (in Voucher Request) and hardly ever used in the constrained network leg (Registrar -> Pledge, in Voucher). [Qin]: Understood now. I agree with your statement. In addition, It looks authorityKeyIdentifier=keyid,issuer, the keyed is The Key ID of the CA’s cert, the issuer is the subject and the serial number of the CA’s cert One example of X509v3 Authority Key Identifier is: X509v3 Authority Key Identifier: keyid:7E:E5:82:FF:FF:FF:15:96:9B:40:FF:C9:5E:51:FF:69:67:4D:BF:FF DirName:/C=UK/O=V13/OU=V13/CN=V13 Certificate Authority serial:8E:FF:A2:1B:74:DD:54:FF In this example, both DirName and Serial are seen as issuer. DirName is one example of subject alternative name, it could also be URI, email, IP address, e.g., subjectAltName=email:copy,email:my@other.address,URI:http://my.url.here/ subjectAltName=IP:192.168.7.1 subjectAltName=IP:13::17 subjectAltName=email:my@other.address,RID:1.2.3.4 subjectAltName=otherName:1.2.3.4;UTF8:some other identifier It seems we will completely remove the “issuer” from authorityKeyIdentifier for some reasons. Best regards Esko -----Original Message----- From: Qin Wu <bill...@huawei.com> Sent: Tuesday, September 21, 2021 12:44 To: Esko Dijk <esko.d...@iotconsultancy.nl>; la...@ietf.org Cc: anima@ietf.org Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? Hi, Esko: -----邮件原件----- 发件人: Anima [mailto:anima-boun...@ietf.org] 代表 Esko Dijk 发送时间: 2021年9月20日 20:48 收件人: Qin Wu <bill...@huawei.com>; la...@ietf.org 抄送: anima@ietf.org 主题: Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? Hello Qin, > naming of this leaf ' idevid-issuer ' is the root cause for > introducing such confusion, For me the cause of the confusion was the sentence " The Authority Key Identifier OCTET STRING (as defined in Section 4.2.1.1 of RFC 5280)". There is only one OCTET STRING defined in Section 4.2.1.1, which is the keyIdentifier field, also named "Key Identifier" in the draft which is not the "Authority Key Identifier". The actual Authority Key Identifier OCTET STRING is defined in Section 4.1 as the field " extnValue" which is present in the Authority Key Identifier extension, so one needs to look in another section (4.1) for the meant OCTET STRING. The interpretation is still ambiguous between options 2 and 3 even if you analyse closely. [Qin]: Yes, I confuse with the option2 and 3, 1. first, I didn't see 2 bytes 04 18 appeared in the below 26 bytes example encoded data 2. Second I think ox18 standard for length of encoded data which is 24 bytes. 3. Since the 'SEQUENCE' is included in the encoded data, why not choose option 2? > whether the voucher artifacts signed by manufacture, needs to closely > tie with MASA For nonceful Vouchers, the MASA would need to sign it or delegate the generation and/or signing to a manufacturer's server. (In the latter case there is a trust relation and operational interaction, but no close tie necessarily.) As long as the signer can be trusted by the Pledge's built-in Trust Anchor, it works. [Qin]:Thank for clarification, if my understanding is correct, the MASA in the former case is the third party entity while manufacturer's server in the latter case should be deployed together with the device by the same manufacturer. regards Esko -----Original Message----- From: Qin Wu <bill...@huawei.com> Sent: Saturday, September 18, 2021 11:41 To: Michael Richardson <m...@sandelman.ca>; la...@ietf.org Cc: stokc...@bbhmail.nl; Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? I agree with this analysis, it looks the naming of this leaf ' idevid-issuer ' is the root cause for introducing such confusion, i.e., easily link KeyIdentifier to 'issuer' defined in section 4.1.2.4 of RFC5280. Also I am wondering whether the voucher artifacts signed by manufacture, needs to closely tie with MASA. Maybe this relation can be decoupled as well. -Qin -----邮件原件----- 发件人: Anima [mailto:anima-boun...@ietf.org] 代表 Michael Richardson 发送时间: 2021年9月9日 1:12 收件人: la...@ietf.org 抄送: stokc...@bbhmail.nl; Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org 主题: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? RFC8366 specifies a idevid-issuer to identify the CA that issued the IDevID. It says: https://www.rfc-editor.org/rfc/rfc8366.html#section-5.3 leaf idevid-issuer { type binary; description "The Authority Key Identifier OCTET STRING (as defined in Section 4.2.1.1 of RFC 5280) from the pledge's IDevID certificate. Optional since some serial-numbers are already unique within the scope of a MASA. Inclusion of the statistically unique key identifier ensures statistically unique identification of the hardware. When processing a voucher, a pledge MUST ensure that its IDevID Authority Key Identifier matches this value. If no match occurs, then the pledge MUST NOT process this voucher. When issuing a voucher, the MASA MUST ensure that this field is populated for serial-numbers that are not otherwise unique within the scope of the MASA."; } We have some discussion about what exactly this means. https://github.com/anima-wg/constrained-voucher/issues/161 captures this as three possibilities: 1) only the KeyIdentifier OCTET STRING 2) the complete AuthorityKeyIdentifier ASN.1 SEQUENCE structure 3) the complete Authority Key Identifier extension OCTET STRING value 'extnValue' per Section 4.1 of RFC 5280 Esko suggests that (3) is the correct thing, detailed as: OCTET STRING (26 byte) 30168014D5039FC78A4DC0468760191FD71B1534C2D88428 SEQUENCE (1 elem) [0] (20 byte) D5039FC78A4DC0468760191FD71B1534C2D88428 > I meant here 26 bytes, sorry! > So 2 bytes 04 18 are used to encode ‘OCTET STRING’, 2 bytes 30 16 for > ‘SEQUENCE’, 2 bytes 80 14 for the ‘[0]’ and the rest is the actual > KeyIdentifier (20 bytes). We think this consistent with other users of Authority Key Identifier. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
