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

[Laurence Lundblade <[e-mail]>]

It’s been a while, but I have another scenario.

Let’s say the key pair is generated on a device, but the certificate is not on the device because the device is very constrained or there are other considerations.  The certificate is to be picked up from a server or some other part of the system infrastructure.

In that case identifying the certificate by the public key or some derivation of the public key is very helpful.  Subject Key ID from RFC 5280 section 4.2.1.2 seems exactly the right thing. The parameter name could be “x5i” or “x5ski”.

For full and standardized interop, we would have to go one step further than RFC 5280 and RFC 7093 to formally define the how the Subject Key ID is created from the key itself.  RFC 5280 only gives “common methods”.

LL



On Dec 6, 2016, at 10:01 PM, Samuel Erdtman <[e-mail]<mailto:[e-mail]>> wrote:

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 <[e-mail]<mailto:[e-mail]>> wrote:
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:[e-mail]<mailto:[e-mail]>]
Sent: Monday, December 05, 2016 6:21 PM
To: Samuel Erdtman <[e-mail]<mailto:[e-mail]>>
Cc: Jim Schaad <[e-mail]<mailto:[e-mail]>>; cose <[e-mail]<mailto:[e-mail]>>
Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Tuesday, November 22, 2016 7:27 PM
> To: Jim Schaad <[e-mail]<mailto:[e-mail]>>
> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose



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