Subject: [COSE] Carrying certificate chains in COSE signed messages

From: "Lundblade, Laurence" <[email-masked]>
Date: Thu, 3 Nov 2016 19:39:53 +0000

For many use cases it is a requirement that a signed message carry leaf and intermediate (X.509) certs that would be used to verify against a trusted root.

It seems like the way to do this is with a COSE_Key, but there aren’t any examples or details.  Is this right?

Thx

LL

---

From: Jim Schaad <[email-masked]>
Date: Thu, 3 Nov 2016 13:15:31 -0700

Do you have a use case where you are planning to use COSE and need to carry
cert chains or is this just speculative?

Jim

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Lundblade, Laurence
> Sent: Thursday, November 03, 2016 12:40 PM
> To: [email-masked]
> Subject: [COSE] Carrying certificate chains in COSE signed messages
> 
> For many use cases it is a requirement that a signed message carry leaf
and
> intermediate (X.509) certs that would be used to verify against a trusted
root.
> 
> It seems like the way to do this is with a COSE_Key, but there aren't any
> examples or details.  Is this right?
> 
> Thx
> 
> LL
> 
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: "Lundblade, Laurence" <[email-masked]>
Date: Fri, 4 Nov 2016 00:08:45 +0000

Yes, have a use case where I *think* I need to carry cert chains with a signed message.  I want to sign something in one place and I want someone far away to be able to verify it based on a trusted a root key.  Compatibility with extant and various cert management SW and services is also desirable.

If not cert chains, then what?  

LL

________________________________________
From: Jim Schaad <[email-masked]>
Sent: Thursday, November 3, 2016 1:15 PM
To: Lundblade, Laurence; [email-masked]
Subject: RE: [COSE] Carrying certificate chains in COSE signed messages

Jim

and
root.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 04 Nov 2016 10:23:46 -0400

If your environment is so constrained that you want to use COSE, why
would you decide on X.509 as your certificate format??  Your cert chain
would likely be larger than your data payload!!

-derek

"Lundblade, Laurence" <[email-masked]> writes:

> Yes, have a use case where I *think* I need to carry cert chains with
> a signed message.  I want to sign something in one place and I want
> someone far away to be able to verify it based on a trusted a root
> key.  Compatibility with extant and various cert management SW and
> services is also desirable.
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Lundblade, Laurence" <[email-masked]>
Date: Fri, 4 Nov 2016 15:47:28 +0000

1) A CBOR/COSE implementation is much cleaner and nicer than a ASN.1/CMS implementation. It is less work to implement, easier to maintain, test and so on. Also it’s not just about the data size.  Would guess that the code size difference between implementations of CBOR/COSE and ASN.1/CMS is larger than a cert.  Also you can add the X.509 cert to the protocol messages outside the constrained environment.

Personally, I was hoping CBOR/COSE would replace ASN.1/CMS in the very long term. :-)

2) Same question as before. If not cert chains, then what?  Pretty sure the 3-party trust introduction with a well-known root cert is a fundamental model that COSE should support.

LL

---

From: Derek Atkins <[email-masked]>
Date: Fri, 04 Nov 2016 12:36:08 -0400

Hi,

"Lundblade, Laurence" <[email-masked]> writes:

> 1) A CBOR/COSE implementation is much cleaner and nicer than a
> ASN.1/CMS implementation. It is less work to implement, easier to
> maintain, test and so on.

Yes...  This is part of my point.

>      Also it’s not just about the data size.
> Would guess that the code size difference between implementations of
> CBOR/COSE and ASN.1/CMS is larger than a cert.  Also you can add the
> X.509 cert to the protocol messages outside the constrained
> environment.

Sure, it's not just about data size, it's also about code size.  But if
you're using COSE then presumably size matters.

> Personally, I was hoping CBOR/COSE would replace ASN.1/CMS in the very

Why wait?

> 2) Same question as before. If not cert chains, then what?  Pretty
> sure the 3-party trust introduction with a well-known root cert is a
> fundamental model that COSE should support.

There is nothing wrong with cert chains per-se, but I would argue X.509
is the wrong solution for COSE.

-derek

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 4 Nov 2016 18:49:23 +0100

It might absolutely feel strange to have certificate chains in COSE since
that would become the larger part of the message.

However I think Laurence has a point in the fact that It is more convenient
to use CBOR then ASN1 even if you formally have the bandwidth and capacity
to process ASN1.

Then there is the connection to existing trust infrastructure many
organizations have well functioning PKIs setups and wants to use them.
Are you saying that we should only use COSE when building completely new
systems with no interaction with existing infrastructure?
I think it would be good for adoption if we could support this use-case.
I could also imagine CAs adopting new certificate formats based on CBOR and
COSE in the future and if that happens a transition would be much easier if
they had the option to start using COSE today.

If this is a big no-no I guess JOSE would be the option.

//Samuel

---

From: Jim Schaad <[email-masked]>
Date: Fri, 4 Nov 2016 11:48:52 -0700

During the development of the COSE document, the creation of attributes to carry X.509 items was discussed.  Given the set of use cases that we had on our radar at the time it was decided that we did not need this at the time.  These were all cases where we were looking at constrained devices where the addition of the certificate to many messages was going to be a problem.  In this environment, if you were using X.509 then you would pre-distribute the certificates rather than carrying them in a message.

If we can identify a number of cases where we would be using X.509 certificates then I would be willing to create a document which would define the fields and how to use them.  It would appear that we might have one case, do people know of more?

I don’t think we have a strong case for doing a new certificate format at this time, however if people think there is enough of a need then the next step would be for them to organize a BOF to see if they can attract enough attention. 

Jim

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Friday, November 04, 2016 10:49 AM
To: Derek Atkins <[email-masked]>
Cc: Lundblade, Laurence <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] Carrying certificate chains in COSE signed messages

It might absolutely feel strange to have certificate chains in COSE since that would become the larger part of the message.

However I think Laurence has a point in the fact that It is more convenient to use CBOR then ASN1 even if you formally have the bandwidth and capacity to process ASN1.

Then there is the connection to existing trust infrastructure many organizations have well functioning PKIs setups and wants to use them.
Are you saying that we should only use COSE when building completely new systems with no interaction with existing infrastructure? 
I think it would be good for adoption if we could support this use-case. 
I could also imagine CAs adopting new certificate formats based on CBOR and COSE in the future and if that happens a transition would be much easier if they had the option to start using COSE today.

//Samuel

On Fri, Nov 4, 2016 at 5:36 PM, Derek Atkins <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Why wait?

-derek

>
>
> On Nov 4, 2016, at 7:23 AM, Derek Atkins <[email-masked] <mailto:[email-masked]> > wrote:
>
>> "Lundblade, Laurence" <[email-masked] <mailto:[email-masked]> > writes:
>>
>>> From: Jim Schaad <[email-masked] <mailto:[email-masked]> >
>>> To: Lundblade, Laurence; [email-masked] <mailto:[email-masked]> 
>>>> From: COSE [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Lundblade, Laurence
>>>> To: [email-masked] <mailto:[email-masked]> 

--
       Derek Atkins                 617-623-3745 <tel:617-623-3745> 
       [email-masked] <mailto:[email-masked]>              www.ihtfp.com <http://www.ihtfp.com> 
       Computer and Internet Security Consultant

_______________________________________________
COSE mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 7 Nov 2016 17:37:34 +0100

Maybe the most reasonable solution would be to write a
complementary/extension doc for the COSE specification. Similar to what is
done with RSA so that this work can finish.

Jim, is that possible?
Laurence, do you think that would be an okay way forward?

//Samuel

On Fri, Nov 4, 2016 at 7:48 PM, Jim Schaad <[email-masked]> wrote:

> During the development of the COSE document, the creation of attributes to
> carry X.509 items was discussed.  Given the set of use cases that we had on
> our radar at the time it was decided that we did not need this at the
> time.  These were all cases where we were looking at constrained devices
> where the addition of the certificate to many messages was going to be a
> problem.  In this environment, if you were using X.509 then you would
> pre-distribute the certificates rather than carrying them in a message.
>
>
>
> If we can identify a number of cases where we would be using X.509
> certificates then I would be willing to create a document which would
> define the fields and how to use them.  It would appear that we might have
> one case, do people know of more?
>
>
>
> I don’t think we have a strong case for doing a new certificate format at
> this time, however if people think there is enough of a need then the next
> step would be for them to organize a BOF to see if they can attract enough
> attention.
>
>
>
> Jim
>
>
>
>
>
> *From:* Samuel Erdtman [mailto:[email-masked]]
> *Sent:* Friday, November 04, 2016 10:49 AM
> *To:* Derek Atkins <[email-masked]>
> *Cc:* Lundblade, Laurence <[email-masked]>; Jim Schaad <
> [email-masked]>; [email-masked]
> *Subject:* Re: [COSE] Carrying certificate chains in COSE signed messages
>
>
>
> However I think Laurence has a point in the fact that It is more
> convenient to use CBOR then ASN1 even if you formally have the bandwidth
> and capacity to process ASN1.
>
>
> I could also imagine CAs adopting new certificate formats based on CBOR
> and COSE in the future and if that happens a transition would be much
> easier if they had the option to start using COSE today.
>

---

From: "Lundblade, Laurence" <[email-masked]>
Date: Mon, 7 Nov 2016 16:46:18 +0000

I assume the actual solution here would just be an extension to and not any revision of the current COSE spec, but it would be nice to see a straw man proposal to know for sure that assumption holds.

If so, an extension doc seems just fine.

LL

On Nov 7, 2016, at 8:37 AM, Samuel Erdtman <[email-masked]<mailto:[email-masked]>> wrote:

Maybe the most reasonable solution would be to write a complementary/extension doc for the COSE specification. Similar to what is done with RSA so that this work can finish.

Jim, is that possible?

//Samuel

On Fri, Nov 4, 2016 at 7:48 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
During the development of the COSE document, the creation of attributes to carry X.509 items was discussed.  Given the set of use cases that we had on our radar at the time it was decided that we did not need this at the time.  These were all cases where we were looking at constrained devices where the addition of the certificate to many messages was going to be a problem.  In this environment, if you were using X.509 then you would pre-distribute the certificates rather than carrying them in a message.

Jim

From: Samuel Erdtman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, November 04, 2016 10:49 AM
To: Derek Atkins <[email-masked]<mailto:[email-masked]>>
Cc: Lundblade, Laurence <[email-masked]<mailto:[email-masked]>>; Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] Carrying certificate chains in COSE signed messages

//Samuel

On Fri, Nov 4, 2016 at 5:36 PM, Derek Atkins <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Why wait?

-derek

>
>
> On Nov 4, 2016, at 7:23 AM, Derek Atkins <[email-masked]<mailto:[email-masked]>> wrote:
>
>> "Lundblade, Laurence" <[email-masked]<mailto:[email-masked]>> writes:
>>
>>> From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
>>> To: Lundblade, Laurence; [email-masked]<mailto:[email-masked]>
>>>> From: COSE [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lundblade, Laurence
>>>> To: [email-masked]<mailto:[email-masked]>
--
       Derek Atkins                 617-623-3745<tel:617-623-3745>
       [email-masked]<mailto:[email-masked]>             www.ihtfp.com<http://www.ihtfp.com/>
       Computer and Internet Security Consultant

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose

---

From: Göran Selander <[email-masked]>
Date: Tue, 8 Nov 2016 15:07:57 +0000

From: COSE <[email-masked]<mailto:[email-masked]>> on behalf of Jim Schaad <[email-masked]<mailto:[email-masked]>>
Date: Friday 4 November 2016 at 19:48
To: "'Lundblade, Laurence'" <[email-masked]<mailto:[email-masked]>>
Cc: 'Samuel Erdtman' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [COSE] Carrying certificate chains in COSE signed messages

This work could be very useful.

One use case is IoT device bootstrapping/on-boarding in a network using vendor issued public key certificates installed during manufacturing and used during deployment to authenticate certificate enrolment of operational certificates. There is recent work using IEEE 802.1AR which is based on X.509, but maybe other formats are more relevant.

In any case, defining certificate enrolment using COSE would make much more sense for constrained devices compared to the proposal to use CMS. The enrolment protocol can be authenticated using transport layer security or application layer security.

Without excluding this case, it would be good to examine the feasibility of using the existing candidates in constrained devices before going forward with that.

Göran

Jim

//Samuel

Why wait?

-derek

--
       Derek Atkins                 617-623-3745<tel:617-623-3745>
       [email-masked]<mailto:[email-masked]>             www.ihtfp.com<http://www.ihtfp.com>
       Computer and Internet Security Consultant

---

From: Jim Schaad <[email-masked]>
Date: Sun, 13 Nov 2016 07:35:46 +0900

Looking at starting such a draft, a few questions have occurred to me.

*  Certificate Identification

There are several different ways that certificates have been identified over time.  Some of them are more or less successful depending on if you are interested in identifying the key or the certificate.

- Issuer/Serial Number - is unique as long as one assumes issuers are unique - assumes certificate can be found independent of the message
- Subject Public Key Identifier - identifies the key and not the certificate, however commonly used in the PKIX world as an identifier
- Hash of certificate - uniquely identifies the certificate - assumes certificate can be found independent of the message.
- The certificate - Big in terms of byte count, would normally be part of a collection as setup below
- URL to the certificate - requires a secure URL (https or similar), potentially with a protocol to return the certificate (how do you do it with coaps?) and requires a second level of certificate processing to occur.

* Certificate collections

- Ordered list of certificates - ala TLS - assumes that a common trust anchor exists - list may be truncated at any point.
- Unordered bag of certificates - ala CMS - may contain extra certificates (here is my encryption certificate as well), may be missing certificates - would require an imposed requirement of the user certificate comes first unless both a collection and an identifier are present which is the case for CMS
-  Include/omit trust anchor certificate - helps to determine if a common one exists, however also allows for the UI problems of trust this certificate to occur.

Jim

---

From: "Lundblade, Laurence" <[email-masked]>
Date: Sun, 13 Nov 2016 18:47:48 +0000

As a signing format, it seems COSE should accommodate a lot of different options for carrying the certificate collection. The trust anchor UI problem seems like an application / implementation problem, not a COSE problem.  For that I like the CMS approach.

However, having the exact chain in the right order to verify the sig certainly can make the verification implementation a lot easier. You don't need any code for certificate identification or chain formation at all. I know first hand that the chain formation code based on matching issuer/serial or such is some work.  You might even be able to not have any parent cert identification at all.

So maybe a data format carrying a bunch of certificates, but with a type indicating whether they are an unordered collection or they are the precise ordered set to verify the signature?

The simplest and smallest key identification scheme seems like Subject Public Key Identifier using a hash of the public key. You don't even need a cryptographically strong hash.

Probably stating the obvious, but one of the reasons for a cert chain is to improve security on the sign / operations side by having intermediate certs that are much less powerful than the root.  For example they might be constrained in time.  However I've found that constraints end up being specific to the system and got implemented on private extensions rather than anything in any standard.

Last, when the signing is done on a constrained device and the verification is done on a server, the constrained device may not need to implement anything using ASN.1. It just has to copy the cert chain into the COSE message. The cert is just an opaque blob.

LL

________________________________________
From: COSE <[email-masked]> on behalf of Jim Schaad <[email-masked]>
Sent: Saturday, November 12, 2016 2:35 PM
To: 'Göran Selander'; Lundblade, Laurence; 'Samuel Erdtman'
Cc: [email-masked]
Subject: Re: [COSE] Carrying certificate chains in COSE signed messages

Jim