Decide on the final format of data in 'idevid-issuer'

[EskoDijk]

This is a reminder to complete the discussion and decide on the final format of 'idevid-issuer'. See also the thread on the ANIMA WG ML! https://www.mail-archive.com/anima@ietf.org/msg03724.html

options are 1) only the KeyIdentifier OCTET STRING value (i.e., the resulting bytes are not a ASN.1 thing) 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

Note for option 1: although this field is marked OPTIONAL in the ASN.1 definition of RFC 5280, it's always present in the AKI of an EE certificate based on the text in RFC 5280 .

Note: looking again at the complete RFC 5280 and RFC 8366 text, it looksl ike option 3) was intended!

[petervanderstok]

Right,

and the asn1 in the EE cerificate looks different again from the definition.

Peter

[EskoDijk]

Example as used in the mailing list:

041830168014D5039FC78A4DC0468760191FD71B1534C2D88428 (26 bytes)

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).

OCTET STRING (24 byte) 30168014D5039FC78A4DC0468760191FD71B1534C2D88428 SEQUENCE (1 elem) [0] (20 byte) D5039FC78A4DC0468760191FD71B1534C2D88428

In my Java APIs, getting the full OCTET STRING including the encapsulation marker (26 bytes) is the simplest code.

[EskoDijk]

However one can still debate what was intended with "Authority Key Identifier OCTET STRING" : the full octet string including the encapsulation marker of 2 bytes (e.g. 041830168014D5039FC78A4DC0468760191FD71B1534C2D88428), or just the value of the embedded octet string (e.g. 30168014D5039FC78A4DC0468760191FD71B1534C2D88428)

[petervanderstok]

For the cose- sign1 object we transport the naked (no asn1) signature. That is a good habit and I propose to transport the naked authority keyid.

[petervanderstok]

That is incredible, because it means adding 2 bytes to the certificate content.

[EskoDijk]

In the certificate, the two extra bytes are already there! (By design - RFC 5280). In the voucher, the idevid-issuer structure is normally not present at all so we don't have to count that. In the Registrar Voucher Request, it MUST be present so it adds always two bytes - but over a fast HTTPS connection where we don't aim to optimize for size.

The reason I'm now following this interpretation is that it looks like RFC 8366 is describing exactly this; but I'm equally ok to drop the 2 bytes to go back to only the embedded / naked value of the OCTET STRING (e.g. 30168014D5039FC78A4DC0468760191FD71B1534C2D88428, 24 bytes in above example) but only if we all agree.

[mcr]

We have the option of redefining it for the constrained-voucher. The initial 6 bytes are a constant.

[EskoDijk]

"6 bytes constant" is only true in the common cases, where only a KeyIdentifier field is used in the AKI, and one of the standard algorithms is used to compute the hash of the public key. The RFC 5280 allows people to put in more information though, or to use different methods, in which case these are not constant anymore.

The thing we can rely on at least is that a KeyIdentifier sub-field is always present, in the AKI of an IDevID cert. (Hence Option 1 is still on the table)

[EskoDijk]

Putting a reminder here that we may file an erratum on RFC 8366 (as discussed in the ML) to clarify interpretation

[petervanderstok]

How I love option 1.

I am certainly nnt looking forward to parse all extension possibilities at reception of the idevid_user.

[mcr]

I prefer option 1. This is an Amends on RFC8366.

[EskoDijk]

Peter also prefers option 1; I'm okay with it as well. Note in my code I tried all of the options 1/2/3 and option 1 has the additional parsing effort (in my case the BouncyCastle library does it for me, so no problem). So I don't understand Peter's comment in combination with his preference.

[siethower]

Both, option 1 and 3 are fine for me.
(Currently we implemented 3, according to our understanding of RFC 8366 [RFC 5280])

[mcr]

Conclusion go with 3, the full AKI. Include example.