Hi, I have also thought about how to identify X.509 with kid. I think it would good with at least some guidance to implementors. I have 2 reasons to identify a X.509 with a kid:
(1). x5t and x5u are encodes to more bytes than a short kid. This matters in very constrained systems. EDHOC with kid fits in single messages in 51 byte LoraWan and 5-hop 6TiSch. X5t does not. (2). COSE_Key does not have any subject, and does therefore not protect agains misbinding attacks when parties can register public keys without “proof of possession" (it is a stated goal of the SIGMA protocol to protect against such attacks). Self-signed certificates might therefore be more secure PRK than COSE_Key in some scenarios. As discussed earlier in this mail thread, I think there are 3 solutions to (1). [1]. The solution today is to put kid and x.509 in a dictionary/map. kid can be used for any key structures. Such use is hinted at in draft-mattsson-cose-cbor-cert-compress and is also how cTLS do things. [2]. add kid field in X.509 [3]. add kty field for X.509 in COSE_Key And one additional solution to r2 [4]. Put subject name in COSE_Key. Cheers John -----Original Message----- From: COSE <[email protected]> on behalf of Brian Sipos <[email protected]> Date: Monday, 7 December 2020 at 15:09 To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [COSE] draft-ietf-cose-x509-07 x5chain and x5bag in COSE_Key Ivaylo, I believe that your understanding of the situation is correct. There is nothing in the current draft which is *preventing* an x5chain or x5bag from being used within a COSE_Key structure. The only missing piece is that there is no existing "kty" value in [4] which would make use of the x5chain/x5bag containers. The use of PKIX certificates is slighty different than existing uses of COSE_Key to express raw (parameterized) public key data, but I think it's in the same spirit of "transporting key data and metadata outside of COSE messages" as existing uses. The one functional difference is that both x5chain and x5bag can represent *multiple* public keys, where all other existing "kty" definitions contain only a single public key. So in that sense any "kid" referring to the COSE_Key will be referring to the entire x5chain/x5bag, while a "x5t" reference would refer to only a single cert in the x5chain/x5bag. Would there be any objection from COSE WG for a non-COSE draft to propose adding a "kty" for "PKIX Certificates" to make use of the x5chain and x5bag containers as key parameters? Unfortunately, key parameter code points are negative integers, so the existing x5 code points cannot be used as key parameters. On Sun, 2020-11-15 at 19:03 +0100, Ivaylo Petrov wrote: > Hello Brian, > > I apologize for the delay. Thank you for reaching out! As the current > editor of the cose-x509 draft I will try to provide some answers > below. > > Cheers, > Ivaylo > > On Tue, Nov 3, 2020 at 7:44 PM Brian Sipos <[email protected]> > wrote: > > All, > > While investigating the use of COSE within another proposed > > security > > protocol [1] I ran into a use case which is not discussed as a > > possibility in the last draft-ietf-cose-x509 [2]: providing a > > certificate chain or bag within a COSE_Key (or COSE_KeySet) > > structure. > > > > [IP]: My understanding is that the idea of the author was that it is > better not to provide too many constraints on how the new header > parameters are used when that is not needed. Could you explain if the > way x5chain or x5bag somehow prevent you from efficiently using them? > > > This particular use case is because a there will likely be many > > signatures present from the same private key associated with an > > end- > > entity certificate, and the message encoding of [1] allows security > > "parameter" data to be encoded once and used for multiple security > > operations. The idea is that the x5chain would be provided once (as > > a > > COSE_Key) and then each COSE_Sign1 would contain an x5t associated > > with > > the end-entity certificate. This would avoid needing to include a > > duplicate x5chain in each of the COSE_Sign1 structures, which would > > bloat the size of the encoded signatures. > > > > [IP]: I am not sure I understood this correctly, so let me try to > rephrase it. In your protocol the security context is split in two > parts. One that is transmitted with each message and one that is not > (it is in a way static). Your idea is to have the certificate that > the protocol needs as the "static" part and then in each message to > send a x5t parameter to refer to this certificate instead of each > time including the complete certificate. If that is the case, that > sounds very reasonable to me, but is there anything in the current > draft preventing you from doing that? > > > Is there a technical reason why x5chain or x5bag are inappropriate > > to > > use within a COSE_Key structure? > > There seems to be nothing prohibiting this in [2] but also nothing > > advocating for this kind of use. The encoding itself could use the > > existing code points assigned for x5chain and x5bag Header > > Parameters > > sub-registry [3] and assign a new "X.509 Certificate" (or some > > other > > appropriate name) codepoint Key Types sub-registry [4]. > > > > Here again I don't think I fully understand your question. It appears > to me that you suggest that x5bag let's say will be placed inside a > COSE_Key structure. My understanding is that you could use a way to > refer to a certificate that would be used for the cryptographic > operations instead of referring to the key in another way. > > > As an alternative, my use could provide for either COSE_Key or > > x5chain/x5bag but that runs into use of codepoints from multiple > > registries for the same purpose, which seems confusing. And I feel > > like > > this certificate-as-public-key seems more general purpose than my > > use > > in [1]. > > > > Thanks for any clarification, > > Brian S. > > > > [1] https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-02 > > [2] https://tools.ietf.org/html/draft-ietf-cose-x509-07 > > [3] > > https://www.iana.org/assignments/cose/cose.xhtml#header-parameters > > [4] https://www.iana.org/assignments/cose/cose.xhtml#key-type > > _______________________________________________ > > COSE mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
