Unfortunately, i have to pile on instead of just answering:
I can not remember that we ever constructed a case where his
field was necessary when we wrote rfc8366. At least, we did
not document it e.g. in the examples. Such an example, explanation
would now be very helpfull in answering your question. Or at leas
for me to wrap my head around it.
I for once can not come up with a case where this field would
be anything else than what is in the CMS signerInfo, aka: this
field is redundant. And creating correct interop for
a redundant field is some somewhat non-motivational.
So, if anyone can lay out an example where this field is
actually required, i would be a lot more incentivised
to think about an answer. But primarily i'd like tha
type of example to be added to rfc8366bis.
Cheers
Toerless
P.S.: I think it is [1], primarily because it would be
strange to map a CMS structure just into a single CMS
octet string field instead of mapping it 1:1.
On Fri, Jul 23, 2021 at 03:30:39PM +0000, Esko Dijk wrote:
> 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.
Sounds like at least the start for an errata against RFC8366.
Not sure if we can start filing an errata when we agree that
the spec is ambiguous *sigh*.
> 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
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
