Subject: Re: [COSE] draft-ietf-cose-x509-07 x5chain and x5bag in COSE_Key

From: Brian Sipos <[email-masked]>
Date: Mon, 7 Dec 2020 14:08:56 +0000

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-masked]>
> 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-masked]
> > https://www.ietf.org/mailman/listinfo/cose

---

From: John Mattsson <[email-masked]>
Date: Tue, 8 Dec 2020 08:11:45 +0000

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-masked]> on behalf of Brian Sipos <[email-masked]>
Date: Monday, 7 December 2020 at 15:09
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [COSE] draft-ietf-cose-x509-07 x5chain and x5bag in COSE_Key

Ivaylo,

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Dec 2020 13:27:58 -0500

I like the Add KID approach.

Russ

> On Dec 8, 2020, at 3:11 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
>