Hello all,

From the hackathon/interop we hit an interesting difference in spec-reading 
viewpoints that I would like to bring to the list.

*** Question and context
The question is what is included in the ‘idevid-issuer’ field? RFC 8366 states 
that it is binary and:

           The Authority Key Identifier OCTET STRING (as defined in
           https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1) from 
the pledge's IDevID
           certificate.  

We can look at the 4.2.1.1 RFC 5280 definition:

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

*** Interpretation #1
take the OCTET STRING part of the Authority Key Identifier, i.e. the " 
Authority Key Identifier OCTET STRING "  which is the last line == 
KeyIdentifier.
So only the ASN.1 bytes encoding 'KeyIdentifier' are included there because 
this is the OCTET STRING part of it as indicated. That is why OCTET STRING is 
written in capitals in RFC 8366.

Note that the keyIdentifier MUST be there for non-self-signed certs per RFC 
5280:
“The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction”

So for this reason one can rely on purely the keyIdentifier part of the AKI; 
and one could think that RFC 8366 was stating this.

*** Interpretation #2
The OCTET STRING is the entire structure AuthorityKeyIdentifier , encoded in 
ASN.1 format (=JSON Octet String encoding in a JSON Voucher, or in CBOR voucher 
a ‘byte string’ CBOR type).
Even though the AuthorityKeyIdentifier  SEQUENCE is not labeled as “OCTET 
STRING” in capitals in RFC 5280, this is what is intended because it can be 
encoded as an octet string in the voucher and is also encoded as octet string 
(coding for ASN.1 SEQUENCE) in ASN.1.

Now I wonder which is right/intended?
And furthermore for constrained use cases would it be ok to take it out as the 
text in RFC 8366 suggests is okay? E.g. if serialNumber is unique across all 
Pledges made by Vendor X.

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl    |   +31 6 
2385 8339

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to