Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt

From: "Lundblade, Laurence" <[email-masked]>
Date: Tue, 6 Dec 2016 02:20:58 +0000

Sorry for the delayed response and thanks for the draft.

The order definitive chain option for x5c looks pretty good. How does the kid parameter come into play? Is x5c in lieu of kid?  Seems like it would be.

Is it usual to have the data type / semantics vary for some CBOR like x5c? Haven’t run into any CBOR like that before.  Would it be better to have an x5cb (b for bag) and an x5co (o for ordered).

Thanks!

LL

On Nov 23, 2016, at 10:43 PM, Samuel Erdtman <[email-masked]<mailto:[email-masked]>> wrote:

Looks like a good start to me.

Laurence what do you think?

//Samuel

On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
This is a rough draft of what a set of X.509 headers could look like.  There is lots of things that are incomplete or missing, but I said I would write up a fast version for people to look at so here it is.

If you are interested, please comment on the headers.  The pointer to the github repository is in the document.

Jim

> -----Original Message-----
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Tuesday, November 22, 2016 7:27 PM
> To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
> Subject: New Version Notification for draft-schaad-cose-x509-00.txt
>
>
> A new version of I-D, draft-schaad-cose-x509-00.txt has been successfully
> submitted by Jim Schaad and posted to the IETF repository.
>
> Name:         draft-schaad-cose-x509
> Revision:     00
> Title:                CBOR Encoded Message Syntax (COSE): Headers for carrying
> and referencing X.509 certificates
> Document date:        2016-11-22
> Group:                Individual Submission
> Pages:                6
> URL:            https://www.ietf.org/internet-drafts/draft-schaad-cose-x509-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-schaad-cose-x509/
> Htmlized:       https://tools.ietf.org/html/draft-schaad-cose-x509-00
>
>
> Abstract:
>    This document defines the headers and usage for referring to and
>    transporting X.509 certificates in the CBOR Encoded Message (COSE)
>    Syntax.
>
> Contributing to this document
>
>    The source for this draft is being maintained in GitHub.  Suggested
>    changes should be submitted as pull requests at <https://github.com/
>    cose-wg/X509>.  Instructions are on that page as well.  Editorial
>    changes can be managed in GitHub, but any substantial issues need to
>    be discussed on the COSE mailing list.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>
> The IETF Secretariat

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 5 Dec 2016 20:16:40 -0800

Thanks for input, it is something that nobody else has actually given yet.

I could easily get behind the idea of moving to two different headers, one
for ordered and one for a bag.  I don't think that there would be a huge
problem with assigning the multiple code points.

I don't know how common/uncommon it is for fields to allow multiple types.
I do know that the COSE spec does it in a couple of places, although most of
them can be ignored at this point in time.  Personally, I don't find the
code to support that feature to be very difficult and argued that as part of
the JOSE effort when the same topic was discussed.

While it does not explicitly say that in COSE, my assumption was always that
'kid' only identified COSE based keys.  I think that is probably an invalid
assumption.  I would however expect that if an explicit key is given in the
form a certificate then a kid would not need to be present.  An application
however could state that a kid could be the spki value from a certificate so
that it could be used to find certificates if desired. I'll make a comment
to myself on that.

More comments from everybody about what is good and bad are wanted.

Jim

From: Lundblade, Laurence [mailto:[email-masked]] 
Sent: Monday, December 05, 2016 6:21 PM
To: Samuel Erdtman <[email-masked]>
Cc: Jim Schaad <[email-masked]>; cose <[email-masked]>
Subject: Re: [COSE] New Version Notification for
draft-schaad-cose-x509-00.txt

The order definitive chain option for x5c looks pretty good. How does the
kid parameter come into play? Is x5c in lieu of kid?  Seems like it would
be.

Is it usual to have the data type / semantics vary for some CBOR like x5c?
Haven't run into any CBOR like that before.  Would it be better to have an
x5cb (b for bag) and an x5co (o for ordered).

Thanks!

LL

 

On Nov 23, 2016, at 10:43 PM, Samuel Erdtman <[email-masked]
<mailto:[email-masked]> > wrote:

//Samuel

On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad <[email-masked]
<mailto:[email-masked]> > wrote:

This is a rough draft of what a set of X.509 headers could look like.  There
is lots of things that are incomplete or missing, but I said I would write
up a fast version for people to look at so here it is.

If you are interested, please comment on the headers.  The pointer to the
github repository is in the document.

Jim

> From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked] <mailto:[email-masked]> ]
> To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
> URL:
https://www.ietf.org/internet-drafts/draft-schaad-cose-x509-00.txt
> until the htmlized version and diff are available at tools.ietf.org
<http://tools.ietf.org/> .

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

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 7 Dec 2016 07:01:44 +0100

Hi Jim,

I think we should name the parameters differently x5t, x5c and x5u are used
in JOSE with slightly different semantic. This would be similar to the
"content type" in the COSE specification where cty is not used.
Since the names are not included in the encoded message it might make sense
to name them:
* x509 Certificate Thumbprint
* x509 Certificate Chain
* x509 Certificate URL

//Samuel

On Tue, Dec 6, 2016 at 5:16 AM, Jim Schaad <[email-masked]> wrote:

> for ordered and one for a bag.  I don’t think that there would be a huge
> I don’t know how common/uncommon it is for fields to allow multiple
> types.  I do know that the COSE spec does it in a couple of places,
> although most of them can be ignored at this point in time.  Personally, I
> don’t find the code to support that feature to be very difficult and argued
> that as part of the JOSE effort when the same topic was discussed.
>
>
>
> While it does not explicitly say that in COSE, my assumption was always
> that ‘kid’ only identified COSE based keys.  I think that is probably an
> invalid assumption.  I would however expect that if an explicit key is
> given in the form a certificate then a kid would not need to be present.
> An application however could state that a kid could be the spki value from
> a certificate so that it could be used to find certificates if desired.
> I’ll make a comment to myself on that.
>
>
>
> *From:* Lundblade, Laurence [mailto:[email-masked]]
> *Sent:* Monday, December 05, 2016 6:21 PM
> *To:* Samuel Erdtman <[email-masked]>
> *Cc:* Jim Schaad <[email-masked]>; cose <[email-masked]>
> *Subject:* Re: [COSE] New Version Notification for
> Haven’t run into any CBOR like that before.  Would it be better to have an
> On Nov 23, 2016, at 10:43 PM, Samuel Erdtman <[email-masked]> wrote:
>
>
>
> On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad <[email-masked]>
> wrote:
>
> This is a rough draft of what a set of X.509 headers could look like.
> There is lots of things that are incomplete or missing, but I said I would
> write up a fast version for people to look at so here it is.
>
> > From: [email-masked] [mailto:[email-masked]]
> > To: Jim Schaad <[email-masked]>
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
>
>
> [email-masked]
> [email-masked]