Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt

[Laurence Lundblade]

Hi Göran,

I understand your two types of native CBOR certs, and raise you by one. I’ve 
assumed COSE because it seems a clear choice to me (no size issue, code re use).

0) Compressed/re-encoded
- Uses CBOR Sequence that exactly mirrors X.509 from Raza draft
- Reduces size of cert, but increased code complexity; both CBOR and DER 
encoding / decoding needed
- Can transform to/from X.509 mechanically without the private key

1) COSE + Mirroring with CBOR Sequence from Raza draft
- Uses the CBOR sequence that exactly mirrors X.509
- Reduces size of cert and lowers code complexity; no DER encoding / decoding
- Must have private key to generate; must be generated by the CA

2) COSE + Mirroring with CWT Claims
- A set of CWT claims are defined that exactly mirror X.509 fields
- Reduces size of cert and lowers code complexity; no DER encoding / decoding; 
can re use some CWT code
- Must have private key to generate; must be generated by the CA

3) COSE + Improved CWT Claims
- A set of CWT claims that don’t necessarily mirror X.509 exactly, but give 
similar semantics
- Reduces size of cert and lowers code complexity; no DER encoding / decoding; 
can re use some CWT code
- Must have private key to generate; must be generated by the CA

I was definitely talking about 3) in my last email. It is clearly not in the 
charter.

So maybe the debate is between 1) and 2). Both are in the charter. Some 
advantages of 2) are:
- Can re use some of the CWT code
- Can move to 3) incrementally when the time comes
- Can drop fields that are not used possibly giving the smallest cert size on 
the wire of any of the options

LL



> On Apr 28, 2020, at 3:23 AM, Göran Selander  
> wrote:
> 
> Hi Laurence,
>  
> Thanks for sharing your thoughts. It seems we are working on slightly 
> different paths.
>  
> The part you called “Compressed Certs” is already in the draft COSE charter 
> where it is referred to as “A CBOR encoding of the compressed certificate 
> profile defined in RFC 7925” so we can leave that out for now.
>  
> My comment was about the other part, what we both call “native CBOR 
> certificates” but mean different things. What is called native in
> draft-raza-ace-cbor-certificates is not intended as a certificate format 
> breaking with X.509. While there are many potential improvements to make on 
> X.509, there is a resistance against new certificate architectures as was 
> clear when this was brought up in Secdispatch at IETF 104 a year ago. As 
> mentioned previously, what we mean by “native CBOR” is the lossless 
> compression of the certificate profile of X.509 into a CBOR encoded format, 
> but signing over the CBOR instead of on the uncompressed data. In this way it 
> is possible to define a bijection between native CBOR certificates and 
> profiled X.509 certificates – the payload of the compressed version of the 
> latter would be identical to the former. So the native CBOR certificates are 
> a faithful representation of these profiled X.509 certificates, using the 
> same payload as in the CBOR compression scheme.
>  
> In contrast to the compression scheme, a conversion between native CBOR and 
> X.509 representations requires access to the private signature key.
> Therefore a mix of X.509 and native CBOR would require multiple handlers at 
> the backend (parsing the payload would be the same). Dedicated deployments 
> could of course use native CBOR certificates exclusively.
>  
> In the same way it would be possible to instead define a COSE_Sign1 and/or a 
> CWT representing these profiled X.509 certificates, this is what I thought 
> you were asking about but apparently not. That would be an alternative as 
> long as we can decide on exactly one of these representations.
>  
> There are a lot of fun things to do in this space, my concern is how to get 
> out a standard. Trying to replace X.509 doesn’t seem like a promising way 
> forward I’m afraid . . .
>  
> Göran
>  
>  
> From: Ace  on behalf of Laurence Lundblade 
> 
> Date: Monday, 27 April 2020 at 20:13
> To: Göran Selander 
> Cc: Joel Höglund , "c...@ietf.org" , 
> "ace@ietf.org" 
> Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt
> 
>> On Apr 27, 2020, at 5:00 AM, Göran Selander 
>> > > wrote:
>>  
>> [GS] The rationale for native CBOR certificates is to reuse the same 
>> encoding as in the compression scheme defined for RFC 7925, but signing the 
>> CBOR instead of signing the uncompressed data. This provides a roadmap with 
>> minimal changes when moving from compressed to native CBOR certificates.
>>  
>> I agree with you that the overhead of COSE_Sign1 or CWT is not major and 
>> these points are open for discussion. The more important question is where 
>> this should be standardized. The compression scheme is now included in the 
>> new draft charter for COSE:
>> https://github.com/cose-wg/Charter/blob/master/Charter.md 
>> 

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

What do you expect to see?   By default a client needs to know that something 
is an AS and have a key to interact with that AS.

 

Jim

 

 

From: Ace  On Behalf Of Peter van der Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: Ace 
Subject: [Ace] draft-ietf-ace-oauth-authz

 

Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource type 
(rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter 

-- 

Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org  , 
stokc...@bbhmail.nl  
www: www.vanderstok.org  
tel NL: +31(0)492474673 F: +33(0)966015248

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] draft-ietf-ace-oauth-authz

[Peter van der Stok]

Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource
type (rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter 
--

Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl
www: www.vanderstok.org [1]
tel NL: +31(0)492474673 F: +33(0)966015248 


Links:
--
[1] http://www.vanderstok.org___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace