I like the Add KID approach. Russ
> On Dec 8, 2020, at 3:11 AM, John Mattsson > <[email protected]> wrote: > > 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
