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
