Subject: [COSE] Key Identification Headers

From: Brian Campbell <[email-masked]>
Date: Tue, 4 Aug 2015 13:54:15 -0600

JOSE has seven different headers aimed at helping the message recipient
identity the key to use to verify or decrypt the message. They are "jku",
"jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" and are discussed in JWS
http://tools.ietf.org/html/rfc7515#section-4.1 and JWE
http://tools.ietf.org/html/rfc7516#section-4.1

Personally, I've always felt that JOSE had too many key hinting/signaling
headers and my implementation experience has only solidified that belief.

I don't think there's any question that COSE should have a Key ID header
that serves a purpose similar to JOSE's Key ID/"kid" header. This message
is intended to try and coerce the WG towards some consensus about what
other key hinting headers to include in the main COSE specification. What
follows is a somewhat brief discussion of each of the JOSE headers and
their potential applicability to COSE. Long story short, I propose that
COSE have significantly fewer key hinting/signaling headers. Perhaps going
as far as only having a Key ID header.

Parameters like "jku" and "x5u", which encourage implementations to blindly
retrieve remote content seem ripe for security problems ranging from
resource consumption attacks  to inadvertently trusting verification keys
that shouldn't be trusted. They are also not particularly space efficient
and (as defined for JOSE anyway) are for HTTPS URIs only. In practice with
JOSE I've seen many applications which use a JWK Set available at an HTTPS
URI, however, the URI is determined some other way (out of band agreement,
metadata exchange, etc.) and never carried in the message.  I propose that
COSE not port over the "jku" or "x5u" message headers and also not attempt
to define a COSE key URI style equivalent header.

Porting the "jwk" message header directly to carry a JWK in a COSE message
doesn't really make sense and I'd propose that COSE not try to define a
similar header to carry a COSE_Key. The full key is not a space efficient
way to signal the key (as apposed to a key id or hash, for example) and
adds risk that an implementation might accept a message with a such a key
without proper trust decision or binding of the key to an identity of a
trusted sender.

A header to carry a X.509 Certificate or Chain (like "x5c" in JOSE) does
potentially seem useful to carry a key that is bound to some identity via
the certificate(s). However, it may not be particularly appropriate or
useful in the constrained word due to the size overhead it adds to a
message. It's also really only meaningful for signed message so probably
wouldn't be appropriate to be defined as a top level header. I'd like to
know if folks in the WG feel strongly (more than just a speculative feeling
that it might be useful) that such a header is needed. I'm inclined to say
that COSE would be better off without.

Does COSE need header(s) to convey the certificate fingerprint/thumbprint?
JOSE has two - "x5t" and "x5t#S256".  As an implementer, I sure would have
preferred that there was only one. Or even none. While a thumbprint does
inherently convey some additional semantics over a key ID alone, a key ID
can certainly carry a thumbprint. I imagine that most deployments will need
to come to agreement about how keys will be singled anyway. So agreeing
that, in the situations that want to do it, the key ID can carry a
certificate thumbprint value seems no more cumbersome than agreeing to use
a more specific header for the same purpose. This is another one where I'd
like to hear if folks in the WG feel strongly that a certificate
fingerprint/thumbprint header is needed in COSE. If so, it'd be really nice
if we could land on a single header for it rather than two. Perhaps a
truncated SHA-256 could be a little bit more space efficient while avoiding
SHA1.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 7 Aug 2015 15:56:06 -0700

I have been holding off on giving my opinion to let others have first crack at this issue.  Since there does not seem to be anyone who cares about these issues I will give my opinion and we will see where things fall out.

I completely agree that key id is needed.  That is why it is the one of these methods that I put into the core document and assigned an integer value for.

Until a group of people come to the working group and say that they have a need to have X.509 certificates as a basis for trust, it is not clear to me that there is any need to support any of the X.509 certificate identification methods.  Even then, there is the ability to use the key id field to match against the subject key identifier field in a certificate so we are not leaving them completely hanging in the wind.

I was never happy with the idea of using URLs to fetch keys for many of the reasons that Brian states below.  This is one of the reasons why I was pressing for language in the JOSE documents that discussed the ideas of binding identify to a key retrieved from a URL as being problematic.  I would be happy not to support this key fetching method.

I have an, admittedly small, degree of sympathy for allowing the key to be carried in the message.  Doing some has some issues about the size of the data that is transmitted.  However, the key is going to be a far more unique value than a key identifier field is for matching against in a database.  I currently have defined a version of carrying the key for doing static-static DH. It is easier to say compare the key against a trust database than it is to say compare one of the other fields (i.e. URL).  However, I would expect that this would not be used much and that key identifier is going to be the 99% case of key identification.   I can live with this option either being present or absent in the specification.

jim

From: COSE [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, August 04, 2015 12:54 PM
To: [email-masked]
Subject: [COSE] Key Identification Headers

JOSE has seven different headers aimed at helping the message recipient identity the key to use to verify or decrypt the message. They are "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" and are discussed in JWS http://tools.ietf.org/html/rfc7515#section-4.1 and JWE http://tools.ietf.org/html/rfc7516#section-4.1

Personally, I've always felt that JOSE had too many key hinting/signaling headers and my implementation experience has only solidified that belief. 

I don't think there's any question that COSE should have a Key ID header that serves a purpose similar to JOSE's Key ID/"kid" header. This message is intended to try and coerce the WG towards some consensus about what other key hinting headers to include in the main COSE specification. What follows is a somewhat brief discussion of each of the JOSE headers and their potential applicability to COSE. Long story short, I propose that COSE have significantly fewer key hinting/signaling headers. Perhaps going as far as only having a Key ID header.

Parameters like "jku" and "x5u", which encourage implementations to blindly retrieve remote content seem ripe for security problems ranging from resource consumption attacks  to inadvertently trusting verification keys that shouldn't be trusted. They are also not particularly space efficient and (as defined for JOSE anyway) are for HTTPS URIs only. In practice with JOSE I've seen many applications which use a JWK Set available at an HTTPS URI, however, the URI is determined some other way (out of band agreement, metadata exchange, etc.) and never carried in the message.  I propose that COSE not port over the "jku" or "x5u" message headers and also not attempt to define a COSE key URI style equivalent header. 

Porting the "jwk" message header directly to carry a JWK in a COSE message doesn't really make sense and I'd propose that COSE not try to define a similar header to carry a COSE_Key. The full key is not a space efficient way to signal the key (as apposed to a key id or hash, for example) and adds risk that an implementation might accept a message with a such a key without proper trust decision or binding of the key to an identity of a trusted sender. 

A header to carry a X.509 Certificate or Chain (like "x5c" in JOSE) does potentially seem useful to carry a key that is bound to some identity via the certificate(s). However, it may not be particularly appropriate or useful in the constrained word due to the size overhead it adds to a message. It's also really only meaningful for signed message so probably wouldn't be appropriate to be defined as a top level header. I'd like to know if folks in the WG feel strongly (more than just a speculative feeling that it might be useful) that such a header is needed. I'm inclined to say that COSE would be better off without.

Does COSE need header(s) to convey the certificate fingerprint/thumbprint? JOSE has two - "x5t" and "x5t#S256".  As an implementer, I sure would have preferred that there was only one. Or even none. While a thumbprint does inherently convey some additional semantics over a key ID alone, a key ID can certainly carry a thumbprint. I imagine that most deployments will need to come to agreement about how keys will be singled anyway. So agreeing that, in the situations that want to do it, the key ID can carry a certificate thumbprint value seems no more cumbersome than agreeing to use a more specific header for the same purpose. This is another one where I'd like to hear if folks in the WG feel strongly that a certificate fingerprint/thumbprint header is needed in COSE. If so, it'd be really nice if we could land on a single header for it rather than two. Perhaps a truncated SHA-256 could be a little bit more space efficient while avoiding SHA1.

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 26 Aug 2015 21:27:14 +0200

Hi,

I come for the PKI side of things and like the idea that the device trusts
one or several roots and then the connecting entity provides the chain to
one of the trusted root(s) when sending a signed message, giving the
benefit that no lookup is needed or no big tables with trusted keys etc.
With that said I can see that the messages will grow a lot when adding the
x509 chain and to validate the chain several asymmetric crypto operations
would be needed so the devices that would benefit of the simplified
provisioning with just a trust anchor would need to handel the larger
message and do several crypto operations, i.e. it might just as well be
able to handle JOSE.

With that said I think having the option to send the chain is good, but I
can see the problems also so if no one else wants it will will not push for
it.

Best Regards
Samuel Erdtman

On Sat, Aug 8, 2015 at 12:56 AM, Jim Schaad <[email-masked]> wrote:

> I have been holding off on giving my opinion to let others have first
> crack at this issue.  Since there does not seem to be anyone who cares
> about these issues I will give my opinion and we will see where things fall
> out.
>
>
>
> I completely agree that key id is needed.  That is why it is the one of
> these methods that I put into the core document and assigned an integer
> value for.
>
>
>
> Until a group of people come to the working group and say that they have a
> need to have X.509 certificates as a basis for trust, it is not clear to me
> that there is any need to support any of the X.509 certificate
> identification methods.  Even then, there is the ability to use the key id
> field to match against the subject key identifier field in a certificate so
> we are not leaving them completely hanging in the wind.
>
>
>
> I was never happy with the idea of using URLs to fetch keys for many of
> the reasons that Brian states below.  This is one of the reasons why I was
> pressing for language in the JOSE documents that discussed the ideas of
> binding identify to a key retrieved from a URL as being problematic.  I
> would be happy not to support this key fetching method.
>
>
>
> I have an, admittedly small, degree of sympathy for allowing the key to be
> carried in the message.  Doing some has some issues about the size of the
> data that is transmitted.  However, the key is going to be a far more
> unique value than a key identifier field is for matching against in a
> database.  I currently have defined a version of carrying the key for doing
> static-static DH. It is easier to say compare the key against a trust
> database than it is to say compare one of the other fields (i.e. URL).
> However, I would expect that this would not be used much and that key
> identifier is going to be the 99% case of key identification.   I can live
> with this option either being present or absent in the specification.
>
>
>
> jim
>
>
>
> *From:* COSE [mailto:[email-masked]] *On Behalf Of *Brian Campbell
> *Sent:* Tuesday, August 04, 2015 12:54 PM
> *To:* [email-masked]
> *Subject:* [COSE] Key Identification Headers
>
>
>
> Parameters like "jku" and "x5u", which encourage implementations to
> blindly retrieve remote content seem ripe for security problems ranging
> from resource consumption attacks  to inadvertently trusting verification
> keys that shouldn't be trusted. They are also not particularly space
> efficient and (as defined for JOSE anyway) are for HTTPS URIs only. In
> practice with JOSE I've seen many applications which use a JWK Set
> available at an HTTPS URI, however, the URI is determined some other way
> (out of band agreement, metadata exchange, etc.) and never carried in the
> message.  I propose that COSE not port over the "jku" or "x5u" message
> headers and also not attempt to define a COSE key URI style equivalent
> header.
>
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>
>