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

[Jim Schaad <[e-mail]>]

The problem w/ trying to define a single way to do SKI is that different Cas are going to do it in different ways and that is always a problem.

 

If you are doing a certificate enrollment protocol, it is always possible to return some information back to the end point that it can use or the same purpose.  It could either return a Key Id that the client is supposed to use or it could return a hash of the certificate as we have a way to identify that as well.

 

One of the problems for certificate based people on just using the SKI for identifying the certificate is to make sure that there are not more than one certificate in the world.  If multiple certificates exist (see attacker), then it is always possible that a certificate with a different identity or set of associated attributes can be obtained when you do the indirection.  Use the hash of the certificates (even a truncated one) makes this a much harder problem to solve.

 

I am leery of doing this because of the difficulty in doing a – this is how we do SKI and it will never change – statement for implementation.  I would rather see an identifier returned as part of the enrollment protocol when a certificate is not returned.

 

jim

 

From: Laurence Lundblade [mailto:[e-mail]] 
Sent: Monday, April 17, 2017 4:58 PM
To: Samuel Erdtman <[e-mail]>
Cc: Jim Schaad <[e-mail]>; cose <[e-mail]>
Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt

 

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