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

[Laurence Lundblade]

Hi Jim,

Thanks for the quick comment.

On Apr 17, 2017, at 7:11 PM, Jim Schaad 
> wrote:

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.

I’m sorry I can’t share details, but I can assure you that this is not possible 
in the use case I have in mind.

I think that leaves us either with the CA and users of this scheme having to 
assume a particular way to compute SKI or inventing some typing scheme for SKIs.

Maybe that ends the conversation…



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.

This seems like a problem when you trust a lot of roots, but not so much of a 
problem when trusting just one or two proprietary roots.  Is that right?

Also, any pointer on what happened with RFC 4387 to look up and fetch certs via 
HTTP?

Thanks again,

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] A couple of COSE questions

[Laurence Lundblade]

Hello I have a few questions…

Registration of hash algs
There’s no assignments for hash algs (SHA-256.. SHA-512, SHA3-256…) in the IANA 
registry here. I 
assume this is because the COSE protocol doesn’t have a need because they are 
bundled up with the signing alg identifiers.  For non-COSE protocols that use 
CBOR and do have a need to identify a hash, would it be reasonable to add them? 
 The COSE registry seems like it is the place to register algorithm IDs for use 
in CBOR in general.  I assume the process would be to write a simple RFC, 
publish and then add to the registry.


Registration of tagging for COSE messages
Why isn’t there a registry section for the tags for these different COSE 
messages?

   COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
   COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
   COSE_Mac_Tagged / COSE_Mac0_Tagged


Tagging of bstr wrapped data
It seems like it would be helpful to use an option tag on the bstr-wrapped 
payload for COSE_Sign and such to tell general purpose parsers and translators 
to remove the bstr wrapping and keep going. Tag 55799 seems like the best fit 
so far, but it may not be a perfect fit and it would be nice to use a tag less 
than 24.

Thanks!

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] A couple of COSE questions

[Laurence Lundblade]

Thank you Jim,

A few comments below.


On Jun 15, 2017, at 2:01 PM, Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:

See in line comments

Jim


From: COSE [mailto:cose-boun...@ietf.org] On Behalf Of Laurence Lundblade
Sent: Thursday, June 15, 2017 12:58 PM
To: cose <cose@ietf.org<mailto:cose@ietf.org>>
Subject: [COSE] A couple of COSE questions

Hello I have a few questions…

Registration of hash algs
There’s no assignments for hash algs (SHA-256.. SHA-512, SHA3-256…) in the IANA 
registry here<https://www.iana.org/assignments/cose/cose.xhtml#algorithms>. I 
assume this is because the COSE protocol doesn’t have a need because they are 
bundled up with the signing alg identifiers.  For non-COSE protocols that use 
CBOR and do have a need to identify a hash, would it be reasonable to add them? 
 The COSE registry seems like it is the place to register algorithm IDs for use 
in CBOR in general.  I assume the process would be to write a simple RFC, 
publish and then add to the registry.

[JLS]  Yes the reason that there are no hash algorithms is that they were not 
needed for any of the core COSE functions.  I am in the process of registering 
two hash functions as part of ietf-schaad-cose-x509.  These are a SHA-256 and a 
truncated SHA-256.  If you want to write up a more complete RFC for this that 
would be fine with me.

SHA-256 will do for now for me.  Do you have the value for it yet?  I don’t 
have time for a more general write of more algs at the moment.




Registration of tagging for COSE messages
Why isn’t there a registry section for the tags for these different COSE 
messages?

   COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /

   COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /

   COSE_Mac_Tagged / COSE_Mac0_Tagged


[JLS] Not too sure what registry you are looking for here.  But I think you 
want this registry 
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#tags

That’s what I was looking for.



Tagging of bstr wrapped data
It seems like it would be helpful to use an option tag on the bstr-wrapped 
payload for COSE_Sign and such to tell general purpose parsers and translators 
to remove the bstr wrapping and keep going. Tag 55799 seems like the best fit 
so far, but it may not be a perfect fit and it would be nice to use a tag less 
than 24.

[JLS]  I am not sure that you would find this generically helpful.  The problem 
is that the parser needs to provide both the encoded version and the unencoded 
version if you are going to do an automatic recursion of the CBOR decoder.  You 
need the first in order to do the signature validation processing.  This means 
that there does not seem to be a real point to making the recursion occur 
automatically that I can see.  We have not provided all of the cues that would 
be needed to do a stream decode and validation at the same process ala how CMS 
does it (and even then there are cases where you need to go back and restart 
the process again).

I figured the answer would be along these lines.

To be more clear on the use case, it seems you could have a small chunk of SW 
that just does signature verification, that doesn’t really understand the 
details of the payload.  Its output is a yes or no.   Then you use a general 
purpose off-the-shelf CBOR-to-JSON translator on the payload.  It only runs if 
the sig verification passed.

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] ECIES key transport?

[Laurence Lundblade]

I'm looking for a scheme that uses elliptic curves where the sender encrypts 
and the receiver decrypts. The receiver has given the sender some key material 
out of band in a one-time exchange that is secured by some other means.  The 
sender can't decrypt with the key material given by the receiver.


I understand how to do this with RSA and CMS  -- RSA OEAP to wrap an AES CEK, 
but not yet how to do it with EC and COSE.


The integration of both integrity protection and data enveloping is nice, but 
it's mostly the data protection I'm after.


I did look at 12.4, but ephemeral-static nor static-static seem right. 12.5 
seems closer.


Thanks!


LL







From: COSE <cose-boun...@ietf.org> on behalf of Jim Schaad 
<i...@augustcellars.com>
Sent: Wednesday, November 22, 2017 10:13 PM
To: Laurence Lundblade; 'cose'
Subject: Re: [COSE] ECIES key transport?

I am not sure what you mean by this, however from the brief description on 
Wikipedia I think you are looking for the Direct ECDH algorithm w/ the AEAD 
encryption algorithm (Section 12.4).

Jim


From: COSE [mailto:cose-boun...@ietf.org] On Behalf Of Laurence Lundblade
Sent: Wednesday, November 22, 2017 1:59 PM
To: cose <cose@ietf.org>
Subject: [COSE] ECIES key transport?

Has anyone done any work on ECIES key transport for COSE?

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] Confirmation / interop for COSE Encrypt with RSA OEAP and AES GCM

[Laurence Lundblade]

We’re trying to follow RFC 8152 + RFC 8230 to do COSE Encryption with RSA OEAP 
and AES GCM. Basically we have an RSA-based X.509 certificate hierarchy that 
we’ve been using with CMS to do blob encryption and want to move to COSE.

RFC 8230 has no example like the ones in 8152 for EC-based encryption.  We also 
haven’t found any other code to interop with. We’re looking for some 
confirmation / interop that we got it right.

Below is an example we’ve produced (this can be used for an example in an RFC 
if desired).

What we find not very clear is what the actual bytes encrypted by the RSA OEAP 
operation should be. In the example below it is the raw CEK and as far we can 
tell this is correct. We’re NOT creating a Enc_structure for the input to the 
RSA operation (we are for the input to AES GCM).

We think RSA OEAP is an instance of Key Transport as mentioned in section 12.3 
in RFC 81512 and thus there are no protected headers in the recipient 
structure. RSA OEAP has no way to authenticate the protected headers so there 
are none.

Would appreciate confirmation that this is all correct and/or some SW to 
interop with. Thanks!

LL






The payload encrypted is the 7 byte string “payload”.

d8 60 84 43 a1 01 03 a1 05 4c a5 72 c6 a0
a8 37 7d 1f 05 82 25 d4 57 94 1b 7b 1f 83 c1 af
52 5b f1 b8 b8 bb f3 cf 1c a6 b7 05 8f eb c9 1d
81 83 40 a2 01 38 28 04 45 6b 65 79 49 44 59 01
00 9b 54 74 8a 11 07 a0 ee e7 8f 93 3b 48 46 e8
98 7f b9 97 45 1f fd 14 80 3f 1b b2 b5 fc c3 44
72 5d 0e 31 13 8d cf 3c 6c 0f db ef 83 61 84 c3
cf 15 86 55 9c 53 1b 69 1f 74 eb 0e ce 7a 47 47
1b 5d 41 11 97 43 02 86 44 bb e5 e1 0d 60 ad 44
c7 55 0a d5 7d f4 30 9f e4 05 e9 52 1d 67 0d d6
52 31 8a bb 6e 15 5e 35 fa 53 b9 89 d2 9a 1e 2a
15 c3 87 75 24 0d d0 82 ef b3 6d 08 f1 c5 77 e0
30 5c 78 f5 81 d5 c8 44 44 83 8f f8 9c 53 52 72
a5 e9 85 c8 9e 8f fe 4f 1d 77 83 e2 b8 7c 7e ab
36 12 73 89 5d 61 90 6a 6f 2c da 02 17 72 66 ad
ed 88 6b e7 56 f9 f7 7e 31 3c 50 d8 d1 15 7b f8
42 fc 09 da 6f 40 35 fc cd 8d 12 63 02 5f 3b 53
49 21 aa db 55 38 1b ab 17 ea 21 5b 73 d2 50 5d
71 7f 79 0a d7 ba 0c da 75 f8 2d ca 8c 8a c2 79
78 a8 ea 28 bb f7 81 1e 74 c0 d1 55 64 da d8 aa
ad


  97(
[
  / protected / h'A10103' / {
  \ alg \ 1:3 \ AES-GCM mode w/ 256-bit key, 128-bit tag \
} / ,
  / unprotected / {
/ iv / 5:h'A572C6A0A8377D1F058225D4'
  },
  / ciphertext / h'941B7B1F83C1AF525BF1B8B8BBF3CF1CA6B7058FEBC91D',
  / recipients / [
[
  / protected / h'',
  / unprotected / {
/ alg / 1:-41 / RSAES-OAEP w/ SHA-256 /,
/ kid / 4:'keyID'
  },
  / ciphertext / 
h'9B54748A1107A0EEE78F933B4846E8987FB997451FFD14803F1BB2B5FCC34472
   
5D0E31138DCF3C6C0FDBEF836184C3CF1586559C531B691F74EB0ECE7A47471B
   
5D41119743028644BBE5E10D60AD44C7550AD57DF4309FE405E9521D670DD652
   
318ABB6E155E35FA53B989D29A1E2A15C38775240DD082EFB36D08F1C577E030
   
5C78F581D5C8838FF89C535272A5E985C89E8FFE4F1D7783E2B87C7EAB36
   
1273895D61906A6F2CDA02177266ADED886BE756F9F77E313C50D8D1157BF842
   
FC09DA6F4035FCCD8D1263025F3B534921AADB55381BAB17EA215B73D2505D71
   
7F790AD7BA0CDA75F82DCA8C8AC27978A8EA28BBF7811E74C0D15564DAD8AAAD'
]
  ]
]
  )


RSA Key Material:

key bits = 2048

n = 
h'ae45ed5601cec6b8cc05f803935c674ddbe0d75c4c09fd7951fc6b0caec313a8df39970c518bff
  
ba5ed68f3f0d7f22a4029d413f1ae07e4ebe9e4177ce23e7f5404b569e4ee1bdcf3c1fb03ef113
  
802d4f855eb9b5134b5a7c8085adcae6fa2fa1417ec3763be171b0c62b760ede23c12ad92b9808
  
84c641f5a8fac26bdad4a03381a22fe1b754885094c82506d4019a535a286afeb271bb9ba592de
  
18dcf600c2aeeae56e02f7cf79fc14cf3bdc7cd84febbbf950ca90304b2219a7aa063aefa2c3c1
  
980e560cd64afe779585b6107657b957857efde6010988ab7de417fc88d8f384c4e6e72c3f943e
  0c31c0c4a5cc36f879d8a3ac9d7d59860eaada6b83bb'

p = h''

q = h''

e = 
h'00
  
00
  
00
  010001'

d = 
h'056b04216fe5f354ac77250a4b6b0c8525a85c59b0bd80c56450a22d5f438e596a333aa875e291
  
dd43f48cb88b9d5fc0d499f9fcd1c397f9afc070cd9e398c8d19e61db7c7410a6b2675dfbf5d34
  
5b804d201add502d5ce2dfcb091ce9997bbebe57306f383e4d588103f036f7e85d1934d152a323
  
e4a8db451d6f4a5b1b0f102cc150e02feee2b88dea4ad4c1baccb24d84072d14e1d24a6771f740
  
8ee30564fb86d4393a34bcf0b788501d193303f13a2284b001f0f649eaf79328d4ac5c430ab441
  
4920a9460ed1b7bc40ec653e876d09abc509ae45b525190116a0c26101848298509c1c3bf3a483
  e7274054e15e97075036e989f60932807b5257751e79'
___
COSE mailing list
COSE@ietf.org

Re: [COSE] Digests (hashes) in COSE?

[Laurence Lundblade]

I have used an alg id for a plain hash in a CBOR/COSE implementation.  Without 
going into details it was a special-purpose singing scheme. I ended up using an 
id in the for-private-use space. 

My use aside, it seems helpful and useful to have SHA-256, 384... and friends 
in the COSE IANA registry. 

LL


From: COSE  on behalf of Jim Schaad 

Sent: Tuesday, February 27, 2018 4:48 PM
To: 'Carsten Bormann'; cose@ietf.org
Subject: Re: [COSE] Digests (hashes) in COSE?

I need to re-publish my document with hash algorithms, however I am not sure 
what needs to be placed in this structure in some ways.

Is there something beyond

MAC = [
Digest : bstr,
Algorithm: alg_id
]

If you start trying to carry the content you end up with problems because it is 
just as often pointed to.  Not sure that putting the pointer in the digest 
computation would make sense as this value often chances as well.

Are you thinking of something specific that should be part of this?

I am not sure just how strong the demand is for parametrized hash algorithms 
is.  I have used a couple in my lifetime, but always as cases to see what would 
happen and have never used one in the wild.

Jim


> -Original Message-
> From: COSE [mailto:cose-boun...@ietf.org] On Behalf Of Carsten Bormann
> Sent: Monday, February 26, 2018 9:01 AM
> To: cose@ietf.org
> Subject: [COSE] Digests (hashes) in COSE?
>
> I think that has come up before, but today in the SUIT WG Interim we briefly
> discussed a structure where it would be useful to contain multiple unkeyed
> digests (hashes) in one signed claim (*).  In COSE, we have a registry for
> keyed MAC schemes, but not for hashes.  We also don’t have a COSE_Digest
> structure (which would be quite simple, I believe) either (**).
>
> To avoid everyone defining their own way of describing hashes, should we
> be setting this up for COSE?
> We would have to be fast to be relevant for SUIT.
>
> Grüße, Carsten
>
> (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4
> (**) maybe a bit like CMS digestedData, but simpler of course
>
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Call for Adoption of draft-schaad-cose-x509 Document

[Laurence Lundblade]

I support from the perspective of EAT / RATS and similar use cases for this 
from when I was previously at Qualcomm.

Perhaps tangental to the main point of this draft, I would like to see alg ids 
for SHA-384 and SHA-512 too. 

LL


> On Jan 16, 2019, at 7:48 AM, ivaylo petrov  wrote:
> 
> Dear WG,
> 
> This message begins the call for adoption of the following draft:
> 
> * draft-schaad-cose-x509-03
>   - https://tools.ietf.org/html/draft-schaad-cose-x509-03 
> 
> 
> We would like to remind you that adoption does not mean they are finished, 
> only that they are an acceptable starting point.
> 
> If you have read the draft, please indicate whether you support adopting that 
> documents as working group items. If you see any problem with adopting it or 
> have any other comment, please tell us.
> 
> This call will run approximately two weeks, ending January 28.
> Please respond before that date.
> 
> Best regards,
> 
> - Matthew and Ivaylo
> COSE Working Group Chairs
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] I-D Action: draft-ietf-cose-hash-sig-06.txt

[Laurence Lundblade]

Hi

The examples are good now, but it still uses “COSE_SIgn0” instead of 
“COSE_Sign1”.  Just need:

s/COSE_Sign0/COSE_Sign1/

(I believe the origin of this is that COSE-C has lots of APIs and such that are 
named COSE_SIgn0. It was before my time with COSE, but I believe COSE_Sign1 
uses to be COSE_Sign0 in the old pre-RFC drafts. COSE-C hasn’t been updated 
since the name was changed so it is still on the old incorrect name).

LL


> On Nov 1, 2019, at 6:51 PM, Russ Housley  wrote:
> 
> This version puts the examples in the format used in RFC 8152 as requested by 
> Laurence Lundblade.  Many thanks to Jim Schaad for doing the actual examples.
> 
> Russ
> 
> 
>> On Nov 1, 2019, at 9:48 PM, internet-dra...@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the CBOR Object Signing and Encryption WG of 
>> the IETF.
>> 
>>   Title   : Use of the HSS/LMS Hash-based Signature Algorithm 
>> with CBOR Object Signing and Encryption (COSE)
>>   Author  : Russ Housley
>>  Filename: draft-ietf-cose-hash-sig-06.txt
>>  Pages   : 15
>>  Date: 2019-11-01
>> 
>> Abstract:
>>  This document specifies the conventions for using the Hierarchical
>>  Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
>>  signature algorithm with the CBOR Object Signing and Encryption
>>  (COSE) syntax.  The HSS/LMS algorithm is one form of hash-based
>>  digital signature; it is described in RFC 8554.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-cose-hash-sig-06
>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-sig-06
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-sig-06
>> 
>> 
>> 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.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
> 

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] AD review of draft-ietf-cose-hash-sig-03

[Laurence Lundblade]

Well I understand better — this is JSON formatted inputs / outputs for a test 
suite used by COSE-C?

But still…

What is a COSE_Sign0? Everywhere I look, I see it is a deprecated name for a 
COSE_SIgn1.

Shouldn’t the examples here look like the examples in RFC 8152? Should this use 
a new style for examples?

LL


> On Oct 10, 2019, at 5:23 PM, Jim Schaad  wrote:
> 
> No that would be the format that I use in the examples with all of the inputs 
> as well.  You should just use the cbor_diag field, and read section 8 of the 
> CBOR draft for how multiple lies are done.
>  
> From: COSE mailto:cose-boun...@ietf.org>> On Behalf 
> Of Laurence Lundblade
> Sent: Thursday, October 10, 2019 4:05 PM
> To: Russ Housley mailto:hous...@vigilsec.com>>
> Cc: Roman D. Danyliw mailto:r...@cert.org>>; Ivaylo Petrov 
> mailto:iva...@ackl.io>>; Ben Kaduk  <mailto:ka...@mit.edu>>; cose mailto:cose@ietf.org>>
> Subject: Re: [COSE] AD review of draft-ietf-cose-hash-sig-03
>  
>  
>> On Oct 10, 2019, at 1:24 PM, Russ Housley > <mailto:hous...@vigilsec.com>> wrote:
>>  
>>   This appendix provides an example of a COSE full message signature
>>   and an example of a COSE_Sign0 message.  The display format includes
>>   "\" to indicate that the same field continues on the next line, and it
>>   includes "|" to separate items within a field.
> 
>  
> Doesn’t COSE only have a COSE_Sign1?  COSE_Sign0 is mentioned as wrong in 
> errata.
>  
> The example in A.2 doesn’t look like a COSE_Sign1 at all.
>  
> LL
>  
> ___
> COSE mailing list
> COSE@ietf.org <mailto:COSE@ietf.org>
> https://www.ietf.org/mailman/listinfo/cose 
> <https://www.ietf.org/mailman/listinfo/cose>
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

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

[Laurence Lundblade]

> 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 
> 
> The charter is currently not explicitly supporting native CBOR certificates. 
> If you think it should, in some variant, then this is a good time to raise 
> your voice.

To go straight to the issue, I think a designing a native CBOR cert should be 
approached differently than compressing / re-encoding an X.509 cert:

Re-encoding
- Size is important
- Exact compatibility is required
- Near zero change to fields and semantics

Native CBOR Cert
- Clean up some of the mess in X.509; it is an old standard with a lot of cruft 
and baggage
- Re design extensions so they are in CBOR format
- Make many of the fields optional, for example not before can often be left 
off, maybe even serial number
- Avoid DN structure for issuer and subject for most use cases
- Use modern formats like COSE and CWT and COSE_Key
- Size is important, but far from the only goal (some size reductions, like 
optional fields will be possible here that are not possible with re-encoding)
- Compatibility matters, but not in the same way

Seems like the right thing to do here is to remove native CBOR certs from this 
document and just focus on compression and re-encoding. Maybe even call them 
“Compressed Certs” rather than “CBOR Certs”. Where that work should go is above 
my pay grade.


BUT, my main interest here relates to CWT and EAT. CWT seems like a really good 
choice on which to base a native CBOR cert. Some of the fields for an X.509 
cert are already defined in CWT (subject, issuer, expiration, not-before). It 
has an extension mechanism built in already in the CWT IANA registry. The 
crypto and signing are well-handled by CWT’s use of COSE.

In work to fit EAT  in as a 
CWT, a few issues have come up — how fields / claims are managed and registered 
with IANA, label spaces and other.  All these issues would apply to 
CWT/COSE/CBOR-based certificate as well. 

To name just one issue, in CWT the expiration date/time can be a floating-point 
number, which is burdensome, not useful. Should we change CWT to disallow or 
should it just be disallowed when a CWT is used as an EAT and when it is used 
as a Cert?

I’m also excited at the idea of re using CWT in a simple form so there is re 
use of code between CWT, EAT and native CBOR certs. I’ve started playing with 
an implementation like this.

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

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

[Laurence Lundblade]

> On Apr 24, 2020, at 5:01 AM, Joel Höglund  wrote:
> 
> > But of most interest to me is whether the COSE was considered as the
> > signing format for native CBOR certs. If COSE is used, then this looks
> > almost identical to CWT and may be a native CBOR cert is a variant of
> > a CWT? … … 
> 
> Our starting point has been to stay close to the original X.509 format while 
> minimizing size. A COSE encoding would re-add some format overhead (close to 
> 10% for the provided example certificate). But if a COSE encoding would help 
> making the format accepted and used, it can definitely be further discussed.
> 
> Once again, thank you for your comments!

Hi Joel,

I’m just focusing on the native CBOR cert here.

The overhead for COSE_Sign1 to encode the algorithm ID, key id (optional), 
payload, and signature is tiny and is fixed. If you assume each of these (IDs, 
payload, sig) already have to be a CBOR-encoded integer or string, then the 
overhead is probably less than ten bytes total, maybe even less than five for 
the COSE structure that groups them.

In your example A.3, I don’t see how the to-be-signed bytes are identified. 
Some solution, probably using bstr wrapping is needed. COSE solves with no more 
overhead than necessary.  (You don’t need this in example A.2, because you 
reconstruct the X.509 ASN.1/DER which does identify the to-be-signed bytes).

I’m not sure where you got the 10% number, but it seems high. Also, the COSE 
overhead is fixed, not proportional to the size of the certificate.


To go on a little more, in the ASN.1 world, X.509 certs didn’t use CMS 
structure for signing which meant they couldn’t share implementations. Seems 
like X.509 and CMS were developed separately. Also, CMS isn’t that compact.

However, COSE_Sign1 is very compact and efficient. If it could be used for a 
native CBOR cert format, then COSE code can be re used. In use cases like 
signed SW updates and secured boot that use certificate chains, both the 
certificate chain and the signed SW updates would use the COSE format and share 
for verifying signatures. 

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Ace] 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 , "cose@ietf.org" , 
> "a...@ietf.org" 
> Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt
> 
>> On Apr 27, 2020, at 5:00 AM, Göran Selander 
>> > <mailto:goran.selander=40ericsson@dmarc.ietf.org>> 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. 

Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT)

[Laurence Lundblade]

This is true, right? The relying party (the receiver) always has to validate 
the certificate chain up to a trust anchor even if it is a constrained device. 
The sender only has to insert certificates into the header, not validate, even 
if it is a non-constrained device. This is true of CMS, TLS and so on. There is 
nothing new or unique here right?

For example, if a constrained device is verifying code signatures, trusted boot 
chains or SUIT manifests, it has to fully validate the certificate chain up to 
a trust anchor. 

This paragraph is true for some use cases like CWT and Attestation, but not all 
use cases.

   It is not necessarily expected that constrained devices will fully
   support the evaluation and processing of X.509 certificates, it is
   perfectly reasonable for a certificate to be assigned to a device
   which it can then provide to a relying party along with a signature
   or encrypted message, the relying party not being a constrained
   device.

It is the requirements and design of the end-end system that determines what 
the constrained device has to do or not do, not the design of these headers. 
Probably it is an overreach to discuss end-end system designs. Maybe it is just 
better to remove this paragraph?

LL


> On Oct 12, 2020, at 2:32 PM, Michael Richardson  wrote:
> 
> 
> Martin Duke  wrote:
>> Your proposed sentence is an improvement, but I'm not sure how it combines
>> with the earlier sentence "It is not necessarily expected that constrained
>> devices themselves will evaluate and process of X.509 certificates". Is
>> "evaluate and process" a different action than "validating" it?
> 
> Validating is a well defined, complex process (RFC6125, etc.) involving path 
> validation, etc.
> Evaluate might mean something less, such as extracting the public key and
> comparing against some known value.  We don't expect any of that.
> 
>> Or is the suggestion here that the constrained device is given a
>> certificate to authenticate itself that it does not bother to verify, but
>> hosts that connect to it *would* validate the certificate?
> 
> Yes, generally, that is what a lot of us have in mind.
> 
> The constrained device has a credential, if in the form of an IDevID or
> LDevID certificate, then it would use this specification to places it into
> the COSE object as a blob.
> 
> It has the private key side in a format that is more convenient for
> processing (perhaps even in a secure enclave of some kind) which it uses to
> sign.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] draft-ietf-cose-x509-07 examples

[Laurence Lundblade]

draft-ietf-cose-x509-07 says:

   Example COSE messages for the various header parameters defined below
   can be found at https://github.com/cose-wg/Examples 
.


When I looked, I couldn’t find any (to help me answer other questions posted 
here). I grepped through all the JSON for 509, x5bag, x5u… and got no hits.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Ace] Gap in registration of application/cwt?

[Laurence Lundblade]

In a CBOR thread it became clear (to me anyway) that in the context of CBOR a 
“tag" is not a prefix, badge, identifier or such. It is the combination of the 
identifier and the content. In the CBOR context when you say “tag 1” or 
“epoch-based date tag” you mean the major type 6 and the number content.  The 
encoded CBOR for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00.

RFC 8392 uses the terminology incorrectly in section 5 
<https://tools.ietf.org/html/rfc8392#section-5>. It refers to the tag as a 
prefix. Maybe errata should be filed on this?


Going back to the identification of a CWT and/or COSE, my understanding is that 
a “CWT” is a protocol message. A “CWT Tag” is a type 6 item value 61 and the 
CWT protocol message.  The definition of the CWT protocol message stands apart 
from the definition of tag 61. (This is not true of a tag 1 epoch date; the 
definition of the date is intwined with the definition of tag 1).

I believe the definition of the CWT protocol message allows the type of COSE 
used to secure it to be identified in many ways. You can do it with CBOR tags 
or you can do with externally such as my Application/CWT; cose-type=COSE_Sign1 
content type example.

Further, I think nesting of COSE works as follows. It doesn’t have to be 
identified with COSE tags. Several levels of COSE can be required by some top 
level media type or even by some CBOR tag that is not a COSE defined tag. For 
example, I could define application/very-secure-string as follows.
  - Start with string of bytes
  - Encrypt it with COSE_Encrypt (the string of bytes is the payload) (note 
that this is not COSE_Encrypt_Tagged)
  - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this is not 
COSE_Sign1_Tagged
  - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that this is 
not COSE_Mac0_Tagged)

I could make the payload at some level in this example some newly defined tag 
that requires a COSE_Sign1 with EdDSA and indicates something about its payload 
format.

LL





> On Aug 15, 2020, at 11:42 AM, Jim Schaad  wrote:
> 
>  
>  
> From: Laurence Lundblade  <mailto:l...@island-resort.com>> 
> Sent: Saturday, August 15, 2020 10:58 AM
> To: Jim Schaad mailto:i...@augustcellars.com>>
> Cc: cose mailto:cose@ietf.org>>; Ace Wg  <mailto:a...@ietf.org>>
> Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?
>  
>  
> 
> 
>> On Aug 14, 2020, at 3:35 PM, Jim Schaad > <mailto:i...@augustcellars.com>> wrote:
>>  
>>  
>>  
>> From: Laurence Lundblade > <mailto:l...@island-resort.com>> 
>> Sent: Friday, August 14, 2020 1:59 PM
>> To: Jim Schaad mailto:i...@augustcellars.com>>
>> Cc: Ace Wg mailto:a...@ietf.org>>; cose > <mailto:cose@ietf.org>>
>> Subject: Re: [COSE] Gap in registration of application/cwt?
>>  
>> Here’s a series of scenarios that I think are legal CWT. These are allowed 
>> by RFC 8392, right?
>>  
>> 1) Explicitly tagged, no external type info needed
>> - Has CWT tag
>> - Has COSE type tag
>> [JLS] Yes
>>  
>> 2) CWT identification by label, COSE type tagged
>> - The CWT is a CBOR data item with a label. The definition of the label says 
>> the contents of the label are always CWT
>> - No CWT tag necessary as it is implied by the label
>> - Has a COSE type tag
>> [JLS] Yes, the label could be internal to the CBOR object or external such 
>> as an media-type
>  
> I was being very specific with the term label, meaning a label/key 
> identifying an item in a CBOR map.
> 
> 
>>  
>> 3) CWT and COSE by label
>> - The CWT is an item with a label. The definition of the label says the 
>> contents of the label are always CWT and of a specific COSE type
>> - No tags necessary
>> [JLS] Yes that would be fine
>>  
>> 4) Application/CWT identifies content as CWT, tagging for COSE type
>> - No CWT tag
>> - Has a COSE tag
>> [JLS] This is the same as 2?  I don’t think that it would be restricted to 
>> just that media type.
>  
> You mean there could be other media types that also identify the content as 
> CWT?
> [JLS] Yes this could be done in the future.   One would normally expect this 
> to be an application specific profile, but funny things happen.
>>  
>> 5) Application/CWT identifies content as CWT
>> - Has CWT tag even though it is redundant 
>> - Has a COSE tag
>> [JLS] Yes
>  
> Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag should 
> not be present.
> [JLS] For deterministic encoding, but not  for general encoding.
>>  
>> 6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …)
>> - No tags are used
&

Re: [COSE] Gap in registration of application/cwt?

[Laurence Lundblade]

Here’s a series of scenarios that I think are legal CWT. These are allowed by 
RFC 8392, right?

1) Explicitly tagged, no external type info needed
- Has CWT tag
- Has COSE type tag

2) CWT identification by label, COSE type tagged
- The CWT is a CBOR data item with a label. The definition of the label says 
the contents of the label are always CWT
- No CWT tag necessary as it is implied by the label
- Has a COSE type tag

3) CWT and COSE by label
- The CWT is an item with a label. The definition of the label says the 
contents of the label are always CWT and of a specific COSE type
- No tags necessary

4) Application/CWT identifies content as CWT, tagging for COSE type
- No CWT tag
- Has a COSE tag

5) Application/CWT identifies content as CWT
- Has CWT tag even though it is redundant 
- Has a COSE tag

6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …)
- No tags are used
- Identification is completely by the MIME type header
- (I understand that the cose-type MIME parameter is not defined, but it could 
be. 8392 doesn’t forbid it)

7) A protocol like FIDO identifies a protocol element that is an attention type 
the type of which is CWT with COSE_Sign1
- No tags are used

8) A protocol like FIDO identifies a protocol element that is an attention type 
the type of which is CWT; the COSE type is determined by tag
- No CWT tag
- Has a COSE tag

The one thing you can’t do is have a CWT tag without a COSE type tag. 8392 
section 6 forbids this.

LL





> On Aug 11, 2020, at 12:20 PM, Laurence Lundblade  
> wrote:
> 
> 
> 
>> On Aug 10, 2020, at 5:49 PM, Jim Schaad > <mailto:i...@augustcellars.com>> wrote:
>> 
>> This is all based on my understanding that the surrounding protocol for must 
>> specify exactly when CBOR tags are to be used and when they are not to be 
>> used and that the surrounding protocol must not leave it as an optional 
>> implementation choice. In this case application/cwt is the supporting 
>> protocol.
>>  
>> [JLS] What is the text that says that this is true.  This would be a 
>> surprising statement for me.
> 
> Here’s three things that lead me to this.
> 
> CBORbis
> The sentence of the first paragraph in 4.2.2 
> <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14#section-4.2.2> very 
> clearly states this, though this is only for deterministic encoding.
> 
> Typical CDDL
> Most CDDL that describes tagged data describes it only as tagged or untagged, 
> not as optionally tagged.  COSE is one example of this. 
> 
> Email threads
> This thread 
> <https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1=Hz7VjeBab9DxPas9E5_KfOmZwN0>
>  and this thread 
> <https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1=y1EZ-IylFpJ3_MndQGADSbKhx0s>.
> 
> I summarized this behavior in this email 
> <https://mailarchive.ietf.org/arch/msg/cbor/Hz7VjeBab9DxPas9E5_KfOmZwN0/> and 
> no where in the rest of the thread was it indicated differently.
> 
> So, it is not a hard requirement because 4.2.2 is only for deterministic 
> encoding, but seems like a “should" in spirit. It is the preferred way to 
> design a CBOR protocol.
> 
> However you slice it, I think it is up to the surrounding protocol to say 
> whether a tag is always required, never required or optionally required. If 
> the protocol doesn’t say, then it defaults to optionally required.
> 
> Defaulting or explicitly allowing optional tagging means the receiver has to 
> allow for all the tagging scenarios and makes possible the error case where 
> the surrounding protocol says the data is of one type and the tag conflicts 
> with it. (e.g. an application/cwt that contains a tagged CoSWID).
> 
> I don’t think optional tagging is of any advantage in a protocol design. It 
> doesn’t enable anything.
> 
> It has some disadvantage because it introduces error conditions and potential 
> confusion.
> 
> I think there are several scenarios with section 6 and application/cwt that 
> could be more clear.
> 
> Can you use tag 61 or not? I think the current answer is that in 
> application/cwt, tag 61 is optional.
> 
> How do you know what the COSE type is? It is somewhat obvious that COSE tags 
> will work, but there is no requirement to use them. A MIME parameter or other 
> is entirely allowed here.
> 
> Section 6 does say that determination that something is a CWT is application 
> dependent, but doesn’t say that the COSE type is also application dependent. 
> Section 7 does address this.
> 
> Said another way, my fully general CWT decoder that is called by some 
> application needs an input parameter to indicate the COSE type because there 
> is no requirement in 8392 that a CWT indicate which COSE type is in use. 
> Sometimes the caller will be able

Re: [COSE] [Ace] Gap in registration of application/cwt?

[Laurence Lundblade]

> On Aug 14, 2020, at 3:35 PM, Jim Schaad  wrote:
> 
>  
>  
> From: Laurence Lundblade  <mailto:l...@island-resort.com>> 
> Sent: Friday, August 14, 2020 1:59 PM
> To: Jim Schaad mailto:i...@augustcellars.com>>
> Cc: Ace Wg mailto:a...@ietf.org>>; cose  <mailto:cose@ietf.org>>
> Subject: Re: [COSE] Gap in registration of application/cwt?
>  
> Here’s a series of scenarios that I think are legal CWT. These are allowed by 
> RFC 8392, right?
>  
> 1) Explicitly tagged, no external type info needed
> - Has CWT tag
> - Has COSE type tag
> [JLS] Yes
>  
> 2) CWT identification by label, COSE type tagged
> - The CWT is a CBOR data item with a label. The definition of the label says 
> the contents of the label are always CWT
> - No CWT tag necessary as it is implied by the label
> - Has a COSE type tag
> [JLS] Yes, the label could be internal to the CBOR object or external such as 
> an media-type

I was being very specific with the term label, meaning a label/key identifying 
an item in a CBOR map.

>  
> 3) CWT and COSE by label
> - The CWT is an item with a label. The definition of the label says the 
> contents of the label are always CWT and of a specific COSE type
> - No tags necessary
> [JLS] Yes that would be fine
>  
> 4) Application/CWT identifies content as CWT, tagging for COSE type
> - No CWT tag
> - Has a COSE tag
> [JLS] This is the same as 2?  I don’t think that it would be restricted to 
> just that media type.

You mean there could be other media types that also identify the content as CWT?

>  
> 5) Application/CWT identifies content as CWT
> - Has CWT tag even though it is redundant 
> - Has a COSE tag
> [JLS] Yes

Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag should 
not be present.

>  
> 6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …)
> - No tags are used
> - Identification is completely by the MIME type header
> - (I understand that the cose-type MIME parameter is not defined, but it 
> could be. 8392 doesn’t forbid it)
> [JLS] Yes you could do that, and as I stated in a previous mail this is not a 
> good idea for the CoAP world.
>  
> 7) A protocol like FIDO identifies a protocol element that is an attention 
> type the type of which is CWT with COSE_Sign1
> - No tags are used
> [JLS] yes
>  
> 8) A protocol like FIDO identifies a protocol element that is an attention 
> type the type of which is CWT; the COSE type is determined by tag
> - No CWT tag
> - Has a COSE tag
> [JLS] yes
>  
> The one thing you can’t do is have a CWT tag without a COSE type tag. 8392 
> section 6 forbids this.
>  
> [JLS] There however is a set of nested cases that you might need to look at.  
> That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign ))  You would also need to 
> think about the requirements for nested COSE layers.

All but the most outer COSE type are always identified by a tag, per 7.1 step 5 
and 7.2 step 6, right?

LL


>  
> Jim
>  
>  
> LL
>  
>  
>  
>  
> 
> 
>> On Aug 11, 2020, at 12:20 PM, Laurence Lundblade > <mailto:l...@island-resort.com>> wrote:
>>  
>>  
>> 
>> 
>>> On Aug 10, 2020, at 5:49 PM, Jim Schaad >> <mailto:i...@augustcellars.com>> wrote:
>>>  
>>> This is all based on my understanding that the surrounding protocol for 
>>> must specify exactly when CBOR tags are to be used and when they are not to 
>>> be used and that the surrounding protocol must not leave it as an optional 
>>> implementation choice. In this case application/cwt is the supporting 
>>> protocol.
>>>  
>>> [JLS] What is the text that says that this is true.  This would be a 
>>> surprising statement for me.
>> 
>>  
>> Here’s three things that lead me to this.
>>  
>>> CBORbis
>>> The sentence of the first paragraph in 4.2.2 
>>> <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14#section-4.2.2> very 
>>> clearly states this, though this is only for deterministic encoding.
>>>  
>>> Typical CDDL
>>> Most CDDL that describes tagged data describes it only as tagged or 
>>> untagged, not as optionally tagged.  COSE is one example of this. 
>>>  
>>> Email threads
>>> This thread 
>>> <https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1=Hz7VjeBab9DxPas9E5_KfOmZwN0>
>>>  and this thread 
>>> <https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1=y1EZ-IylFpJ3_MndQGADSbKhx0s>.
>>>  
>>> I summarized this behavior in this email 
>>> <https://mailarchive.ietf.org/arch/msg

Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-x509-07: (with COMMENT)

[Laurence Lundblade]

> On Oct 21, 2020, at 1:27 PM, Benjamin Kaduk  wrote:
> 
> On Wed, Oct 21, 2020 at 12:54:44PM -0700, Laurence Lundblade wrote:
>> 
>>> On Oct 21, 2020, at 10:58 AM, Benjamin Kaduk via Datatracker 
>>>  wrote:
>>> 
>>>  x5t:  This header parameter provides the ability to identify an X.509
>>> certificate by a hash value.  The attribute is an array of two
>>> 
>>> I suggest using the word "thumbprint" somewhere to motivate the 't' in
>>> "x5t”.
>> 
>> Using “thumbprint” makes sense to me, though it was changed from thumbprint 
>> to fingerprint in March 
>> <https://github.com/cose-wg/X509/commit/32c2bf2b2411250f6d9232b43ae0813ac9d88a44>.
>>  
> 
> My point was more that we're effectively tied to the "x5t" symbol for JOSE
> parity, and even if we want to call the thing it carries a "fingerprint",
> we should still use the word "thumbprint" once to explain the mnemonic
> value of the 't’.

Makes sense.

> 
>> Is it the common understanding that this “x5t” identifies the end-entity 
>> cert like subjectKeyIdentifier does for CMS 
>> <https://tools.ietf.org/html/rfc5652#section-5.3>? I can’t imagine what else 
>> it would identify, but it seems saying this explicitly would be helpful. CMS 
>> certainly is explicit and detailed on this.
> 
> That's what I assumed, but probably worth a mention (one could, of course,
> identify a CA by fingerprint as well).

The identification of the CA(s) would be in the X.509 certs in the Subject Key 
Identifier or such. Don’t think x5t would ever identify a CA (unless the cert 
is both an end-entity and CA cert).

I worry a little about ambiguity if you receive a COSE with an x5chain, an 
x5bag and an x5t.  In particular x5t and x5chain both identify the end-entity 
cert. Which has precedence? Since the point of x5chain is to avoid the work of 
cert path construction, I’d say that if it is present, use that. If x5chain 
processing fails, the whole processing fails. If every (constrained node) 
implementation must fall back to cert path construction using x5bag, then there 
would be no savings in using x5chain.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] draft-ietf-cose-x509-07 open GitHub issues, PEM, DER and x5t parameter

[Laurence Lundblade]

I went through my open GitHub issues on cose-x509 
 and closed a few, but a few remain.  
The comments on the issue diverged from their titles, but still seem valuable. 
They come down to two things.

1) There is agreement that only certs in the DER format is allowed. However, 
cose-x509-07 doesn’t seem to say that.

2) Confusion over the x5t parameter. I think it is to identify the end-entity 
cert in an x5bag or out of a collection fetched by URI or a collection the 
relying party already has, but I’m not sure from the text. (Maybe it is just my 
misunderstanding or misreading something).

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT)

[Laurence Lundblade]

> On Oct 19, 2020, at 11:58 PM, Carsten Bormann  wrote:
> 
> On 2020-10-19, at 19:45, Laurence Lundblade  wrote:
>> 
>> It is the requirements and design of the end-end system that determines what 
>> the constrained device has to do or not do, not the design of these headers. 
>> Probably it is an overreach to discuss end-end system designs. Maybe it is 
>> just better to remove this paragraph?
> 
> The constrained device can delegate most of its tasks (“what is has to do”) 
> to a (sufficiently trusted) less-constrained one (the only tasks that it 
> cannot delegate are the ones needed to properly establish and maintain trust 
> into that device and the communication with it).
> The paragraph mostly serves as a reminder of how the task delegation pattern 
> can alleviate the concerns that led to the original COSE not having 
> X.509-related primitives.

Hi Cartsen,

As someone who is not involved in Ace and some of the other work on constrained 
devices, with this explanation, the paragraph seems more out of place and 
misleading .
- It doesn’t inform or provide needed background info as to usage and design of 
cose-x509 (delegation issues are the same and even more important for regular 
x.509).
- It doesn’t say anything about delegation to a cloud or such, so it’s unclear 
what it is talking about
- Maybe it reminds some people that already know about architecture for 
delegation chain validation; not sure reminders for those in the know are useful
- The security considerations section for delegation of chain validation would 
be substantial

All that said, I don’t think the paragraph is so awful it I would say it must 
be deleted, but think the document would be better if it was (or it was 
expanded and moved to an appendix, or better yet some constrained device 
architecture / cook book document).

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Magnus Westerlund's Discuss on draft-ietf-cose-x509-07: (with DISCUSS)

[Laurence Lundblade]

We had a good discussion on key / cert identification for EAT / RATS at our 
virtual interim meeting today. There seems to be consensus support for use of 
cose-x509.

LL


> On Oct 22, 2020, at 11:17 AM, Laurence Lundblade  
> wrote:
> 
> I would like to see it as standards track.
> 
> I would like EAT / RATS to make normative reference to it. Some forms of 
> Attestation use Endorsements to convey a signature verification key to the 
> Verifier and some Endorsements are in the form of an X.509 certificate.
> 
> I will present some of this at the RATS virtual interim tomorrow 
> <https://datatracker.ietf.org/doc/agenda-interim-2020-rats-06-rats-01/>. 
> Slides are here 
> <https://datatracker.ietf.org/doc/slides-interim-2020-rats-06-sessa-eat-verification-id-and-other-updates/>.
>  This is why I’ve been so interested in this lately.
> 
> Also, it seems pretty important for COSE to be usable with the all the X.509 
> infrastructure out there.
> 
> LL
> 
> 
>> On Oct 22, 2020, at 5:18 AM, Magnus Westerlund via Datatracker 
>> mailto:nore...@ietf.org>> wrote:
>> 
>> ...
>> I think the topic should be fairly easily to resolve one way or another.
>> However, even after having read the reply to Marin's comment I don't think 
>> this
>> document is published with the right status.
>> 
>> - The document defines new CBOR attributes, that is standard track work as it
>> comes out as consensus document from a IETF WG. - It does not define or
>> document crypto algorithm just refer to existing ones. - The charter item 
>> might
>> have been reasonable as informational if existing attributes could have been
>> used. With the choice to define new attributes I think this has entered
>> standards track. - The status of the document I think will also affect the
>> value that IANA might assign to these COSE Header Parameters.
>> 
>> If there are additional considerations I am happy to learn about them.
>> 
>> Else, I would propose a change of status to proposed standard and redo the 
>> IETF
>> last call.
>> 
>> 
>> 
>> 
>> 
>> ___
>> COSE mailing list
>> COSE@ietf.org <mailto:COSE@ietf.org>
>> https://www.ietf.org/mailman/listinfo/cose
>> 
> 
> ___
> COSE mailing list
> COSE@ietf.org <mailto:COSE@ietf.org>
> https://www.ietf.org/mailman/listinfo/cose 
> <https://www.ietf.org/mailman/listinfo/cose>
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] draft-ietf-cose-x509-07 and x5u header

[Laurence Lundblade]

OK. Got it. Thanks for writing it out.

I think that means identification of an end-entity cert must usually be covered 
by the signature. Since x5t and x5chain identify end-entity certs, they should 
be protected headers. From an attackers point of view the unprotected headers 
can be manipulated to the same result as an x5u if it were unprotected.

It is spelled out clearly here in Key Identification in RFC 7517 
<https://tools.ietf.org/html/rfc7515#section-6> (JWS). Seems like cose-x509 
needs similar text.

It seems like you could combine a protected x5t with an unprotected x5u to get 
the same result. Fetch the cert with x5u, then make sure it is right with x5t.

I spent some time reading CMS, RFC 5652. It does not seem to address this. The 
SignerIdentifier which identifies the end-entity cert does not seem to be 
covered by the signature. This seems like an omission in CMS.

If I’d read RFC 7515 before I read cose-x509, I would have been much less 
confused and caused a lot less trouble here.

LL



> On Oct 22, 2020, at 2:18 PM, Benjamin Kaduk  wrote:
> 
> On Thu, Oct 22, 2020 at 01:56:58PM -0700, Laurence Lundblade wrote:
>> Below...
>> 
>>> On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk  wrote:
>>> 
>>> Hi Laurence,
>>> 
>>> On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote:
>>>> 
>>>>> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk  wrote:
>>>>> 
>>>>> On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote:
>>>>>> I’m trying to understand why the x5u header must be a COSE protected 
>>>>>> header parameter and in general what the expected use of this header is.
>>>>>> 
>>>>>> My understanding is that it the relying party that is validating the 
>>>>>> cert chain is the one doing the HTTP fetching.
>>>>>> 
>>>>>> In the case of application/pkix-cert, then only one DER cert is returned 
>>>>>> and that is the end-entity cert.
>>>>>> 
>>>>>> My expectation for the way this would work is:
>>>>>> - The relying party would use HTTP to with the x5u URL to fetch the 
>>>>>> end-entity cert
>>>>>> - The relying party would have a trust anchor previously configured
>>>>>> - The certs in the chain between the end-entity are either already 
>>>>>> possess by the relying party or are in the x5bag header
>>>>>> - Then it is just a straight forward chain formation and validation. 
>>>>>> 
>>>>>> In this use, there is no requirement for security of the URL or for use 
>>>>>> of TLS to fetch it. All the necessary security is provided by standard 
>>>>>> chain validation.
>>>>>> 
>>>>>> So why is there a requirement that the header be protected and that 
>>>>>> TLS/DTLS be used?
>>>>>> 
>>>>>> Further, wouldn't the header protection be a form of self signing since 
>>>>>> the private key used to sign the header corresponds to the public key 
>>>>>> that is being fetched?
>>>>> 
>>>>> It is in some sense a form of self-signing, yes.  But TLS (or equivalent)
>>>>> is still needed for fetching the certificate in order to verify that the
>>>>> *certificate* received is the one intended, not a different certificate
>>>>> that wraps the same public key.  There are plenty of attacks if you swap
>>>>> out the certificate for one with different key usage, SAN, etc.
>>>>> You might argue that it's hard to get a different cert (with
>>>>> attacker-controlled contents) for the same public key if the attacker
>>>>> doesn't have access to the corresponding private key, but that's not a 
>>>>> very
>>>>> reliable security control.
>>>> 
>>>> Hi Ben, 
>>>> 
>>>> It seems like your are interpreting the x5u header to be for the fetching
>>>> of a single validated end-entity certificate. Some remote service did the
>>> 
>>> I do not believe I am doing so.  The TLS (or other) authentication of the
>>> URI target does not inherently stand in for local validation of the
>>> certificate and chain.  (There may be particular special cases arranged by
>>> policy where it does, but not in the general case.)
>>> 
>>> I am saying that you can have multiple certificates, call them A and B,
>>> that certify the same public

Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-x509-07: (with COMMENT)

[Laurence Lundblade]

> On Oct 21, 2020, at 10:58 AM, Benjamin Kaduk via Datatracker 
>  wrote:
> 
>   x5t:  This header parameter provides the ability to identify an X.509
>  certificate by a hash value.  The attribute is an array of two
> 
> I suggest using the word "thumbprint" somewhere to motivate the 't' in
> "x5t”.

Using “thumbprint” makes sense to me, though it was changed from thumbprint to 
fingerprint in March 
.
 

Is it the common understanding that this “x5t” identifies the end-entity cert 
like subjectKeyIdentifier does for CMS 
? I can’t imagine what else it 
would identify, but it seems saying this explicitly would be helpful. CMS 
certainly is explicit and detailed on this.

> 
> Also, we may want to make a pass to check for consistent usage of
> "attribute", "parameter", etc. -- I think this is the first time we say
> "the attribute is”.

I believe the correct term is “header parameter”. This was settled on for 
draft-ietf-cose-rfc8152bis-struct and Jim made a number of changes to cose-x509 
to use that term back in March (same PR as referenced above). However, 
“attribute” is still used a lot and probably all those uses should be “header 
parameter”.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Gap in registration of application/cwt?

[Laurence Lundblade]

> On Aug 10, 2020, at 5:49 PM, Jim Schaad  wrote:
> 
> This is all based on my understanding that the surrounding protocol for must 
> specify exactly when CBOR tags are to be used and when they are not to be 
> used and that the surrounding protocol must not leave it as an optional 
> implementation choice. In this case application/cwt is the supporting 
> protocol.
>  
> [JLS] What is the text that says that this is true.  This would be a 
> surprising statement for me.

Here’s three things that lead me to this.

CBORbis
The sentence of the first paragraph in 4.2.2 
 very 
clearly states this, though this is only for deterministic encoding.

Typical CDDL
Most CDDL that describes tagged data describes it only as tagged or untagged, 
not as optionally tagged.  COSE is one example of this. 

Email threads
This thread 

 and this thread 
.

I summarized this behavior in this email 
 and 
no where in the rest of the thread was it indicated differently.

So, it is not a hard requirement because 4.2.2 is only for deterministic 
encoding, but seems like a “should" in spirit. It is the preferred way to 
design a CBOR protocol.

However you slice it, I think it is up to the surrounding protocol to say 
whether a tag is always required, never required or optionally required. If the 
protocol doesn’t say, then it defaults to optionally required.

Defaulting or explicitly allowing optional tagging means the receiver has to 
allow for all the tagging scenarios and makes possible the error case where the 
surrounding protocol says the data is of one type and the tag conflicts with 
it. (e.g. an application/cwt that contains a tagged CoSWID).

I don’t think optional tagging is of any advantage in a protocol design. It 
doesn’t enable anything.

It has some disadvantage because it introduces error conditions and potential 
confusion.

I think there are several scenarios with section 6 and application/cwt that 
could be more clear.

Can you use tag 61 or not? I think the current answer is that in 
application/cwt, tag 61 is optional.

How do you know what the COSE type is? It is somewhat obvious that COSE tags 
will work, but there is no requirement to use them. A MIME parameter or other 
is entirely allowed here.

Section 6 does say that determination that something is a CWT is application 
dependent, but doesn’t say that the COSE type is also application dependent. 
Section 7 does address this.

Said another way, my fully general CWT decoder that is called by some 
application needs an input parameter to indicate the COSE type because there is 
no requirement in 8392 that a CWT indicate which COSE type is in use. Sometimes 
the caller will be able to provide the COSE type and sometimes they won’t. 
Sometimes there will be an error of conflicting COSE type and sometimes the 
error will be that the COSE type can’t be determined.

I think it would have been cleanest if CWT always indicated the COSE type be 
used and the tagging optionality didn’t span two protocol layers, but that 
would be an incompatible change.  Maybe a recommendation that CWT’s SHOULD 
always indicate their COSE type?

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] Gap in registration of application/cwt?

[Laurence Lundblade]

It doesn’t seem clear what the CBOR tagging requirements are when 
application/cwt is used to indicate a message is a CWT.

This is the text that I think it missing:

The CBOR CWT tag (61) must NOT be used. It is unnecessary because the media 
type already indicates it is a CWT.

The COSE type indicating tag MUST be present. It is necessary to determine 
whether what the COSE type is, whether it is COSE_Sign1, COSE_Mac0...

Another solution could be a MIME parameter added to the application/cwt 
indicating the COSE type.

Step 3 in section 7.2 also seems wrong. It doesn’t make it an error for the 
COSE type tag to be absent when the CBOR CWT tag is present.


This is all based on my understanding that the surrounding protocol for must 
specify exactly when CBOR tags are to be used and when they are not to be used 
and that the surrounding protocol must not leave it as an optional 
implementation choice. In this case application/cwt is the supporting protocol.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] COSE messages with kid in layer-1

[Laurence Lundblade]

Hi Brian,

Looks to me like there is an example of COSE_Sign1 that is pretty much 
identical to what you’ve requested below in C.2.1. 

My understanding is that the kid can as needed in any of the COSE message 
types. It is usually unprotected, but I don’t see any requirement that 
precludes it from being protected (and section 6 of RFC 7515, JSON Web 
Signature, suggests the kid should be protected at times).

I would say it is the key identification scheme that determines which headers 
are used and which are protected. The key identification scheme varies from one 
COSE use case to another.

LL

> On Dec 28, 2020, at 3:12 PM, Brian Sipos  wrote:
> 
> All,
> In the examples of RFC 8152 [1] the COSE_Mac0 and COSE_Encrypt0 examples 
> don't include a key identifier ("kid" parameter) in the top-level unprotected 
> headers, and there is no example of COSE_Sign1 message. The informative text 
> implies that there should not be a kid parameter, but I don't see this in any 
> normative statement of RFC 8152 or in the errata [2]. I also don't see any 
> difference in the upcoming 8152bis document [3].
> 
> I thought that the algorithm itself determined which protected/unprotected 
> headers were acceptable within a particular layer, while the message type 
> determined the top-level structure and whether there are sub-layers.
> 
> Is there a fundamental reason why the single-signer example (from C.1.1) of:
>98(
>  [
>/ protected / h'',
>/ unprotected / {},
>/ payload / 'This is the content.',
>/ signatures / [
>  [
>/ protected h'a10126' / << {
>/ alg / 1:-7 / ECDSA 256 /
>  } >>,
>/ unprotected / {
>  / kid / 4:'11'
>},
>/ signature / h'...'
>  ]
>]
>  ]
>)
> could not be rewritten as a COSE_Sign1 message of:
>18(
>  [
>/ protected h'a10126' / << {
>/ alg / 1:-7 / ECDSA 256 /
>  } >>,
>/ unprotected / {
>  / kid / 4:'11'
>},
>/ payload / 'This is the content.',
>/ signature / h'...'
>  ]
>)
> I thought that the point of the COSE_Mac0, COSE_Sign1, COSE_Encrypt0 messages 
> were just to reduce the framing overhead of allowing multiple signatures.
> 
> Thanks for any clarification,
> Brian S.
> 
> [1] https://tools.ietf.org/html/rfc8152#appendix-C 
> 
> [2] https://www.rfc-editor.org/errata_search.php?rfc=8152 
> 
> [3] https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-14 
> 
> 
> ___
> COSE mailing list
> COSE@ietf.org 
> https://www.ietf.org/mailman/listinfo/cose 
> 
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] GitHub issues and -08 release

[Laurence Lundblade]

I closed three issues in the cose x509 GitHub 
 I’d opened a year or so ago as they 
have been resolved in the -08 and/or previous drafts.

I opened two new issues that are about consistency with JWS. Exact consistency 
with JWS seems valuable. It comes up with EAT as we’re trying to use CWT and 
JWT as semantically equivalent (but syntactically different).

I also opened an issue on x5u as to the nature of the “trust relationship” 
between the signer and the URI host. Since “trust relationships” are important 
and central here I think it should be spelled out in full detail (and I’m not 
entirely sure what is intended)

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] Identifying the end-entity cert

[Laurence Lundblade]

Was looking over the -08 draft and comparing to JWS header parameters.  I think 
the -08 draft would be much improved by explicitly saying how the end-entity 
cert is determined. 

JWS is clear and explicit about this:
   - x5t always refers to an end-entity
   - In x5u the first cert is always the end-entity
   - In x5c the first cert is always the end-entity

JWS uses the phrase "The certificate containing the public key corresponding to 
the key used to digitally sign” rather than "end-entity”. I prefer end-entity, 
but either is fine.

By contrast, COSE X.509 only explicitly says how the end-entity is determined 
for an x5chain. Nothing is said for x5t, x5bag or x5u.

Seems to me that COSE X.509 should be made identical to JWS for x5t, x5chain 
and x5u. 

Then COSE has the add-on bonus of x5bag. x5bag never determines the end-entity 
since it is un ordered. You have to have an x5t, kid or some other means of 
knowing which in the x5bag is the end-entity. And it is OK that x5bag doesn’t 
even contain the end-entity.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] bstr wrapping for native signed (was Re: New Version Notification for draft-mattsson-cose-cbor-cert-compress-05.txt)

[Laurence Lundblade]

> On Dec 15, 2020, at 8:53 AM, Carsten Bormann  wrote:
> 
> On 2020-12-07, at 23:02, Laurence Lundblade  wrote:
>> 
>> I don’t think it works very well at all to directly sign encoded CBOR. It 
>> should be wrapped in a byte string.
> 
> Sorry for coming in late; I’m having a hard time following this thread.
> 
> Generally, we don’t want to do the “XMLDsig” thing and require canonical (the 
> new word is “deterministic” in RFC 8949) encoding of CBOR data items 
> re-encoded as signature input.
> 
> But it seems to me that the structure described on page 8 of 
> draft-mattsson-cose-cbor-cert-compress-05.txt doesn’t need that:
> 
> https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-05#page-8
> 
> This is a CBOR sequence (RFC 8742) of 11 CBOR data items, 10 of which form a 
> subsequence that would be the signing input, and the 11th being a byte string 
> with the signature.
> I’m not sure the current draft defines how to do that for native signing, and 
> I hope the procedure will be culturally compatible with COSE at some point 
> (i.e., facilitate some code reuse/sharing).
> 
> RFC 8949 does not prescribe an API for a generic CBOR decoder.  But we can go 
> by the 60+ implementations documented on https://cbor.io/impls.html — 
> generally these do not provide ways to decode an encoded data item and then 
> ask the decoder for the position and length of a specific subtree in the 
> encoded input.  I think this is what Laurence has in mind.

Yes, you need the offset of the end of the to-be-hashed data returned by the 
CBOR decoder (or some equivalent way of knowing what to hash). I wouldn’t 
expect CBOR decoders to return this offset as it doesn’t seem necessary for 
anything but this particularly use case, not even for COSE.


> But the situation here is somewhat different: The top level of a 
> X.509-compatible CBOR certificate is that sequence.  Many CBOR 
> implementations do not address CBOR sequences (RFC 8742) explicitly, they 
> just allow you to decode an item from a start position and give you the end 
> position.  Applying that 10 times gives you an end position that can be used 
> with the start of the encoded certificate as the extent of the signing input. 
> The result of signing that can then be compared with the content of the 11th 
> item.
> 
> So I think that we do not have the same level of problem we would have if we 
> needed to obtain start/end positions for something deep in the structure.

I agree that this is not the same level of problem because the start position 
is 0 and the end position is not as hard to find as in COSE. But it still seems 
like a problem that may require change to many otherwise complete CBOR 
decoders. My decoder, QCBOR, works on sequence but doesn’t return offsets.. 
Some other decoder might process the CBOR into an internal tree structure first 
and not record the offsets and thus not be able to return them.

When I spoke of hacking the decoder previously, it was modifications to know 
the offset. 

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] bstr wrapping for native signed (was Re: New Version Notification for draft-mattsson-cose-cbor-cert-compress-05.txt)

[Laurence Lundblade]

> On Dec 15, 2020, at 7:33 AM, Hristozov, Stefan 
>  wrote:
> 
> What exactly do you mean by hacking the decoder? Do you mean to track the 
> offset? What are the alternatives?

I mean modifying the decoder to return the offset (or some other access to 
to-be-hashed data). Not all, maybe only very few, return the offset. There is 
no need return it.

My own decoder, QCBOR, maintains an internal cursor for the position in the 
CBOR tree, but doesn’t return byte offsets. There is no need to.

The alternative is to change the CBOR cert design so the to-be-signed data is 
wrapped in a byte string like COSE does (or just use COSE for signing native 
CBOR (which gets you code re use)).

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] draft-ietf-cose-x509-07 and x5u header

[Laurence Lundblade]

Here’s text from section 6 in JWS 
<https://tools.ietf.org/html/rfc7515#section-6> that seems pretty close:

   Specifically, the Header
   Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256"
   can be used to identify the key used.  These Header Parameters MUST
   be integrity protected if the information that they convey is to be
   utilized in a trust decision...

My understanding is that “info used in a trust decision” typically refers to 
fields in the end-entity certificate other than the key.

LL


> On Nov 1, 2020, at 10:51 AM, Ivaylo Petrov  wrote:
> 
> Hello Laurence,
> 
> I am confident this discussion has been useful for the understanding of 
> everyone, so thank you for starting it! Do not hesitate to suggest text if 
> you believe anything needs to be explained in more details regarding why some 
> attributes need to be protected and why others do not.
> 
> Thanks,
> Ivaylo
> 
> 
> On Fri, Oct 23, 2020 at 9:02 PM Laurence Lundblade  <mailto:l...@island-resort.com>> wrote:
> OK. Got it. Thanks for writing it out.
> 
> I think that means identification of an end-entity cert must usually be 
> covered by the signature. Since x5t and x5chain identify end-entity certs, 
> they should be protected headers. From an attackers point of view the 
> unprotected headers can be manipulated to the same result as an x5u if it 
> were unprotected.
> 
> It is spelled out clearly here in Key Identification in RFC 7517 
> <https://tools.ietf.org/html/rfc7515#section-6> (JWS). Seems like cose-x509 
> needs similar text.
> 
> It seems like you could combine a protected x5t with an unprotected x5u to 
> get the same result. Fetch the cert with x5u, then make sure it is right with 
> x5t.
> 
> I spent some time reading CMS, RFC 5652. It does not seem to address this. 
> The SignerIdentifier which identifies the end-entity cert does not seem to be 
> covered by the signature. This seems like an omission in CMS.
> 
> If I’d read RFC 7515 before I read cose-x509, I would have been much less 
> confused and caused a lot less trouble here.
> 
> LL
> 
> 
> 
>> On Oct 22, 2020, at 2:18 PM, Benjamin Kaduk > <mailto:ka...@mit.edu>> wrote:
>> 
>> On Thu, Oct 22, 2020 at 01:56:58PM -0700, Laurence Lundblade wrote:
>>> Below...
>>> 
>>>> On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk >>> <mailto:ka...@mit.edu>> wrote:
>>>> 
>>>> Hi Laurence,
>>>> 
>>>> On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote:
>>>>> 
>>>>>> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk >>>>> <mailto:ka...@mit.edu>> wrote:
>>>>>> 
>>>>>> On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote:
>>>>>>> I’m trying to understand why the x5u header must be a COSE protected 
>>>>>>> header parameter and in general what the expected use of this header is.
>>>>>>> 
>>>>>>> My understanding is that it the relying party that is validating the 
>>>>>>> cert chain is the one doing the HTTP fetching.
>>>>>>> 
>>>>>>> In the case of application/pkix-cert, then only one DER cert is 
>>>>>>> returned and that is the end-entity cert.
>>>>>>> 
>>>>>>> My expectation for the way this would work is:
>>>>>>> - The relying party would use HTTP to with the x5u URL to fetch the 
>>>>>>> end-entity cert
>>>>>>> - The relying party would have a trust anchor previously configured
>>>>>>> - The certs in the chain between the end-entity are either already 
>>>>>>> possess by the relying party or are in the x5bag header
>>>>>>> - Then it is just a straight forward chain formation and validation. 
>>>>>>> 
>>>>>>> In this use, there is no requirement for security of the URL or for use 
>>>>>>> of TLS to fetch it. All the necessary security is provided by standard 
>>>>>>> chain validation.
>>>>>>> 
>>>>>>> So why is there a requirement that the header be protected and that 
>>>>>>> TLS/DTLS be used?
>>>>>>> 
>>>>>>> Further, wouldn't the header protection be a form of self signing since 
>>>>>>> the private key used to sign the header corresponds to the public key 
>>>>

Re: [COSE] draft-ietf-cose-x509-07 open GitHub issues, PEM, DER and x5t parameter

[Laurence Lundblade]

Hi Ivaylo,

> On Nov 1, 2020, at 10:55 AM, Ivaylo Petrov  wrote:
> 
> 2) I clarified that the hash is computed over the DER encoding of the 
> certificate. I am not completely sure that we should limit the use of x5t to 
> only reference the certificate containing the end-entity key, but that is 
> also fine with me.

JWS is clear about x5t as the end-entity cert:

   The "x5t" (X.509 certificate SHA-1 thumbprint) Header Parameter is a
   base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER
   encoding of the X.509 certificate [RFC5280 
] corresponding to the key
   used to digitally sign the JWS.

I can’t imagine any other use of x5t as all certs superior to the end-entity 
must be identified by secured identifiers in the certificate one below to 
defend against the attack Ben described (the same attack that requires x5t a 
protected header).

Appendix D in JWS also discusses use of x5t as the end-entity.

I don’t think I’m missing anything here, but tell me if I am.


Also, it looks to me that Appendix D of JWS 
 is highly applicable to 
cose-x509. A non-normative link to it would be helpful in understanding 
cose-x509.

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Magnus Westerlund's Discuss on draft-ietf-cose-x509-07: (with DISCUSS)

[Laurence Lundblade]

I would like to see it as standards track.

I would like EAT / RATS to make normative reference to it. Some forms of 
Attestation use Endorsements to convey a signature verification key to the 
Verifier and some Endorsements are in the form of an X.509 certificate.

I will present some of this at the RATS virtual interim tomorrow 
. Slides 
are here 
.
 This is why I’ve been so interested in this lately.

Also, it seems pretty important for COSE to be usable with the all the X.509 
infrastructure out there.

LL


> On Oct 22, 2020, at 5:18 AM, Magnus Westerlund via Datatracker 
>  wrote:
> 
> ...
> I think the topic should be fairly easily to resolve one way or another.
> However, even after having read the reply to Marin's comment I don't think 
> this
> document is published with the right status.
> 
> - The document defines new CBOR attributes, that is standard track work as it
> comes out as consensus document from a IETF WG. - It does not define or
> document crypto algorithm just refer to existing ones. - The charter item 
> might
> have been reasonable as informational if existing attributes could have been
> used. With the choice to define new attributes I think this has entered
> standards track. - The status of the document I think will also affect the
> value that IANA might assign to these COSE Header Parameters.
> 
> If there are additional considerations I am happy to learn about them.
> 
> Else, I would propose a change of status to proposed standard and redo the 
> IETF
> last call.
> 
> 
> 
> 
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
> 

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] draft-ietf-cose-x509-07 and x5u header

[Laurence Lundblade]

Below...

> On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk  wrote:
> 
> Hi Laurence,
> 
> On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote:
>> 
>>> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk  wrote:
>>> 
>>> On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote:
>>>> I’m trying to understand why the x5u header must be a COSE protected 
>>>> header parameter and in general what the expected use of this header is.
>>>> 
>>>> My understanding is that it the relying party that is validating the cert 
>>>> chain is the one doing the HTTP fetching.
>>>> 
>>>> In the case of application/pkix-cert, then only one DER cert is returned 
>>>> and that is the end-entity cert.
>>>> 
>>>> My expectation for the way this would work is:
>>>>  - The relying party would use HTTP to with the x5u URL to fetch the 
>>>> end-entity cert
>>>>  - The relying party would have a trust anchor previously configured
>>>>  - The certs in the chain between the end-entity are either already 
>>>> possess by the relying party or are in the x5bag header
>>>>  - Then it is just a straight forward chain formation and validation. 
>>>> 
>>>> In this use, there is no requirement for security of the URL or for use of 
>>>> TLS to fetch it. All the necessary security is provided by standard chain 
>>>> validation.
>>>> 
>>>> So why is there a requirement that the header be protected and that 
>>>> TLS/DTLS be used?
>>>> 
>>>> Further, wouldn't the header protection be a form of self signing since 
>>>> the private key used to sign the header corresponds to the public key that 
>>>> is being fetched?
>>> 
>>> It is in some sense a form of self-signing, yes.  But TLS (or equivalent)
>>> is still needed for fetching the certificate in order to verify that the
>>> *certificate* received is the one intended, not a different certificate
>>> that wraps the same public key.  There are plenty of attacks if you swap
>>> out the certificate for one with different key usage, SAN, etc.
>>> You might argue that it's hard to get a different cert (with
>>> attacker-controlled contents) for the same public key if the attacker
>>> doesn't have access to the corresponding private key, but that's not a very
>>> reliable security control.
>> 
>> Hi Ben, 
>> 
>> It seems like your are interpreting the x5u header to be for the fetching
>> of a single validated end-entity certificate. Some remote service did the
> 
> I do not believe I am doing so.  The TLS (or other) authentication of the
> URI target does not inherently stand in for local validation of the
> certificate and chain.  (There may be particular special cases arranged by
> policy where it does, but not in the general case.)
> 
> I am saying that you can have multiple certificates, call them A and B,
> that certify the same public key K.  Knowing K, you can validate the
> message signature, protected attributes, etc., including the URI used to
> fetch the certificate.  However, if the URI used to fetch the certificate
> uses a scheme that does not provide integrity protection or server
> authentication, then the party dereferencing the URI could obtain
> certificate A when the message originator intended for certificate B to be
> used for validation.  It is not too hard to imagine situations where both A
> and B can be used to build valid chains that end at root CAs trusted by the
> message recipient, and thus the insecure certificate fetch is (1)
> undetected and (2) causes the message to be interpreted differently than
> intended by the originator.  As I mentioned originally, A and B could have
> different X.509 extensions, (extended) key usage, subject information,
> etc., so there is a lot of room for the "interpreted differently" to be
> attacked.

But isn’t this a problem with any and all cert chain construction and 
validation?  If this is an issue, then x5bag and x5chain should be protected 
headers.

Seems like the real problem is CA operation. CA’s shouldn’t be creating 
alternate certs for real keys that result in issues like this.

So it still seems to me that the primary reason for an x5u that is a protected 
header parameter and obtained with DTLS is so you don’t have to validate the 
end-entity on the constrained device. Presumably you already have a DTLS stack, 
so you are almost getting the validated cert for no extra code.


> 
>> cert chain validation. You and other folks probably were involved 

[COSE] magic number, file format and tags

[Laurence Lundblade]

One way to handle CBOR certs in files would be to use the CBOR magic number 
55799 (0xd9d9f7) to identify it as CBOR and then define a tag to identify it as 
a CBOR-cert. Or just rely on the .cbor file extension and a CBOR-cert tag. 

It seems to be common practice to define a tag for CBOR protocol messages. Why 
not CBOR cert? COSE, CWT, CoSWID and others do it. I opened an issue 
 for it.

0xd9d9f7 also definitely distinguishes CBOR from PEM and DER.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm

[Laurence Lundblade]

> On Jun 23, 2021, at 9:42 AM, Mike Jones 
>  wrote:
> 
> The WebAuthn and FIDO2 working group members had thought that the COSE 
> algorithm semantics were the same as those for JOSE, where algorithm 
> identifiers are not polymorphic.  They were wrong, but that's water under the 
> bridge now.  The FIDO/WebAuthn usage of the algorithm identifiers requires 
> that the identifiers used unambiguously specify all algorithm parameters.  
> (Note that FIDO/WebAuthn does not use COSE signatures - only COSE algorithm 
> identifiers.)  They have done what they needed to do to remove the 
> ambiguities arising in practice from use of polymorphic algorithm identifiers 
> for their use cases.
> 
> Note that by the time that we registered the ES256K algorithm for signing 
> with the secp256k1 curve in RFC 8812, we were aware of the problem and 
> intentionally made ES256K non-polymorphic - both for JOSE and for COSE.
> 
> I believe that we should create a policy requiring that all future algorithm 
> registrations should be non-polymorphic.  Furthermore, I believe we should 
> consider defining and registering new non-polymorphic algorithm identifiers 
> so that use of the existing polymorphic algorithm identifiers can be avoided 
> and deprecated.

This seems good to me.

Going a bit further, the binding to a particular hash function seems important 
too. Aside from the security reasons, it makes means that an algorithm ID 
always selects a function that takes an arbitrary number of unstructured bytes 
to be signed/verified which makes implementation of crypto APIs cleaner and 
reduces code size.

It also seems more convenient in protocols like FIDO. You only need to carry a 
single integer around. My recollection of ASN.1 is that the structure of an 
algorithm specifier varies by algorithm which makes writing code for it more 
complex. You have to decode a structure that specifies a hash rather than just 
switch on an integer.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] The one-byte saving from use of a sequence

[Laurence Lundblade]

If I’m thinking right, the one-byte saving from using a sequence rather than 
array for CBORCertificate only happens when using CBORCertificate in a non-CBOR 
protocol. When you put CBORCertificate in a CBOR protocol, it has to be an 
array (or a bstr-wrapped sequence) so it can be distinguished from the 
surrounding CBOR. In non-CBOR protocols, the surrounding protocol (e.g., the 
DER, or the TLS records) provides the framing for what is the cert, so the 
array is not needed.

I’d like to see CBORCertificate an array in the main definition. Then when 
CBORCertificate is put in a non-CBOR protocol, it can be “unwrapped" to save 
the byte. The CDDL notation for that would be ~CBORCertificate. (I’ve been 
reading up on CDDL unwrapping lately, so hopefully I got that right).

This also aligns CBORCertificate with the other CBOR protocols I’ve seen so 
far. They use an array or map to hold the top-level messages together.

Also, I’m pretty sure the CDDL for COSE_C5 is wrong in the -08 draft. It says:

COSE_C5 = [ + CBORCertificate ]

With CBORCertificate defined as a CDDL group, no framing structure to 
distinguish the individual CBORCertificates is generated. The array defined by 
this is not of individual certs, but of an aggregation of all the certificate 
data items. It would not be possible to decode correctly. Making 
CBORCertificate an array solves this problem.

We should expect CBORCertificate to be incorporated into lots and lots of other 
CBOR-based protocols. If we are making a mistake like this because of 
CBORCertificate being a sequence and not an array, it seems others may as well. 
So another reason for the main definition of CBORCertificate to be an array.

LL
 



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] The one-byte saving from use of a sequence

[Laurence Lundblade]

> On May 14, 2021, at 1:22 AM, John Mattsson 
>  wrote:
> 
> > I'm I'm pretty sure it is incorrect CDDL
> I don't know why you think this was incorrect CDDL. RFC 8610 even has the 
> following example [+(left: uint, right: uint)] (but this does not matter as I 
> think we have already taken the decision to use arrays).
> 
> > It would not be possible to decode correctly.
>  
> I don’t think that was true. That would only be true if you cannot determine 
> the number of elements from c509CertificateType (but this does not matter as 
> I think we have already taken the decision to use arrays).
>  

Yes, you are right, as long as the number of items is fixed, you can count and 
successfully decode (didn’t think of counting like that).

You’d have to be aware of this every time you designed a CBOR protocol that 
uses CBORCertificate

For example, you couldn’t count for this protocol, but it works fine if 
CBORCertificate is an array.

   [ 
   * cert : CBORCertificate
   * vector : int
   ]

I still think everyone’s life will be easier if CBORCertificate defined as an 
array so it works as expected for CBOR-based protocols and you unwrap the array 
to save the byte in non-CBOR protocols.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] C509 Certification Request (CSR)

[Laurence Lundblade]

> On May 26, 2021, at 3:45 AM, Carsten Bormann  wrote:
> 
> I think it would be good to check our agreement in this group that having a 
> C509-shaped CSR is not a replacement for or an obstacle to developing 
> requests for CWT-shaped signed assertions.

This is the main thing for me.

We must not close off pure CBOR CSRs and Certs. We want to eventually get to a 
place where some one can run a system with no ASN.1/DER.

I would write drafts for this stuff now, except I’m committed to the EAT draft 
and need to finish that. I’d also do implementations. My ctoken 
 implementation of CWT and EAT is 
designed so this stuff can be easily added to it, but again I need to finish 
EAT. The implementation is also so the code is shared between CWT, EAT and 
eventually certs and CSRs. You could even do an (incompatible) revision of the 
FIDO protocol that would re use this code.

I kind of agree with Michael’s point that it is wasteful to have three formats 
(PKCS 10, CWT-based CSR and the thing in between proposed here). I also see any 
transition to a pure CBOR/CWT infrastructure as very long involved with many 
drafts being authored.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] C509 Certification Request (CSR)

[Laurence Lundblade]

> On May 26, 2021, at 1:53 AM, John Mattsson 
>  wrote:
> 
> I think the general CSR format for C509 need to support all the options in 
> the subject, subjectPublicKeyAlgorithm, and extensions of a C509 certificate. 
> Not sure we like to extend CWT with everything in RFC 5280. The size of the 
> CSR format does not seem as important as the size of the certificate format.

My thought for the long run is that there is a CBOR/CWT-based set of protocols 
that replace all the ASN.1/DER-based protocols. That of course includes a pure 
CBOR cert (based on CWT) and a pure CBOR CSR (also based on CWT). This is of 
course taking CWT far beyond its original intent, but that’s good because of 
code re use. Think of it as a flexible set of signed attributes, not as just 
for authentication. We’re already extending this way with EAT 10+ claims are 
being added.

So the answer is, yes, we should extend CWT with stuff in RFC5280. Maybe not 
all of it and maybe using lessons learned, but it should give all the 
functionality needed.

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] C509 Certification Request (CSR)

[Laurence Lundblade]

Any interest in CWT / JWT with the proof-of-possesion claim defined in RFC 8747 
and RFC 7800? They both have a subject and a public key, the same as PKCS-10.

Seems there is some code size advantage, perhaps more so in the long run, to 
going with pure CBOR. You only need to have COSE signing and verifying and that 
COSE code can be shared between all sorts of security functions like 
attestation, authentication, SW update.

With the CWT/EAT format, code is also shared for decoding the token/CSR, so the 
net code add to be a CSR is really small.

EAT defines an intended-use claim that can indicate the use is 
proof-of-posssion.

What you don’t get is an issue in the format of a DN, but maybe that is a good 
thing.

LL


> On May 25, 2021, at 1:32 PM, John Mattsson 
>  wrote:
> 
> Hi,
>  
> There has been several requests regarding CSR including #77 and #80 from 
> Stefan Hristozov. Defining a CSR format seems very easy reusing existing CDDL 
> and definition for certificates. When discussed during the interim, there 
> seemed to be support of specifying a C509 CSR format. I made a commit with 
> the following CDDL as a starting point for a CSR format:
>   
>
> ~~~ CDDL
> C509CertificateSigningRequest = [
>TBS CertificateSigningRequest,
>subjectProofOfPossesionValue: any,
> ]
>  
> ; The elements of the following group are to be used in a CBOR Sequence:
> TBS CertificateSigningRequest = (
>c509 CertificateSigningRequest Type: int,
>subject: Name,
>subjectPublicKeyAlgorithm: AlgorithmIdentifier,
>subjectPublicKey: any,
>attributes: [ * Attribute ],
>subjectProofOfPossesionAlgorithm: AlgorithmIdentifier,
> )
>  
> Attribute = ( attributeType: int, attributeValue: any )
> ~~~
>  
> The format is more of less taken from RFC 2988 (PKCS #10, 1.7). Most 
> definitions can just be reused from draft-ietf-cose-cbor-encoded-cert
>  
> Some comments:
>  
> - I don't think there is any reason to have a CBOR CSR with signature over 
> DER like we have done with C509 certificates. But having a type int is likely 
> good anyway even if only one is defined.
>  
> - Everybody seems to use the word "Certificate signing request" instead of 
> the RFC 2988 wording "certification request" so probably best to just use CSR.
>  
> - The RFC 2986 name signaturealgorithm does not match the algorithms defined 
> in RFC 6955 for DH keys. I suggest to use the name ProofOfPossesion following 
> RFC 6955. Signature algorithms is then a special case.
>  
> - The RFC 6955 algorithm would need to get int code points in the draft. They 
> currently do not have this as they are not used in certificates.
>  
> - RFC 2986 does not sign the signature, but there seems to be no reason to 
> not do this, so I made the format following the C509 certificate CDDL.
>  
> - I don't know which attributes would have to registered. Which attributes 
> are typically used? Are any attributes typically used?
>  
> Cheers,
> John
>  
>  
> ___
> COSE mailing list
> COSE@ietf.org 
> https://www.ietf.org/mailman/listinfo/cose 
> 
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] C509 Certification Request (CSR)

[Laurence Lundblade]

> On May 25, 2021, at 2:28 PM, Laurence Lundblade  
> wrote:
> 
> ...
> 
> What you don’t get is an issue in the format of a DN, but maybe that is a 
> good thing.

Should have said “is a subject in the format of a DN”.

Also note that attributes just become other CWT and EAT claims, again for which 
there is already likely to be an implementation and for which the code can be 
shared.

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm

[Laurence Lundblade]

> On Jun 23, 2021, at 8:32 PM, Carsten Bormann  wrote:
> 
> On 23. Jun 2021, at 18:42, Mike Jones 
>  wrote:
>> 
>> I believe that we should create a policy requiring that all future algorithm 
>> registrations should be non-polymorphic.  Furthermore, I believe we should 
>> consider defining and registering new non-polymorphic algorithm identifiers 
>> so that use of the existing polymorphic algorithm identifiers can be avoided 
>> and deprecated.
> 
> While I can’t see anything wrong with registering “ciphersuite” style 
> algorithm identifiers like ES256k, there also is nothing wrong with “pure” 
> algorithm identifiers.
> They just can’t be used with protocols that expect the full ciphersuite to be 
> specified in one number.

They also won’t work with APIs that expects a ciphersuite to be specified. For 
example, an API that take an integer that is a COSE algorithm identifier and a 
byte buffer or byte stream of some sort that is the actual data to be signed.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] A standard definition for digests in draft-ietf-cose-hash-algs?

[Laurence Lundblade]

Hi Carsten,

> On Jul 10, 2021, at 12:02 AM, Carsten Bormann  wrote:
> 
> 
>> On 2021-07-10, at 05:44, Laurence Lundblade  wrote:
>> 
>> Hi, Laurence here causing trouble again...
>> 
>> I’m looking to add a claim in EAT that is a digest — a hash algorithm 
>> identifier and the hash value.
> 
> What is that claim asserting?
> If I make the claim “3” that is not a very good claim.
> If I make the claim “this device needs to be allowed a sustained 
> communication bit rate of 3 bit/s to operate”, this is a much better claim.
> 
>> draft-ietf-cose-hash-algs-09 defines:
>> 
>> COSE_Hash_Find = [
>>hashAlg : int / tstr,
>>hashValue : bstr
>> ]
> 
> This is the “3”.

Not sure I’m receiving the point you are trying to make here with “3”.

We’ve defined COSE_Sign and COSE_Mac to carry payloads that are unspecified by 
COSE. People can do dumb things and good things in with what is defined today.

Seems like COSE_Digest would be pretty much the same.

Note also that the name “COSE_Hash_Find” does not really line up with the 
actual uses in EAT, SUIT or CoSWID.

And it is of course incumbent on EAT to define what the digest is of, just like 
SUIT and CoSWID defined what the object of their digests.


>> This is pretty much what is needed, but the name of it is odd and the text 
>> suggests it should only use this for searching for things, which is not the 
>> purpose. 
>> 
>> draft-ietf-cose-hash-algs-09 also “mentions":
>> 
>> COSE_Hash_V = (
>>1 : int / tstr, # Algorithm identifier
>>2 : bstr, # Hash value
>>? 3 : tstr, # Location of object that was hashed
>>? 4 : any   # object containing other details and things
>>)
> 
> Entries 3 and 4 complement (or, can complement in a specific context — that’s 
> why this is an example) the “3” to a meaningful claim.

SUIT, CoSWID and EAT just need the simple pair of algorithm ID and hash value. 
Seems like the pair is enough to be of value to me without the extra data item 
for location. In all three the identification of the object of the hash is in 
the surrounding structure, not in the digest structure.


>> But this is just an example, not an actual normative standard definition 
>> according to the text, so I don’t think it is right to use it in a standards 
>> track document.
> 
> Of course you can use examples for building your standard-track document.

My hope is to add support for a standard like COSE_Digest to my COSE library so 
it maybe can end up as code shared by CoSWID, SUIT and EAT.  If it is a 
standard, then it get used more as is and more libraries may support it as is.

Also, if COSE_SIgn1 where just an example, I don’t think it would be the same 
as what we have now.


>> Also that CoSWID has a CBOR structure like this, but uses the Named 
>> Information Hash Algorithm Registry, not COSE algorithm identifiers.
> 
> RFC 6920 has been around for a while and so was the go-to registry before 
> cose-hash-algs defined its own.
> 
>> And, SUIT laments that COSE doesn’t have this and defines its own with a 
>> different non-COSE numbering scheme for identifying hash algorithms.
> 
> To be fixed with cose-hash-algs.

Is there a PR I can look at yet so I can see what to do in EAT?

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] A standard definition for digests in draft-ietf-cose-hash-algs?

[Laurence Lundblade]

Hi, Laurence here causing trouble again...

I’m looking to add a claim in EAT that is a digest — a hash algorithm 
identifier and the hash value.

draft-ietf-cose-hash-algs-09 defines:

COSE_Hash_Find = [
hashAlg : int / tstr,
hashValue : bstr
]

This is pretty much what is needed, but the name of it is odd and the text 
suggests it should only use this for searching for things, which is not the 
purpose. 

draft-ietf-cose-hash-algs-09 also “mentions":

COSE_Hash_V = (
1 : int / tstr, # Algorithm identifier
2 : bstr, # Hash value
? 3 : tstr, # Location of object that was hashed
? 4 : any   # object containing other details and things
)

But this is just an example, not an actual normative standard definition 
according to the text, so I don’t think it is right to use it in a standards 
track document.

Also that CoSWID has a CBOR structure like this, but uses the Named Information 
Hash Algorithm Registry, not COSE algorithm identifiers.

And, SUIT laments that COSE doesn’t have this and defines its own with a 
different non-COSE numbering scheme for identifying hash algorithms.

All of the above uses are reasonably secure because they are embedded secured 
structures so the reasoning that digest shouldn’t exist because it isn’t secure 
in and of itself does seem right and deprives us of something useful.

Seems to me like draft-ietf-cose-hash-algs-09 should have a solid standard 
definition for a digest. My proposal would to replace COSE_Hash_Find and 
COSE_Hash_V with this:

COSE_Digest = (
1 : int / tstr, # COSE Algorithm identifier
2 : bstr, # Hash value
* : $$cose-digest-extensions
)

It seems too open-ended to try to figure out a standard for location of the 
object that is hashed, so I left that out.

Seems OK to just define a group and let the user of it make it into a map or 
array as they wish.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Pull-request addressing issues #29 #30 #31 #33 in draft-ietf-cose-x509-08

[Laurence Lundblade]

I wouldn’t say MUST, just highly recommended. If there is consensus for MUST I 
won’t object considering that the cost of protection is low for all the uses I 
can imagine.

LL

> On Mar 11, 2021, at 11:35 PM, John Mattsson 
>  wrote:
> 
> New comment from Laurance on GitHub pointing out that proof-of-possesion
> is not enough. I think this point to that COSE integrity protection of the 
> end-entity certificate needs to be MUST.
> 
> Cheers,
> John
> 
> https://github.com/cose-wg/X509/pull/35
> 
>  This doesn't address the case where a CA correctly and intentionally
>  issued two certs for the same key with different characteristics (e.g.,
>  key use, expiration, other extensions) and the attacker swapped them.
> 
>  Maybe this: "When any field in a certificate beyond the key (e.g., key
>  use, expiration, other extensions) is used in security decisions by the
>  receiver, the COSE header containing or referencing the certificate
>  should be in the protected bucket"."
> 
> 
> 
> 
> -Original Message-
> From: John Mattsson 
> Date: Thursday, 11 March 2021 at 08:33
> To: Carsten Bormann 
> Cc: cose 
> Subject: Re: [COSE] Pull-request addressing issues #29 #30 #31 #33 in 
> draft-ietf-cose-x509-08
> 
> Yes it probably better to register a new media type. E.g.:
> 
> application/cose-x509-chain
> 
> Let's discuss tomorrow.
> 
> Cheers,
> John
> 
> -Original Message-
> From: Carsten Bormann 
> Date: Wednesday, 10 March 2021 at 21:03
> To: John Mattsson 
> Cc: cose 
> Subject: Re: [COSE] Pull-request addressing issues #29 #30 #31 #33 in 
> draft-ietf-cose-x509-08
> 
> On 24. Feb 2021, at 10:35, John Mattsson 
>  wrote:
>> 
>> - Added media type application/cbor for a COSE_X509 chain.
> 
> Why is that the right media type?
> (We have specific ones for everything else, no?)
> 
> Grüße, Carsten
> 
> 
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] COSE content-type (generic header 3)

[Laurence Lundblade]

This is a CoAP content ID, right? Seems like RFC 7252 restricts these to 
0-65535, so yes, uint.

LL

> On Feb 17, 2021, at 2:11 PM, Carsten Bormann  wrote:
> 
> draft-ietf-cose-rfc8152bis-struct-15.txt defines a generic header 3, which is 
> either a media-type-name [1] or a content-format number.
> Table 3 on page 17 says this is text string or unsigned integer.
> The CDDL snippet following the table at the start of page 18 says
> 
>   ? 3 => tstr / int,  ; content type
> 
> I think this should be uint, not int.
> 
> I also would like to be able to use Content-Type [1] or preferably even 
> Content—Format-String [2] for the text string (we already can use 
> Content-Format numbers for the uint).
> 
> Is this a clarification we can/should do at this stage?
> 
> Grüße, Carsten
> 
> 
> [1]: 
> https://www.ietf.org/archive/id/draft-bormann-core-media-content-type-format-02.html#name-content-type
> [2]: 
> https://www.ietf.org/archive/id/draft-bormann-core-media-content-type-format-02.html#name-content-format
> 
> BTW, the plan for this draft is to update and resubmit it before IETF110 and 
> then ask for DISPATCH.
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] "CBOR Certificates"

[Laurence Lundblade]

CBOR.X.509 pronounced “CBOR X 509”?  X.509.CBOR could work too.

Then when we have real CBOR certs they get called “CBOR Certificates” of “CBOR 
Certs”.

LL

> On Feb 12, 2021, at 3:44 AM, John Mattsson 
>  wrote:
> 
> CBOR + X.509 = C.509 (CBOR encoded X.509) ?
>  
>  
> ___
> COSE mailing list
> COSE@ietf.org 
> https://www.ietf.org/mailman/listinfo/cose 
> 
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

A small comment on code size as the author of a commercial-quality COSE 
implementation designed to have small code size.

There is a bit of a trade-off between code size and bytes on the wire. Reducing 
the bytes on the wire by one byte in this case will lead to an increase in code 
size by a lot more than one byte, assuming both int and bstr are supported. If 
both are not supported, then there is #ifdef complexity and configuration work 
with general purpose COSE implementations.

Most of the code cost for me in implementing COSE is in the header parameter 
decoding.

This desire to save 1 CBOR byte here and there at the cost of code / complexity 
shows up elsewhere. Here’s one from CoSWID
one-or-more = T / [ 2* T ]

This could just be an array.

I don’t know the use cases, but I’m a little skeptical these sorts of things 
are worth a byte or two on the wire.

LL



> On Jul 30, 2021, at 5:28 AM, Göran Selander 
>  wrote:
> 
> Hi,
> 
> In LAKE yesterday we had a discussion on compact key identifiers. The main 
> candidate to use, 'kid', is specified as a CBOR bstr, which is typically at 
> least 2 bytes (exception: empty bstr which is 1 byte). We therefore want to 
> allow keys to be identified with CBOR ints which has 48 1-byte values to 
> allow for a larger number of optimally small identifiers.
> 
> One solution would be to define a new COSE key common parameter and COSE 
> header parameter, say 'kid2', of type bstr / int. Another solution would be 
> to extend 'kid' to be bstr / int.
> 
> In the former case a 'kid2' can be used to reference keys identified with 
> either 'kid2' or 'kid', but 'kid' would not be able to reference keys 
> identified with 'kid2' having an int value. Not clear to me if that is a 
> problem. 
> 
> While the LAKE WG did not express any preference, one opinion I learnt after 
> the meeting was a preference of extending 'kid' to bstr / int.
> 
> What do folks in COSE think?
> 
> I'm familiar with the process of registering new COSE parameters, what is the 
> requirement for changing the value type of an existing registration? 
> Standards action with expert review?
> 
> Thanks
> Göran
> 
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] tstr values for kty, alg, crv, etc.

[Laurence Lundblade]

> On Aug 9, 2021, at 12:43 PM, Michael Richardson  wrote:
> 
> 
> Carsten Bormann  wrote:
>> This discussion is all a bit short sighted to me. Sure, we can advise
>> against registering text labels now. But COSE has a long life with many
>> applications before it, some of which may be outside what you are
>> thinking about now. What’s the rush on disabling these?
> 
> I understood that some people think that we can encode the map key for 'kty'
> as both 'kty' and also 1.
> 
> (section 7 of RFC8152)
> [ditto alg and I think key_ops]
> 
> I'm not convinced the document says that.

Agreed.

The CDDL allows only 1, 2, 3,...for the params defined in COSE, but allows tstr 
for future params.


   label = int / tstr


   COSE_Key = {
   1 => tstr / int,  ; kty
   ? 2 => bstr,  ; kid
   ? 3 => tstr / int,; alg
   ? 4 => [+ (tstr / int) ], ; key_ops
   ? 5 => bstr,  ; Base IV
   * label => values
   }

Essentially, I think anyone trying to register tstr COSE identifier or label 
should be asked if they really want to do that, is it really necessary to use a 
tstr instead of an int:  Are you just doing it because you are used to JSON? 
You know that most implementations don’t support tstr, right?

Also, to be clear, you don't register both a tstr and an int for a particular 
item. There are two ways of doing this, but not for an individual item. Having 
tstr ‘foo’ and int 42 both referring to the same item would actually require 
two registrations and would be the worst thing to do.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] tstr values for kty, alg, crv, etc.

[Laurence Lundblade]

I don’t think tstr can be removed from the standard. That would break backwards 
compatibility. Maybe a strong recommendation could be added with the comment 
that many implementations don’t support tstr.

There is a revision of 8152 in process right now called 8152bis. That seems 
like the place to do it.

LL


> On Aug 5, 2021, at 8:29 PM, AJITOMI Daisuke  wrote:
> 
> Hi folks,
> 
> > I prefer to see the option of `tstr` labels removed if possible.
> 
> I'm glad to see that there are several people who agree with me.
> 
> To remove the option of tstr labels from the spec, would a revised RFC be 
> needed? Or would an errata enough for that?
> Anyway, I would like to hear from the key members in COSE whether this change 
> is acceptable or not.
> 
> If it is acceptable, I would like to support moving this effort forward.
> 
> Best regards,
> Daisuke
> 
> 2021年8月5日(木) 19:48 Jeremy O'Donoghue  <mailto:jodon...@qti.qualcomm.com>>:
> Hi list,
> 
>  
> 
> I agree with Laurence on this. I work on platform-related security standards 
> at GlobalPlatform where we are using COSE quite extensively. A major use-case 
> is highly constrained embedded targets where the benefits from eliminating 
> string handling are considerable – many such platforms do not have a heap, 
> and minimal code size is an important design goal.
> 
>  
> 
> I prefer to see the option of `tstr` labels removed if possible. We do have a 
> 64bit integer space for algorithms which should suffice. If this is not 
> possible (e.g. for backward compatibility with proprietary implementations), 
> at least a note to registrants that integer values are greatly preferred in 
> some implementations for reasons of code size would be helpful. 
> Implementations could then decide whether to not implement tstr support.
> 
>  
> 
> Best regards
> 
> Jeremy
> 
> 
> 2021年7月29日(木) 5:50 Laurence Lundblade  <mailto:l...@island-resort.com>>:
> Yes, I much prefer int labels for a small C implementation. Adding support 
> for tstr labels would noticeably increase code size. I hope no one registers 
> a tstr label.  It seems unlikely because algorithms are relatively hard to 
> invent and vet.
> 
> LL
> 
> 
>> On Jul 28, 2021, at 5:47 AM, Carsten Bormann > <mailto:c...@tzi.org>> wrote:
>> 
>> Hi Daisuke,
>> 
>>> On 2021-07-28, at 13:45, AJITOMI Daisuke >> <mailto:ajit...@gmail.com>> wrote:
>>> 
>>> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is not 
>>> necessary because I think the major advantage of COSE is its 
>>> compactness,but I would like to know what you are assuming as the value of 
>>> tstr.
>> 
>> The registrant gets the choice between a text string and an integer.
>> 
>> https://www.iana.org/assignments/cose/cose.xhtml 
>> <https://www.iana.org/assignments/cose/cose.xhtml> lists the registration 
>> procedures for certain ranges, e.g.:
>> 
>> https://www.iana.org/assignments/cose/cose.xhtml#algorithms 
>> <https://www.iana.org/assignments/cose/cose.xhtml#algorithms>
>> 
>> Range Registration Procedures 
>> Strings of length 1  Standards Action With Expert Review
>> Integer values between -256 and 255  Standards Action With Expert Review
>> Strings of length 2  Specification Required
>> Integer values from 256 to 65535 Specification Required
>> Integer values from -65536 to -257   Specification Required
>> Strings of length greater than 2 Expert Review
>> Integer values greater than 65535Expert Review
>> 
>> So labels the representations of which would be 1+0 and 1+1 bytes long 
>> require standards action, 1+2, specification required, and 1+>2, expert 
>> review.
>> 
>> It doesn’t look like anyone has felt a need to register a text string label 
>> for an algorithm ID yet; there are still quite a few 1+1 (and even a few 
>> 1+0!) values available for registration.
>> 
>> I would expect that, until we run out of codepoints, the registration of 
>> text labels will remain an occurrence for special circumstances (which means 
>> we might not be prepared for text labels when we finally actually need them).
>> 
>> Grüße, Carsten
>> 
>> ___
>> COSE mailing list
>> COSE@ietf.org <mailto:COSE@ietf.org>
>> https://www.ietf.org/mailman/listinfo/cose 
>> <https://www.ietf.org/mailman/listinfo/cose>
> 

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

Understood about the use case. Thx for the background.

> On Aug 10, 2021, at 3:13 AM, Göran Selander 
>  wrote:
> 
> Assume that we do want to allow key identifiers to be CBOR ints in certain 
> settings,  what is the best (least intrusive) way to allow this while still 
> maintain compatibility with 'kid's supporting the type bstr? Another 
> alternative to what has been listed below is to define 'kid2' to only be of 
> type int - is that a better option?

I didn’t write actual code to check, but they about the same to me.

‘kid' as int/bstr seems less confusing to me than ‘kid2’. It tells you it does 
exactly the same thing whether it is an int or a bstr.

So my pick is ‘kid’, but ‘kid2’ is OK too.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] tstr values for kty, alg, crv, etc.

[Laurence Lundblade]

Yes, I much prefer int labels for a small C implementation. Adding support for 
tstr labels would noticeably increase code size. I hope no one registers a tstr 
label.  It seems unlikely because algorithms are relatively hard to invent and 
vet.

LL


> On Jul 28, 2021, at 5:47 AM, Carsten Bormann  wrote:
> 
> Hi Daisuke,
> 
>> On 2021-07-28, at 13:45, AJITOMI Daisuke > > wrote:
>> 
>> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is not 
>> necessary because I think the major advantage of COSE is its compactness,but 
>> I would like to know what you are assuming as the value of tstr.
> 
> The registrant gets the choice between a text string and an integer.
> 
> https://www.iana.org/assignments/cose/cose.xhtml 
>  lists the registration 
> procedures for certain ranges, e.g.:
> 
> https://www.iana.org/assignments/cose/cose.xhtml#algorithms 
> 
> 
> Range  Registration Procedures 
> Strings of length 1   Standards Action With Expert Review
> Integer values between -256 and 255   Standards Action With Expert Review
> Strings of length 2   Specification Required
> Integer values from 256 to 65535  Specification Required
> Integer values from -65536 to -257Specification Required
> Strings of length greater than 2  Expert Review
> Integer values greater than 65535 Expert Review
> 
> So labels the representations of which would be 1+0 and 1+1 bytes long 
> require standards action, 1+2, specification required, and 1+>2, expert 
> review.
> 
> It doesn’t look like anyone has felt a need to register a text string label 
> for an algorithm ID yet; there are still quite a few 1+1 (and even a few 
> 1+0!) values available for registration.
> 
> I would expect that, until we run out of codepoints, the registration of text 
> labels will remain an occurrence for special circumstances (which means we 
> might not be prepared for text labels when we finally actually need them).
> 
> Grüße, Carsten
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] Defining CWT, and JWT in UCCS in EAT

[Laurence Lundblade]

Generally agree with what you say below, Carsten.

It is partly my mistake for bringing up 8152bis. I didn’t realize 9051 and 9052 
were out. I only brought it up because someone else suggested we put the CWT 
CDDL in a COSE document.

I believe there has been some confusion between these two:
   1) The CDDL for a CWT
   2) A new CDDL mechanism kinda like .cbor so that the CDDL for an encrypted 
COSE payload can be specified. There would be two parts to this
   2a) Some additional CDDL control add-on to RFC 8610 that is not 
COSE-specific
   2b) An add-on to the COSE spec that makes use of the new CDDL control 
for payload specification

To write a full tight CDDL spec for CWT, we need all off the above. 

But of course the prose-based specification of COSE and CWT are perfectly fine 
now; the above would just allow all of it to be expressed in CDDL, rather than 
partly in prose and partly in CDDL.

(Seems like we’re in a transition period into the CDDL era were we are going to 
have a number of RFCs that add some CDDL to an existing document that isn’t 
fully CDDL. Some of these will be because CDDL itself is evolving. Not a bad 
thing, but a transition nevertheless).

LL



> On Jan 4, 2022, at 8:09 AM, Carsten Bormann  wrote:
> 
> On 2022-01-04, at 14:02, Jeremy O'Donoghue  wrote:
>> 
>> I absolutely would not put the CWT CDDL into RFC8152bis – it is a payload 
>> definition, and RFC8152 is nicely agnostic as to payload right now – it 
>> makes sense to keep it that way.
> 
> Obviously.
> 
> But before I agree with you any further, please note that we are not at 
> liberty to put new work into the two RFCs-to-be (9051 and 9052) that used to 
> be called RFC8152bis.  These are approved documents, and they have long left 
> the WG.
> 
>> I agree with Laurence that RFC8152bis needs a way to indicate the payload 
>> type.
> 
> I don’t understand this sentence, not only because RFC8152bis doesn’t really 
> need anything (see above), but also because there is common header “content 
> type” (label 3), which is a way to indicate the payload type.
> 
> Note that CWT is reasonably well-defined (suffering only by the lack of CDDL 
> definitions for the individual registrations, and of a CDDL framework to put 
> these in).  All we seem to be discussing is the editorial matter where to put 
> a CDDL definition that expresses that content.  We are doing this not because 
> we “need” it, but to make it easier to exercise the well-defined extension 
> points CWT offers.
> 
> I’m not sure I understand the rest of the message given that background.
> There is no need for a CWTbis.  Any document could define that CDDL, even 
> EAT. I’d still prefer to have this CDDL text and the accompanying conventions 
> explained in a separate document.  (No, splitting that out doesn’t need to 
> delay EAT.)  Which WG gets to run the process for agreeing that document is a 
> second-order consideration; the decision should be dominated by quality and 
> expediency considerations (including any rechartering that may be required).  
> There is no need to wait with writing that document while that decision is 
> being made by the SEC ADs; we can simply discuss it by cross-posting to all 
> candidate WGs.
> 
> As a general observation, the IETF is really bad in writing up small tweaks 
> to an existing specification that may be needed for new work unless that 
> happens in the same WG.  Another contributor to the appetite for large, 
> long-running WGs...
> 
> Grüße, Carsten
> 
> 

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] Defining CWT, and JWT in UCCS in EAT

[Laurence Lundblade]

On Dec 17, 2021, at 1:46 PM, Michael Richardson  wrote:
> 
> Laurence Lundblade  wrote:
>> So the question is: where should the CDDL for a CWT go? Here’s the main 
>> options I can think of:
>> - EAT
>> - UCCS
>> - CWTbis (a revision of CWT to include CDDL)
>> - Some other new standard
>> - no where, never create it
> 
> I'd say that it should go into RFC8152bis. 

Seems it would be as odd going into COSE as it would EAT. 

It would create a circular dependency between CWT and COSE. COSE payloads can 
be lots of different things. We don’t want to collect the CDDL for various the 
COSE payloads in COSE. The separation between COSE and its payloads is very 
clean right now.

What should go into COSE is modifications to the COSE CDDL that defines a 
template by which the type of the payload can be specified (that template would 
use a .cbor control; see it done in the replicated COSE CDDL in CoSWID section 
7 and 8), but that is not what this thread is about.

Below is the CDDL that this thread is about.

If the below CDDL went into its own document, it would be short. Below is the 
bulk of the document.

What WG and what charter? It needs to be standards track.

LL


   ; This is the fundamental definition of a Claims-Set for both CBOR
   ; and JSON. It is a set of label-value pairs each of which is a
   ; claim.
   ;
   ; In CBOR the labels can be integers or strings with a strong
   ; preference for integers.  For JSON, the labels are always strings.
   ;
   ; The values can be anything, with some consideration for types that
   ; can work in both CBOR and JSON.

   Claims-Set = {
   * $$claims-set-claims,
   * Claim-Label .feature "extended-label" => any
   }

   Claim-Label = int / text

   string-or-uri = tstr
   time-int = #6.1(int)

   ; This is CDDL for the 7 individual claims that are defined in CWT
   ; and JWT.  This CDDL works for either CBOR format CWT or JSON format
   ; JWT.

   $$claims-set-claims //= (iss-label => string-or-uri)
   $$claims-set-claims //= (sub-label => string-or-uri)
   $$claims-set-claims //= (aud-label => string-or-uri)
   $$claims-set-claims //= (exp-label => ~time)
   $$claims-set-claims //= (nbf-label => ~time)
   $$claims-set-claims //= (iat-label => ~time)
   $$claims-set-claims //= (cti-label => bytes)

   iss-label = 1
   sub-label = 2
   aud-label = 3
   exp-label = 4
   nbf-label = 5
   iat-label = 6
   cti-label = 7



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] CDDL for CWT, JWT, UCCS and UJCS

[Laurence Lundblade]

Hi folks,

Sorry for the large cross-post, but wanted to be sure everyone is a little 
aware of this.

The latest EAT draft  
 efines CDDL for 
a Claims-Set, the main collection of label-value pairs that is central to CWT 
and JWT. It is intended to work for both CBOR and JSON (and maybe other 
encodings). When you want to define a new claim for a CWT or JWT you can write 
it in CDDL and both the CBOR protocol implementer and JSON protocol implementer 
know what to do. Should even work with the CDDL validation tools. See here 
.

There’s a few other things in this EAT draft:
The Claims-Set CDDL applies to UCCS
It defines UJCS (which is a one-liner in CDDL) in case you don’t want to use 
JWT NULL algorithm for something like EAT Attestation Results
It defines a way to put a CWT inside a JWT and vice versa since EAT needs 
nested tokens

A common format for signed/encrypted/unsecured collections of CBOR/JSON 
label-value pairs seems generally useful for more than just EAT. The common 
format could give some code re use too.

I’m not sure that this belongs in the EAT draft. I put it in EAT to get it 
published in a coherent way for the basis of discussion. I’m expecting 
discussion of this in the RATS sessions at IETF 112 (Chairs / ADs, maybe you 
have an opinion on where further discussion can happen).

LL


P.S. This turned up some issues around how CDDL for CBOR+JSON works and how to 
validate with the cddl validation tool:
Integer vs text labels
How to represent byte strings so they get b64 encoded and validate
An alternative to CBOR tags for JSON

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

[Laurence Lundblade]

Hi,

Not sure where this will go, but thought it worth running up the flag pole.

To validate EAT CDDL I’m pulling in *all* of these into one:
— CoSWID CDDL
— SUIT CDDL
— COSE CDDL
— EAT/CWT CDDL

I have diag format EAT example tokens with claims that are CoSWIDs that 
validate against the above.

CoSWID replicates and modifies a lot of COSE CDDL in normative text primarily 
so it can fully specify the COSE payload with a .cbor control. 

SUIT doesn’t replicate COSE. It specifies the COSE payload in prose.

I have thus far taken SUITs approach as I don’t want to replicate and modify 
COSE CDDL. EAT also must support nesting of COSE encryption inside COSE signing 
and such. (It seems CoSWID’s approach actively prohibits COSE encryption).

In an ideal world, I think the CDDL in the COSE struct draft would some how use 
a CDDL template through which one could specify the CDDL for the COSE payload.  
This CDDL template would work for COSE signed, then encrypted or encrypted then 
MAC’’d and any other nesting of COSE. In this ideal world CoSWID wouldn’t have 
to replicate CDDL from COSE and SUIT and EAT could use it too. I’m not sure 
this ideal COSE CDDL is possible though.

Has anyone considered writing the COSE CDDL this way?

Another problem with the replicated COSE CDDL in CoSWID in the EAT document 
build and validate is that there is collision between the names of CDDL rules. 
I’m just manually tweaking stuff to get around this. CDDL name spaces would fix 
this.


If the world stays the same (no change to COSE struct document or CoSWID) I can 
make EAT work as follows:
 - No .cbor control to specify the COSE payload, only prose
 - Some non-normative, unpublished glue CDDL that is part of the EAT document 
build and example validation script is needed.

LL








___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

[Laurence Lundblade]

Hi Hannes,

This is only about a tiny little part of the EAT spec and is not important for 
EAT publication.

This is only about how to use CDDL with COSE. It’s not about interoperability 
or what claims there are in the EAT spec.

Hannes, you can probably ignore this thread if you want.


To go further…

I am observing how two different protocols that use COSE specify what the COSE 
payload should be. I am interested because EAT must specify this too. I noticed 
that they do it different:
— CoSWID goes to a lot of trouble to use CDDL via a .cbor control
— SUIT just uses simple prose, not CDDL

Note that I am only talking about the CDDL link between COSE and the COSE 
payload. Clearly SUIT, EAT and CoSWID all of which are COSE payloads are 
described in CDDL. See details below for what I mean by the link.

I was quite happy with simple prose, but then I saw what CoSWID did. It seemed 
worth checking in because CoSWID went to a lot of trouble to do what it did.

Right now, I think simple prose is fine and even prefer it. 

If I were the CoSWID author I would probably stick with simple prose so the 
CDDL for COSE doesn’t have to be replicated and to allow for COSE encryption.

If I were the draft-ietf-cose-rfc8152bis-struct author, I’d make an attempt at 
a CDDL template for COSE so that future standards could do what CoSWID did 
without replicating COSE CDDL.

If that turned out well, then for future protocols after publication of 
draft-ietf-cose-rfc8152bis-struct, I’d consider using the CDDL template for 
COSE messages.

LL


Here’s the link between for COSE payload for CoSWID. It is in blue in this CDDL 
that is replicated from COSE. It occurs in  section 7 of CoSWID. 
<https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-19#section-7>

   COSE-Sign1-coswid = [
   protected: bstr .cbor protected-signed-coswid-header,
   unprotected: unprotected-signed-coswid-header,
   payload: bstr .cbor payload,
   signature: bstr,
   ]


Here it is in prose in SUIT in section 5.2 
<https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-16#section-5.2>:

 These blocks
   are one of:


   *  COSE_Sign_Tagged

   *  COSE_Sign1_Tagged

   *  COSE_Mac_Tagged

   *  COSE_Mac0_Tagged

   Each of these objects is used in detached payload mode.  The payload
   is the bstr-wrapped SUIT_Digest.


Here it is in CWT, section 7.1 in prose 
<https://datatracker.ietf.org/doc/html/rfc8392#section-7.1>

   1.  Create a CWT Claims Set containing the desired claims.

   2.  Let the Message be the binary representation of the CWT Claims
   Set.

   3.  Create a COSE Header containing the desired set of Header
   Parameters.  The COSE Header MUST be valid per the [RFC8152 
<https://datatracker.ietf.org/doc/html/rfc8152>]
   specification.

   4.  Depending upon whether the CWT is signed, MACed, or encrypted,
   there are three cases:

   *  If the CWT is signed, create a COSE_Sign/COSE_Sign1 object
  using the Message as the COSE_Sign/COSE_Sign1 Payload; all
  steps specified in [RFC8152 
<https://datatracker.ietf.org/doc/html/rfc8152>] for creating a COSE_Sign/
  COSE_Sign1 object MUST be followed.


EAT inherits this from CWT so it doesn’t need to say it explicitly. 

However EAT uses CDDL so it is a possibility that EAT can do what CoSWID did.



> On Dec 8, 2021, at 4:46 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Carsten,
> 
> I suspect Laurence is sending this email because of his work on EAT. I am 
> arguing that an attempt to improve the CDDL for the mentioned specs will not 
> lead to any improvement at all because the problem is elsewhere. I am saying 
> that because I have just spent many hours reading the EAT spec.
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Carsten Bormann 
> Sent: Wednesday, December 8, 2021 1:37 PM
> To: Hannes Tschofenig 
> Cc: Laurence Lundblade ; cose ; 
> c...@ietf.org; Henk Birkholz 
> Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD
> 
> On 2021-12-08, at 13:30, Hannes Tschofenig  wrote:
>> 
>> EAT by itself is not really an interoperable spec. COSE on its own is not 
>> interoperable either.
> 
> If I guess about the definition of "interoperable spec” you are using here, 
> ASCII is not an interoperable spec either - you still have to agree on what 
> the text means…  Still, ASCII was kind of useful as the basis for a lot of 
> interoperability, I think.
> 
> I think the point here was to shape some CDDL that makes it easier to talk 
> about the way a more specific (interoperable?) spec uses COSE (which does 
> have CDDL, just not in a way that usually can be integrated as-is to express 
> the additional constraints a COSE-using specification typically makes).
> 
> Grüße, Carsten
> 
> IMPORTANT NOTICE: The contents of this email and a

Re: [COSE] [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

[Laurence Lundblade]

On Dec 8, 2021, at 8:08 AM, Hannes Tschofenig  wrote:
> 
> 
> PS: I am not sure whether the ".cbor control" is an important concept in this 
> conversation.

It is absolutely critical and central to the topic I brought up. It is the only 
thing I wanted to talk about.

But, happy for you to discuss other things about COSE.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

[Laurence Lundblade]

On Dec 16, 2021, at 7:18 AM, Michael Richardson  wrote:
> 
> 
> Laurence Lundblade  wrote:
>> For example, I find what CoSWID does awkward:
>> - Replicating code and definitions generally seems poor practice
>> - It excludes the possibility for encryption
>> - It doesn’t define what EAT needs, a signed or unsigned message that
>> is always a tag, somewhat motivating me to replicate/author CoSWID CDDL
>> in EAT.
> 
> I think that this is because we haven't gotten a library/public-include
> system for CDDL.  So the urge is to make documents self-contained.

It didn’t replicate all of the COSE CDDL, just the parts to enable control of 
the headers and to allow specification of the payload with .cbor.

It did replicate not enough to be self-contained, so I don’t think that is the 
reason.

Also, it doesn’t just replicate the CDDL, it modifies it! This is so the CDDL 
also controls some of the COSE headers. (Again, I find this odd and awkward; 
CWT and EAT don’t try to control the COSE headers).

I think the reason is so the CDDL specification is more thorough and covers 
more of the CoSWID protocol. It is so prose is not relied upon for these.

It is also a cool use of CDDL templates.

LL



Note, that I have replicated COSE CDDL in the EAT document build system so I 
can do thorough CDDL validation of the EAT examples, but it is not part of the 
published document. I’m also using curl to fetch CoSWID and SUIT CDDL for this. 
All of this is because we don’t have a scheme for publish/reference, #includes 
and such. If all this broke because the URLs changed or the CDDL in CoSWID CDDL 
in GitHub was refactored or such, all that would break is the CDDL validation. 
The EAT document and building of the EAT document doesn’t rely on any of it. 
(Thanks Thomas)

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

[Laurence Lundblade]

I guess for me this thread is about the state of the art for use of CDDL.

- CDDL seems just fine for protocol messages
- CDDL is missing some pieces when combining CDDL-defined protocols (name 
spaces, a publication and reference mechanism)
- CDDL is missing some pieces for specifying encryption payloads and maybe 
draft-ietf-cose-rfc8152bis-struct is not using what is available now for 
signing/MAC

(This is not any criticism of CDDL; just observing more good things we could do 
with it).

It seems a relatively new thing where we take the formal protocol specification 
and computationally and deterministically validate messages and examples the 
way I’m doing it in EAT (Thx Thomas) and probably others are doing. I haven’t 
seen it done with ABNF. We usually don’t do it with ASN.1 and [BDC]ER (lack of 
tools?). Not sure about YANG.

I don’t think it is mandatory that we do this formal validation of 100% of a 
protocol. Almost 10,000 RFCs and the majority don’t.

So it seems that specifying COSE payloads with .cbor is a “nice to have”, but 
not mandatory.  We’re still kind of figuring out how to do it.

For example, I find what CoSWID does awkward:
- Replicating code and definitions generally seems poor practice
- It excludes the possibility for encryption
- It doesn’t define what EAT needs, a signed or unsigned message that is always 
a tag, somewhat motivating me to replicate/author CoSWID CDDL in EAT.

So where I land on this now is to use CDDL as much as possible (in EAT), but 
don’t push it to where it gets awkward or contorted. Hope that CDDL and COSE 
get improved so that EATbis and future protocols can easily do more CDDL.

LL



> On Dec 9, 2021, at 10:54 AM, Michael Richardson  wrote:
> 
> 
> {noticing this is not CC'ed to SUIT or SACM or RATS}
> 
> Laurence Lundblade  wrote:
>> I am observing how two different protocols that use COSE specify what the 
>> COSE payload should be. I am interested because EAT must specify this too. I 
>> noticed that they do it different:
>> — CoSWID goes to a lot of trouble to use CDDL via a .cbor control
> 
> probably because CoSWID author (Henk) is also CDDL author, and therefore is
> more expert at using CDDL.
> 
>> — SUIT just uses simple prose, not CDDL
> 
> I think that the question is what kind of advice CBOR and COSE WG should 
> provide to
> other WGs about whether or not to explain things with .cbor controls.
> 
>> Here’s the link between for COSE payload for CoSWID. It is in blue in this 
>> CDDL that is replicated from COSE. It occurs in  section 7 of CoSWID. 
>> <https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-19#section-7>
> 
>> COSE-Sign1-coswid = [
>> protected: bstr .cbor protected-signed-coswid-header,
>> unprotected: unprotected-signed-coswid-header,
>> payload: bstr .cbor payload,
>> signature: bstr,
>> ]
> 
> ...
> 
>> EAT inherits this from CWT so it doesn’t need to say it explicitly.
>> However EAT uses CDDL so it is a possibility that EAT can do what CoSWID did.
> 
> That seems like the right way to me.
> It's unclear to me which direction will work better for people who are not
> CDDL experts.  Consider  that a formal language like CDDL might actually be
> easier to understand for non-native-english speakers!
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Looking for COSE libraries and open source implementations

[Laurence Lundblade]

Here’s the GitHub lookup  on the COSE key word: https://github.com/topics/cose

COSE-C is the original, but it is not maintained now: 
https://github.com/cose-wg/COSE-C

My own maintained implementation (just signing so far) is here: 
https://github.com/laurencelundblade/t_cose

LL


> On Jul 26, 2021, at 6:13 AM, g_e_montenegro=40yahoo@dmarc.ietf.org wrote:
> 
> Hi Folks,
>  
> I’m looking at COSE versus more traditional alternatives, pros and cons, and 
> a huge cons would be access to open source implementations and libraries.
>  
> Anybody know of a good source of information about COSE libraries and open 
> source implementations?
>  
> I’m aware of https://github.com/cose-wg , which 
> has some good pointers, but they appear somewhat outdated. 
>  
> Thanks for any hints.
>  
> Gabriel
> ___
> COSE mailing list
> COSE@ietf.org 
> https://www.ietf.org/mailman/listinfo/cose 
> 
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

[Laurence Lundblade]

For EAT, putting the profile claim in a header could be really useful, 
especially if the EAT is encrypted.

The profile claim tells you the something about the format and type of the EAT, 
maybe even which processor to hand it off too. It’s nice to be able to do the 
hand off without having to decrypt and verify. 

The intended use claim is another good candidate for this header.

I like the addition a lot.

LL



> On Mar 13, 2022, at 1:47 PM, Tobias Looker  wrote:
> 
> Hi Hannes,
> 
> I can elaborate.
> 
> Encrypted CWTs - In some circumstances CWT claims can be useful to have 
> available for processing prior to decryption. For example the iss claim can 
> be used to indicate to a recipient of an encrypted CWT how it should be 
> decrypted, by informing the recipient who encrypted (and potentially signed) 
> it.
> 
> Detached Signature - In cases where a detached signature COSE structure is 
> being used the payload can be un-available (or of invalid form) to express 
> CWT claims. A concrete example is being able to express who signed the 
> detached signature structure (using the iss claim) and when it expires (using 
> the exp claim).
> 
> Thanks,
>  
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0>
>   
>  
> Tobias Looker
> MATTR
> CTO
> +64 (0) 27 378 0461
> tobias.looker@mattr.global <mailto:tobias.looker@mattr.global>
>  
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0>
>   
>  
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0>
>
>  
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0>
>   
>  
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=0>
> 
> This communication, including any attachments, is confidential. If you are 
> not the intended recipient, you should not read it - please contact me 
> immediately, destroy it, and do not copy or use any part of this 
> communication or disclose anything about it. Thank you. Please note that this 
> communication does not designate an information system for the purposes of 
> the Electronic Transactions Act 2002.
> 
> From: Hannes Tschofenig  <mailto:hannes.tschofe...@arm.com>>
> Sent: 12 March 2022 01:45
> To: Mike Jones  <mailto:michael.jo...@microsoft.com>>; Anders Rundgren 
> mailto:anders.rundgren@gmail.com>>; 
> Laurence Lundblade mailto:l...@island-resort.com>>
> Cc: Tobias Looker  <mailto:tobias.looker@mattr.global>>; cose@ietf.org <mailto:cose@ietf.org> 
> mailto:cose@ietf.org>>
> Subject: RE: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in 
> COSE Headers
>  
>

Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

[Laurence Lundblade]

> On Mar 7, 2022, at 9:23 PM, Anders Rundgren  
> wrote:
> 
> On 2022-03-04 8:08, Carsten Bormann wrote:
>> On 2022-03-04, at 07:54, Anders Rundgren  
>> wrote:
>>> 
>>> - Collect key and algorithm data from the authorization signature object.
>>> - Save and Remove FIDO "authenticatorData" and FIDO "signature" from the 
>>> CBOR container.
>> This is what we called the “transform” in the beloved XMLDSig.
>> The complexities of this step can be the basis of interesting 
>> vulnerabilities (or interoperability failures).
> 
> Since I had not worked with low-level encoders and decoders, I spent a couple 
> of days in the lab (kitchen actually).
> 
> To not be dependent on my own stuff (which of course works flawlessly since 
> it was from the beginning designed with FIDO in mind), I applied the more 
> universal CSF (CBOR Signature Format) to Laurence's excellent QCBOR library.  
> This is what I came up with:
> https://github.com/cyberphone/D-CBOR/blob/main/verify-demo/csf-verifier.c

Your code accesses private QCBOR data structures to make this work, but no fear 
because 1) this part of QCBOR is not going to change and 2) I’m working on a PR 
to allow access to encoded maps and arrays 
. (I’m  bit bogged down on 
QCBOR PRs these days)

> The actual transform part is performed by FOUR LINES of C.  This was a 
> surprise even to me.
> 
> Carsten, you should be proud; CBOR is the by far best data interchange format 
> for blending with cool cryptographic constructs!
> 
> Could wrapping your precious data in bstr just in order to sign it, be headed 
> for obsolescence? :)

I suspect not because decoders in other languages won’t be so easy to modify 
for this.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

I believe the targets motivating full encoding variance for EAT are pure 
hardware implementations. Think of a TPM-like chip that outputs EAT. Or a HW IP 
core that ARM sells for your SoC.

I’m pretty sure this is quite possible without any SW (except the driver SW for 
the EAT attestation core, network stack and such that doesn’t need to be 
secure).

Experience with SW implementation like QCBOR is not particularly relevant.

LL




> On Feb 23, 2022, at 2:42 PM, Michael Richardson  wrote:
> 
> 
> I've read the exchange between Laurence and Carsten and Anders.
> 
> If we accept that the only constrained part will be the Attesting Environment
> on the Attester, and that all other systems (Verifier, RP) are at least >
> class 2 (RFC7228), then we clearly should be optimizing for ease of encoding.
> 
> While my experiences with Op-Tee is rather shallow (I compiled it once),
> my impression is that it is at least class 2 in size.  A bit of memory
> allocation won't be a problem, or pre-allocating a few kilobytes for the CWT
> won't be a problem.
> 
> I have experience with QCBOR, TinyCBOR and NanoCBR.
> My experience is that indefinite length strings are not really needed as long
> as one is encoding into a memory buffer.  Noting where the length box is and
> filling it in later isn't impossible, but it certainly is harder if one
> doesn't have an estimate of the size to know which integer size to use.
> Worst case, one can assume that the strings can't exceed the size of the
> output buffer!
> 
> My claim that an output buffer is needed is that we are going to sign it all,
> and while one can construct SHA256 hash calculators that don't need the bytes 
> all
> in a row, it's such a pain to do generically, that if one is doing it, one is
> creating a bespoke hasher.
> 
> I see no strong reason to rule indefinite encodings out: Verifiers and RPs 
> should be
> prepared to process them.  I would not encourage their use by encoders.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> ___
> RATS mailing list
> r...@ietf.org
> https://www.ietf.org/mailman/listinfo/rats

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

> On Feb 23, 2022, at 1:08 PM, Carsten Bormann  wrote:
> 
> Hi Laurence,
> 
>> 
>> I know in reality most decoders will handle non-preferred serialization, but 
>> I don’t see anything in section 5.2 that says that they must. (non-preferred 
>> is still well formed).
> 
> What part of the first sentence of section 5.2:
> 
>>> A generic CBOR decoder can decode all well-formed encoded CBOR data items 
>>> and present the data items to an application.
> 
> ...could we have phrased better?


Well, um, maybe.  :-)

It’s a small sentence with potentially big implications. 

If your generic decoder is like the pseudo code the implications aren’t big, 
but for decoders like QCBOR that do a lot more work for you, the implications 
are large — deep combined nesting of interleaved definite length and indefinite 
lengths maps and arrays, huge indefinite length strings, multiple levels of tag 
nesting for a data item that is a map label, a nested set of maps that is used 
as a map label,…

I haven’t checked, but there might not be very many truly conformant generic 
decoders. QCBOR definitely isn’t, because it has limits like a max of 4GB for 
encoded input, max levels of map, array and tag nesting and such to be 
efficient with code size and memory.

That said, probably most decoders can handle non-preferred integers, the topic 
at hand, just fine because it is trivial.

Yes you are of course right that 5.2 that defines generic decoders says 
non-preferred serialization must be supported.

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

On Feb 21, 2022, at 8:31 AM, Carsten Bormann  wrote:
> 
> On 2022-02-21, at 17:15, Anders Rundgren  
> wrote:
>> 
>> I couldn't find any valid reason for using JSON
> 
> We seem to have found an area where we agree :-)

Not out for a big debate here or to win hearts and minds, but here’s the 
reasons for JSON.

The overwhelming one is that JSON use in the world is something like ten times 
CBOR use. People and libraries that implement it well are a dime a dozen. CBOR 
isn’t even close.

EAT is not just for small embedded devices. People want to use it to prove one 
cloud service to another, to prove an Android app to a cloud service and so on.

EAT is used for both Attestation Evidence and Attestation Results. Attestation 
Results is a B-to-B interaction and most of them these days are JSON.

The RATS charter suggests (but does not require) work in both JSON and CBOR.

The big cross-bar diagram in RATS architecture 

 says that RATS should be adaptable to many encoding formats (CWT, JWT, TPM, 
X.509, other…), so we’re lucky we’re only having to do two.

I personally, would mostly be OK with CBOR/COSE/CWT, but it seems to me that 
JSON is so heavily used that we would be limiting RATS/EAT up take if we 
limited ourselves to it.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

On Feb 21, 2022, at 6:31 AM, Hannes Tschofenig  
wrote:
> 
> I could, however, imagine to write an COSE implementation that does not 
> require the entire CWT be held in RAM since the digital signature just covers 
> the hash of the CWT and you can use a rolling hash.



No need to imagine. For signing, t_cose  
allows you to create COSE headers, 
then CBOR-encode the payload an item at a time and then append the signature. 
t_cose does require the completed COSE message be in RAM, but not the input 
payload.

LL



___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

> On Feb 22, 2022, at 1:19 PM, Carsten Bormann  wrote:
> 
> On 2022-02-22, at 20:45, Laurence Lundblade  wrote:
>>> 
>>>> The main example I can think of is EAT in pure HW (e.g., a TPM-like chip 
>>>> that outputs EAT). Outputting fixed length integers will make that HW 
>>>> simpler.
>>> 
>>> Any CBOR decoder will be happy with decoding this.
>> 
>> True, but decoders aren’t actually required to so by RFC 8949, right? Second 
>> paragraph here.
> 
> Generic CBOR decoders are.
> You might cook up an application specific decoder for an application that 
> doesn’t need non-preferred encoding, but that would not be a full CBOR 
> decoder.

I know in reality most decoders will handle non-preferred serialization, but I 
don’t see anything in section 5.2  
<https://www.rfc-editor.org/rfc/rfc8949.html#name-generic-encoders-and-decode>that
 says that they must. (non-preferred is still well formed).


>>> There is only one place I have found so far where EAT actively causes an 
>>> interoperability issue:  By ruling out preferred serialization for floating 
>>> point values.  Creating a separate CBOR dialect by ruling out 
>>> half-precision encoding might save 8 lines of C code in a decoder (which 
>>> you can simply copy from 
>>> https://www.rfc-editor.org/rfc/rfc8949.html#name-half-precision),
>> 
>> It’s not just 8 line of code because it requires a floating library and/or 
>> floating-point hardware.  That isn’t available in some places. For example 
>> some implementations of Arm TrustZone don’t support it.
> 
> So what do you do with the lat/lon information then?
> (The half.c code doesn’t actually need floating-point hardware, BTW, if you 
> manage to do an ldexp in software.  But you don’t need to do that if you 
> can’t process the data at all — just keep the undecoded representation then.)

Understood.

Pulling an ldexp library could be a big deal. It could increase code size by a 
lot.


>>> but ensures that a standard CBOR encoder cannot be used without supplying 
>>> encoding options.  Not a smart move.
>> 
>> Seems like it would be dumb for a CBOR encoder to use floating point for the 
>> cti claim. Would some really do that?
> 
> This discussion was more about lat/lon.  
> cti (label 7) is a byte string, so there is no such problem there.

Lat/long needs double precision float to be useful to beings the size of humans 
on a planet of earth's size. Half-precision has so little precision on a planet 
of earth's size that it is useless for location.

I mis-remembered “iat” as “cti”. Iat is a time stamp. A uint64 can represent 
everything needed for a time stamp, 1 second precision and +/- 500 million 
years. Float adds no value.

So EAT
- disallows half-precision in location, but allows doubles to relieve a decoder 
from implementing half-precision
- disallows float for iat to relieve a decoder from implementing float, 
assuming it is not implementing location (many EAT implementations will not 
support location)

There is no general requirement related to float for all claims in EAT. Future 
claims are free to do what they want.

I’m trying to be thorough and considerate of the receiver here so they know 
exactly what they have to do and so the requirements are minimized. Definitely 
open to changes here.



>> The serialization that is of the most concern is indefinite lengths for 
>> strings and maps. CBOR, COSE and CWT all allow them and there is advantage 
>> to use them on the encoding side so they shouldn’t be ruled out.
> 
> Right, for data objects that need “streaming” (write to network while still 
> being generated).  Not so sure about objects that need to be signed.
> 
> But your point is that the decision to not allow indefinite length strings 
> may be a significant win for the decoder, so that is a valid case for having 
> an encoding option.  But the decoder doesn’t have to know that this option 
> was enabled on the encoder side, so there is no interoperability problem.
> 
>> The decode for them is definitely more work and makes the decoder larger.  
>> For example, indefinite length strings need to be coalesced in to one and 
>> that requires a memory allocator or at least more memory management and 
>> copying than definite length strings. 
> 
> (Or you can just use the partial strings in sequence.)
> 
>> QCBOR’s decode API is the same for indefinite length maps and arrays as it 
>> for definite length maps and arrays, but that wasn’t easy to implement. I 
>> think some decoders require the protocol implementor to be conscious of the 
>> distinction.
> 
> Right, a constrained decoder would usually offer the string segment

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

Got it. Made PR to remove half-precision exclusion 
 from location. Thanks for the 
discussion and foot notes!

Checked a few decoders and can see that half-precision decoding is often 
supported.

LL

> On Feb 23, 2022, at 1:08 PM, Carsten Bormann  wrote:
> 
>>> 
>>> This discussion was more about lat/lon.  
>>> cti (label 7) is a byte string, so there is no such problem there.
>> 
>> Lat/long needs double precision float to be useful to beings the size of 
>> humans on a planet of earth's size. Half-precision has so little precision 
>> on a planet of earth's size that it is useless for location.
> 
> That is not what this is about.
> 
> Saying “You need 16 bits to express the unsigned integer weight of a street 
> vehicle in kg” does not mean that I can’t encode the weight of my bike in 8 
> bits.
> What the current text in EAT says is equivalent to "you can’t ever use 8 bits 
> because some vehicles need 16".  That is not smart.
> 
>> I mis-remembered “iat” as “cti”. Iat is a time stamp. A uint64 can represent 
>> everything needed for a time stamp, 1 second precision and +/- 500 million 
>> years. Float adds no value.
> 
> Right, but that is OK: It is a restriction at the data model level.  You are 
> asking the application not to feed floats into the generic encoder.
> 
> (Note that we strengthened the little wall between integer and floating point 
> for RFC 8949, after seeing that RFC 7049 was confusing people a lot.)
> 
>> 
>> So EAT
>> - disallows half-precision in location, but allows doubles to relieve a 
>> decoder from implementing half-precision
> 
> Bad.  Half-precision (binary16) is not a different type at the data model 
> level, it is just an efficient way to represent certain numbers in your data 
> model.
> Binary16 has a significand [sic] precision of 11 bits.  Binary32 has 24 bits.
> So if you feed random binary32 lat/lon (~ meter precision) to your generic 
> encoder, every 8192th will be encoded in half-precision (*).
> 
> Since lat/lon values are probably approximately evenly distributed, that by 
> itself is not a reason to implement half-precision.
> The fact that CBOR preferred encoding does employ half-precision is.
> Deviating from that by disallowing binary16 is expensive: You no longer can 
> employ generic encoders.
> 
> Don’t do that.
> 
>> - disallows float for iat to relieve a decoder from implementing float, 
>> assuming it is not implementing location (many EAT implementations will not 
>> support location)
> 
> Good(**).  That selection of integer second timestamps is a part of your data 
> model.  
> You can do that, and no generic encoder will suddenly turn your integer iat 
> number into a float.
> (Again, with RFC 7049, it possibly could have, but we fixed that.)
> 
> Grüße, Carsten
> 
> (*) Note that a similar thing happens in JSON: numbers that happen to be 
> whole numbers will be encoded without fractional parts (10.0 becomes 10).
> In certain decoder implementations, that makes them a different “type" than 
> 10.0 or 1e1 or 0.1e2 etc., causing breakage.
> But the JSON data model only has numbers, not integers as a separate, 
> incompatible type, so these decoders are broken with applications that simply 
> expect numbers.
> (Find ISO 6093:1985 for some fascinating history in this space :-)
> 
> (**) ((I’m not making any representation on whether applications need to know 
> with a precision of smaller than a second when your EAT was issued.  
> I really can’t imagine that, but that is proof by lack of imagination; I do 
> assess that the cost of enabling that is higher than the benefits.  
> But that is true until someone has a convincing counterexample…  
> Consolation is that these people can introduce a float iat = “fiat” :-)))
> 

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

[Laurence Lundblade]

Makes sense to me. Helps out for the EAT claim named “profile” which gives 
information about the type of the token you might want before fully verifying 
it. Addresses an issue Anders brought up about the profile claim.

LL


> On Mar 2, 2022, at 9:34 AM, Mike Jones 
>  wrote:
> 
> The use case is the same as that which motivated Section 5.3 of JWT 
> “Replicating Claims as Header Parameters” 
> https://datatracker.ietf.org/doc/html/rfc7519#section-5.3 
>  – encrypted CWTs 
> for which you’d like to have unencrypted instances of particular claims to 
> determine how to process the CWT prior to decrypting it.  Note that 
> https://datatracker.ietf.org/doc/html/rfc7519#section-10.4 
>  explicitly 
> registers the “iss”, “sub”, and “aud” claims as JWE header parameter values 
> exactly for this purpose.
>  
> This draft defines a syntax for COSE to likewise enable the corresponding CWT 
> claims to be passed in the clear in the COSE header, just as JWT claims can 
> be replicated as JOSE header parameters when needed.
>  
>   
> -- Mike
>  
> From: Hannes Tschofenig  
> Sent: Wednesday, March 2, 2022 12:21 AM
> To: Tobias Looker ; cose@ietf.org
> Cc: Mike Jones 
> Subject: RE: Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE 
> Headers
>  
> Hi Tobias, 
>  
> Could you say something about the use cases or provide an example of what you 
> want to accomplish?
>  
> Ciao
> Hannes
>  
> From: COSE mailto:cose-boun...@ietf.org>> On Behalf 
> Of Tobias Looker
> Sent: Wednesday, March 2, 2022 5:32 AM
> To: cose@ietf.org 
> Cc: m...@microsoft.com 
> Subject: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE 
> Headers
>  
> Hi All,
>  
> This is an email to introduce the newly submitted draft titled "CBOR Web 
> Token (CWT) Claims in COSE Headers", the current abstract is as follows.
>  
> "This document describes how to include CBOR Web Token (CWT) claims in the 
> header parameters of any COSE structure. This functionality helps to 
> facilitate applications that wish to make use of CBOR Web Token (CWT) claims 
> in encrypted COSE structures and/or COSE structures featuring detached 
> signatures, while having some of those claims be available before decryption 
> and/or without inspecting the detached payload."
>  
> https://datatracker.ietf.org/doc/draft-looker-cose-cwt-claims-in-headers/ 
> 
>  
> As covered in the introduction of this draft, a similar mechanism already 
> exists for JWT and we see value in providing a way to do the same with CWTs.
>  
> Thanks,
> 
>  
> 
>   
>  
> 
> Tobias Looker
> 
> MATTR
> CTO
> 
> +64 (0) 27 378 0461
> tobias.looker@mattr.global 
>  
> 
>   
>  
> 
>
>  
> 

Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

[Laurence Lundblade]

Yes, the only issue of yours that addresses is the ability to access the 
profile claim before decoding, decrypting and verifying the COSE payload.

LL

> On Mar 2, 2022, at 11:38 PM, Anders Rundgren  
> wrote:
> 
> On 2022-03-02 19:33, Laurence Lundblade wrote:
>> Makes sense to me. Helps out for the EAT claim named “profile” which gives 
>> information about the type of the token you might want before fully 
>> verifying it. Addresses an issue Anders brought up about the profile claim.
> 
> Not so fast  :)  I brought up a bunch of things which can be illustrated by 
> this (just implemented...) example of an encryption object:
> 
> 211(["https://example.com/myobject; <https://example.com/myobject>, {
>   / COSE content encryption algorithm = A256GCM /
>   1: 3,
>   / Key encryption container /
>   2: {
> / COSE Key encryption algorithm = ECDH-ES+A256KW /
> 1: -31,
> / Key identifier /
> 3: "mykey",
> / Ephemeral key /
> 5: {
>   / COSE Key type = OKP /
>   1: 1,
>   / COSE Curve = X25519 /
>   -1: 4,
>   / COSE X coordinate /
>   -2: h'33a04b83d4428824b6d5477522d4a88fac4441122bc46136c0203faa308c3929'
> },
> / Encrypted key /
> 10: 
> h'e08977c25aeccaecd63b3367de2e2b8f700c82e098ad1e5099d9db510920ccff14debf820427e4ba'
>   },
>   / Tag /
>   8: h'59a84826983e3247fbec4295f75cc138',
>   / IV /
>   9: h'fd8556c122cff2bc128d5119',
>   / Encrypted data /
>   10: 
> h'e16b16c29da5163eb0131dd1f10f080f8850f55df2ae9d89a3b839ad50952858445f290dfb60'
> }])
> 
> The core of this builds on Deterministic CBOR which unleashes the true power 
> of CBOR in a way legacy solutions do not.   The enhancements include:
> Eliminating wrapping of header and (unencrypted) application data.
> Using the entire container (modulo the algorithm output variables which are 
> added lastly) as input to a signature process and to the authentication part 
> of an encryption process.  In the example that includes the top-level CBOR 
> tag as well.  cryptoOperation(cborObject.encode()) is all that it takes on 
> the encoder's side.
> This is pretty much what the X.509 folks have been doing from the very start 
> so there is close to zero innovation here 
>  <https://apps.timwhitlock.info/emoji/tables/unicode#emoji-modal>
> 
> In the example I have also used a URL as profile/object type indicator since 
> IANA CBOR custom tag 1537244 or whatever you end-up with, simply isn't pretty 
> enough :)  To be more serious: URLs are decentralized and would in this 
> context probably be browseable as well.
> 
> Cheers,
> Anders
> 

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

> On Feb 23, 2022, at 1:08 PM, Carsten Bormann  wrote:
>> 
>> Pulling an ldexp library could be a big deal. It could increase code size by 
>> a lot.
> 
> Yes. 
> I should probably write some alternative C code that is a couple lines longer 
> but doesn’t need ldexp.
> (But what do you do with the binary32 then?)

I did that with shifts and masks and got a good education about floating point. 
:-)

https://github.com/laurencelundblade/QCBOR/blob/master/src/ieee754.c

More on the other parts later. Appreciate the discussion.

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

EAT allows for use of the different CBOR serializations just like COSE and CWT 
so particular deployments can choose what is best for them. It is important to 
continue to allow all serializations in EAT for the reasons that they exist in 
the first place.

The main example I can think of is EAT in pure HW (e.g., a TPM-like chip that 
outputs EAT). Outputting fixed length integers will make that HW simpler.

EAT goes one step further than COSE and CWT by pointing out that different 
serializations can cause interoperability issues and advises that a profile 
that specifies the serialization used be created for each use case. (Note that 
serialization variation is minor compared to algorithm selection and key 
identification and distribution)

It seems true to me that there are CBOR serialization variants that would not 
interoperate. Sounds a little bad and messy...

In reality, I don’t think it very bad because is very easy to support preferred 
serialization and because it is possible to create a decoder that supports all 
the serializations. Supporting these serializations doesn’t increase RAM and 
CPU usage much. We don’t hear any complaining from the real world about this 
and CBOR is getting close to ten years old.

LL


> On Feb 22, 2022, at 6:50 AM, Carsten Bormann  wrote:
> 
> Hi Anders,
> 
>> The WebAuthn/FIDO specification details CBOR serialization requirements
> 
> (As does COSE *for its internally constructed signing inputs*, not for what 
> goes over the wire.)
> 
>> while the EAT draft specifies multiple alternatives.  
> 
> Maybe we need to fix that then.
> 
>> There must be a reason for that.  
> 
> The spirit is willing, but the flesh is weak.
> Well, actually, the spirit is the problem.
> We need to get better in the willpower to nail down unneeded choices.
> (Of which JSON vs. CBOR is one.)
> 
>> To cope with (and potentially enforce/verify), different CBOR serialization 
>> variants, CBOR tools typically provide options: 
>> https://github.com/peteroupc/CBOR-Java/blob/master/api/com.upokecenter.cbor.CBOREncodeOptions.md
> 
> This is a bit of a Cadillac implementation with lots of options, many of 
> which have to do with API variants as opposed to encoding options.
> None of the latter ones will get in the way of EAT interoperability.
> 
>> The proposal is simply defining something like an "I-CBOR" that could serve 
>> as the foundation for future standards like EAT.
> 
> I-JSON was necessary because JSON implementations claim to have ingested 
> something and then give you something else, unless you stay in the fold of 
> I-JSON.
> I’m not aware of a similar problem for CBOR, so I don’t know why we’d need 
> I-CBOR.
> 
> Yes, because of historical artifacts we have different 
> deterministic/“canonical” encoding rules — but that is of interest only where 
> you *need* deterministic encoding.  COSE did the right thing and minimized 
> that surface so it actually doesn’t matter which ones you are using.  (CTAP2 
> actually did that too, IIRC, they just wrote down some additional rules that 
> they don’t actually need.  But I didn’t look at this for a while.)
> 
> If you really do need deterministic encoding, it’s right there in STD94 
> (RFC8949).  You need to remember that deterministic encoding spans all the 
> way to the application, so slapping an I-something label on the encoder is 
> not going to give you actual interoperability if you really do need 
> deterministic encoding.
> 
> Do we?
> 
> Grüße, Carsten
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade]

I’ve put the text that EAT has profiles CBOR encoding in below.

> On Feb 22, 2022, at 11:09 AM, Carsten Bormann  wrote:
> 
> On 2022-02-22, at 18:08, Laurence Lundblade  wrote:
>> 
>> EAT allows for use of the different CBOR serializations just like COSE and 
>> CWT so particular deployments can choose what is best for them. It is 
>> important to continue to allow all serializations in EAT for the reasons 
>> that they exist in the first place.
> 
> This is confusing terminology.
> You wouldn’t call putting space after a comma in JSON “different 
> serializations”.
> That is just the lenience that the format provides.
> The fixed length argument example you give is one of the reasons we put in 
> that lenience in the first place:
> 
>> The main example I can think of is EAT in pure HW (e.g., a TPM-like chip 
>> that outputs EAT). Outputting fixed length integers will make that HW 
>> simpler.
> 
> Any CBOR decoder will be happy with decoding this.

True, but decoders aren’t actually required to so by RFC 8949, right? Second 
paragraph here 
<https://www.rfc-editor.org/rfc/rfc8949.html#name-preferred-serialization>.


> 
>> EAT goes one step further than COSE and CWT by pointing out that different 
>> serializations can cause interoperability issues
> 
> There is only one place I have found so far where EAT actively causes an 
> interoperability issue:  By ruling out preferred serialization for floating 
> point values.  Creating a separate CBOR dialect by ruling out half-precision 
> encoding might save 8 lines of C code in a decoder (which you can simply copy 
> from https://www.rfc-editor.org/rfc/rfc8949.html#name-half-precision),

It’s not just 8 line of code because it requires a floating library and/or 
floating-point hardware.  That isn’t available in some places. For example some 
implementations of Arm TrustZone don’t support it.

> but ensures that a standard CBOR encoder cannot be used without supplying 
> encoding options.  Not a smart move.

Seems like it would be dumb for a CBOR encoder to use floating point for the 
cti claim. Would some really do that?


> 
>> and advises that a profile that specifies the serialization used be created 
>> for each use case. (Note that serialization variation is minor compared to 
>> algorithm selection and key identification and distribution)
> 
> That is highly misleading.
> 
>> It seems true to me that there are CBOR serialization variants that would 
>> not interoperate. Sounds a little bad and messy...
> 
> If you create multiple incompatible variants by restricting the format, you 
> can create non-interoperating dialects.  Don’t do that then.

The serialization that is of the most concern is indefinite lengths for strings 
and maps. CBOR, COSE and CWT all allow them and there is advantage to use them 
on the encoding side so they shouldn’t be ruled out.

The decode for them is definitely more work and makes the decoder larger.  For 
example, indefinite length strings need to be coalesced in to one and that 
requires a memory allocator or at least more memory management and copying than 
definite length strings. 

QCBOR’s decode API is the same for indefinite length maps and arrays as it for 
definite length maps and arrays, but that wasn’t easy to implement. I think 
some decoders require the protocol implementor to be conscious of the 
distinction.

I think the indefinite length interoperability problem is not large, because 
indefinite lengths are rarely used, but it is still something.

I’m open to suggestions on how to better handle this in EAT.

LL




Text from EAT’s profile discussion

7.2.2.  
CBOR
 Map and Array Encoding 

The profile should indicate whether definite-length arrays/maps, 
indefinite-length arrays/maps or both are allowed. A good default is to allow 
only definite-length arrays/maps. 

An alternate is to allow both definite and indefinite-length arrays/maps. The 
decoder should accept either. Encoders that need to fit on very small hardware 
or be actually implement in hardware can use indefinite-length encoding. 

This applies to individual EAT claims, CWT and COSE parts of the 
implementation. 

7.2.3.  
CBOR
 String Encoding 

The profile should indicate whether definite-length strings, indefinite-length 
strings or both are allowed. A good default is to allow only definite-length 
strings. As with map and array encoding, allowing indefinite-length strings can 
be beneficial for some smaller implementations. 

7.2.4.  
CBOR
 Preferred Serialization 

The profile should indicate whether encoders must use preferred serialization. 
The profile should indicate whether decoders must accept non-preferred 
serialization.___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

Thinking about Mike’s comment today in COSE/Vienna about backwards 
compatibility. Looked at my code around this. That definitely seems like an 
issue. 

What about defining “kid2” as just int? “kid” stays as bstr only. Then there’s 
no backwards compatibility break. Adding support for another integer parameter 
isn’t difficult. The downside is a little extra code to look at two different 
parameters.

You’d probably want to say that only one of the two kids MUST be present.

Another random idea — could you say that it is allowed to translate an integer 
kid to a bstr kid by assuming network byte order and stripping leading zeros? 

LL




> On Aug 13, 2021, at 3:01 AM, Laurence Lundblade  
> wrote:
> 
> Understood about the use case. Thx for the background.
> 
>> On Aug 10, 2021, at 3:13 AM, Göran Selander 
>> > <mailto:goran.selander=40ericsson@dmarc.ietf.org>> wrote:
>> 
>> Assume that we do want to allow key identifiers to be CBOR ints in certain 
>> settings,  what is the best (least intrusive) way to allow this while still 
>> maintain compatibility with 'kid's supporting the type bstr? Another 
>> alternative to what has been listed below is to define 'kid2' to only be of 
>> type int - is that a better option?
> 
> I didn’t write actual code to check, but they about the same to me.
> 
> ‘kid' as int/bstr seems less confusing to me than ‘kid2’. It tells you it 
> does exactly the same thing whether it is an int or a bstr.
> 
> So my pick is ‘kid’, but ‘kid2’ is OK too.
> 
> LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

I’m fine with A, but I’d like this to be the definition of it:

When a kid is an integer it is not a separate kid space, but rather a compact 
alternate encoding of some one-byte kid values. The one-byte kid values 0x00 
through 0x30 may be encoded either as h’00’ through h’30’ or as the integers 
-24 through 23. That is, a one-byte kid is converted to an integer by 
subtracting 24 from it, putting on the wire as an integer and turned back into 
a byte string kid by adding 24.

Integer encoding is only permitted for single-byte kid’s between 0x00 to 0x30. 
(There is no encoding advantage for other kid values)

The point of the integer kid encoding is to service a particular use case where 
saving one by in the encoded kid is worth while. The integer kids will encode 
in one byte where as the byte strings of length one encode in two bytes.

It is advantageous to the COSE SW stacks, COSE APIs and COSE key databases that 
the integer-encoded kid not be a separate space from the byte-string encoded 
kids. If it is a separate space then the stacks, APIS and databases much carry 
a tag along side with the kid to indicate which kid space it is from.

LL




> On Mar 23, 2022, at 7:00 AM, Carsten Bormann  wrote:
> 
> On 22. Mar 2022, at 09:42, Göran Selander 
>  wrote:
>> 
>>> I’d like to ask those who are proposing kid => int / bytes:  are the two 
>>> kid name spaces disjoint
>> 
>> Yes. An integer kid is considered different from a byte string kid.
> 
> OK. Is this a deliberate decision or did you consider making integers 
> synonyms for certain byte strings?
> 
> (My proposal uses them as synonyms for certain two-byte strings.  This 
> actually increases the surface of short identifiers as much as keeping them 
> separate does.)
> 
> Grüße, Carsten
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

Let me try to be more clear.

The COSE standard now is:

   kid => bstr

If we make this change:

   kid => int / bstr

then we break backwards compatibility for COSE as Mike pointed out today. So we 
need a separate parameter called kid2, ckid, intkid or such. 

To not break backwards compatibility we need:

   intkid = int

or:

   intkid = int / bstr

(I don’t remember why an int kid was needed, but do remember I was convinced 
that it was)

LL


> On Mar 21, 2022, at 6:43 PM, Orie Steele  wrote:
> 
> I think I may have misread your proposal.
> 
> Why do we need `kid2` is this just so that we can have an integer `kid` ?
> 
> Seems not worth it to me, since `kid` is already legal in CBOR, my proposal 
> of `ckid` makes no sense.
> 
> So I am basically just saying I dislike seeing `kid2` and don't understand 
> what its value prop is.
> 
> OS
> 
> 
> 
> 
> 
> On Mon, Mar 21, 2022 at 12:16 PM Göran Selander  <mailto:goran.selan...@ericsson.com>> wrote:
> Hi Orie,
> 
>  
> 
> Thanks for input. I didn't get the proposal though:
> 
>  
> 
> > If we really need an integer version of `kid` I would suggest following the 
> > `jti / cti` convention and calling it `ckid`... keeping it optional (as is 
> > the convention), and ensuring it is not part of thumbprint computations.
> 
>  
> 
> RFC 7517/7519: kid and jti value are case-sensitive strings
> 
>  
> 
> RFC 8152/8392: kid and cti value are CBOR bstr
> 
>  
> 
> Is there any difference between a `ckid` which is CBOR int or a `kid2` which 
> is a CBOR int (besides the name)?
> 
>  
> 
> Thanks
> 
> Göran
> 
>  
> 
>  
> 
> From: Orie Steele 
> Date: Monday, 21 March 2022 at 14:55
> To: Göran Selander  <mailto:goran.selan...@ericsson.com>>
> Cc: Laurence Lundblade  <mailto:l...@island-resort.com>>, cose@ietf.org <mailto:cose@ietf.org> 
> mailto:cose@ietf.org>>
> Subject: Re: [COSE] Key identifier of type bstr / int
> 
> I am a -1 to changing `kid`, it should remain a string, for compatibility 
> with existing key identifier systems.
> 
> Including ones that support 
> https://datatracker.ietf.org/doc/html/rfc7638#section-1 
> <https://datatracker.ietf.org/doc/html/rfc7638#section-1>
> 
> See the original definition: 
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.5 
> <https://datatracker.ietf.org/doc/html/rfc7517#section-4.5>
> 
> > The "kid" value is a case-sensitive string.
> 
> Many implementations have built hard dependencies on RFC7515.
> 
> One of the nicest things about JOSE / COSE is being able to "upgrade" from 
> JOSE to COSE.
> 
> Having a significant difference between `kid` in JOSE and COSE would be 
> harmful.
> 
> If we really need an integer version of `kid` I would suggest following the 
> `jti / cti` convention and calling it `ckid`... keeping it optional (as is 
> the convention), and ensuring it is not part of thumbprint computations.
> 
> Regards,
> 
> OS
> 
> 
> 
>  
> 
> On Mon, Mar 21, 2022 at 8:35 AM Göran Selander 
>  <mailto:40ericsson@dmarc.ietf.org>> wrote:
> 
> Hi Laurence,
> 
>  
> 
> Thanks for copying in the old thread. As noted, you and others preferred 
> `kid` as bstr / int rather than `kid2` as int when we discussed it last time. 
> Would be good to come out with a more solid motivation this time so we can 
> converge on this  :-)
> 
>  
> 
> With `kid2` as int, the fields that uses both bstr and int would be of type  
> `kid` / `kid2` which is fine.
> 
>  
> 
> There is an algorithm for translation from CBOR bstr / int to byte strings on 
> the wire (back and forth) in draft-ietf-core-oscore-edhoc.
> 
>  
> 
> Göran
> 
>  
> 
>  
> 
> From: COSE mailto:cose-boun...@ietf.org>> on behalf 
> of Laurence Lundblade mailto:l...@island-resort.com>>
> Date: Monday, 21 March 2022 at 14:14
> To: Göran Selander  <mailto:40ericsson@dmarc.ietf.org>>
> Cc: cose@ietf.org <mailto:cose@ietf.org>  <mailto:cose@ietf.org>>
> Subject: Re: [COSE] Key identifier of type bstr / int
> 
> Thinking about Mike’s comment today in COSE/Vienna about backwards 
> compatibility. Looked at my code around this. That definitely seems like an 
> issue. 
> 
>  
> 
> What about defining “kid2” as just int? “kid” stays as bstr only. Then 
> there’s no backwards compatibility break. Adding support for another integer 
> parameter isn’t difficult. The downside is a little extra code to look at two 
> different parameters.
> 
>  
> 
> You’d probably want to say that only one of the tw

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

> On Mar 22, 2022, at 12:00 AM, Carsten Bormann  wrote:
> 
> Now, there is also API compatibility — can you upgrade the COSE library 
> without upgrading the using application.
> 
> I’d like to ask those who are proposing kid => int / bytes: are the two kid 
> name spaces disjoint (so you need an API extension, too), or is an integer 
> kid just a way to express the same kid as was already possible to express 
> using a byte string kid.  Another way to say the latter is that all kids are 
> byte strings and the integer representation is just a compressed way to 
> express such a byte string.  Obviously, the latter way to interpret kids is 
> slightly less efficient, because there are now two ways to express certain 
> kids.  But the change is also local, i.e. you can do it in your library 
> without changing anything else.
> 
> If we go for the latter, we will want to make sure that in particular the 
> integers -24..23 map to useful byte strings and v.v.  Note that there is no 
> need to make these byte strings short; e.g., a decimal representation (‘-24’ 
> to ‘-1’ and ‘0' to ’23’ in CBOR DN), or maybe an octal one (’50’ to ’77’ and 
> ’00’ to ’27’) would work well.  We don’t even need to support integers 
> outside -24..23.

From an API and implementation point of view, I like that int key IDs are just 
another way of putting the bytes on the wire.

Seems like we could just say that single byte kid value 0x01 can be encoded as 
bstr h’01’ or as integer 01. Allow this only for single byte kids in a range. 
Implementations error out for integers that can’t map to a single byte kid.

This keeps the COSE API, SW stack above and key databases the same, a byte 
string, no matter what encoding is used to convey.

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

> On Mar 21, 2022, at 11:20 PM, Michael Richardson  
> wrote:
> 
> Laurence Lundblade mailto:l...@island-resort.com>> 
> wrote:
>> Let me try to be more clear.
> 
>> The COSE standard now is:
> 
>>   kid => bstr
> 
>> If we make this change:
> 
>>   kid => int / bstr
> 
>> then we break backwards compatibility for COSE as Mike pointed out
> 
> I don't think that this breaks *compatibility*
> Old signed objects are still valid.

I guess you are right.

If you give 

kid => int

to an existing implementation it will say “kid is in the wrong format”

If you give
   
   Intkid => int

to an existing implémentation it will say “there is no kid”

Can’t see it matters that much which.

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Key identifier of type bstr / int

[Laurence Lundblade]

> On Mar 23, 2022, at 11:24 AM, Ilari Liusvaara  
> wrote:
> 
> On Mon, Mar 21, 2022 at 02:13:50PM +0100, Laurence Lundblade wrote:
>> Thinking about Mike’s comment today in COSE/Vienna about backwards
>> compatibility. Looked at my code around this. That definitely seems
>> like an issue. 
> 
> What does your code do if it encounters a recipient with int kid?
> 
> 1. Treats the entiere message as malformed?
> 2. Ignores the recipient?
> 3. Something else? What?
> 
> 
> And it is the implementations that do 1. (or 3. with some oddball
> semantics) that worry me the most here. Not so much 2., as such
> recipient is probably not correct anyway.

For option A, t_cose would reject the whole message.

For option B or C, t_cose would accept the message unless intkid was marked as 
critical, in which case it would correctly reject the message. There would be 
no way to get the intkid or even know it exists, though a future version of 
t_cose will be more extensible in that regard.

You can classify end-end systems using COSE kid into 3:

1) mandatory — receiving app can’t function without a kid
2) kid not used
   2a) not used and reject the message if it is present
   2b) not used, don’t care if it is present
3) optional, some messages can have a kid and it will be used, but there is 
some means other than a kid parameter for finding the key

Note that this list is about kid, not about integer kid. Mandatory means it 
must have a kid the system can understand.

Assuming t_cose behavior, Option A works fine for systems 1) and 2a), but not 
2b) or 3).

Options B and C work for all system.

Since integer kid is only for a small optimization you might be tempted to use 
the two-byte encoding for compatibility with all COSE libraries if the 
optimization isn’t absolutely critical. In coming vast spread of COSE use 
cases, the integer kid will only be used very rarely, so maybe better not to 
confuse the existing kid parameter.

Now I am leaning towards B or C.

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] COSE X509 x5t hash algorithm identifier

[Laurence Lundblade]

+1

LL

> On Feb 8, 2022, at 7:01 PM, Brian Sipos  wrote:
> 
> All,
> While attempting to use the same kind of hash algorithm agility as the COSE 
> X509 draft "x5t" parameter [1], I ran into a technical issue that I wrote up 
> in a ticket [2]. I realize that I just missed the COSE interim to be able to 
> discuss this, but I think this is a simple issue with (hopefully) a simple 
> valid/invalid disposition. If valid and it would be helpful for me to submit 
> a PR, please let me know.
> Thanks,
> Brian S.
> 
> [1] 
> https://www.ietf.org/archive/id/draft-ietf-cose-x509-08.html#section-2-5.5 
> 
> [2] https://github.com/cose-wg/X509/issues/46 
> 
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Why you shouldn't have your crypto designed by a CEO

[Laurence Lundblade]

Given the vast hype and dollars around “crypto” these days it’s no surprise 
stuff like this is happening.  Was interesting to read.

More and better implementations of COSE would probably make a big difference in 
its deployment. I’m trying with t_cose, but it would be cool if OpenSSL and 
Bouncy Castle supported COSE the way they support CMS. 

It would be helpful if there were some really good apps that helped pull COSE 
through. Some are coming, but it is a bit slow. CMS got a lot of pull through 
from PKCS7 and S/MIME.

LL



> On Jan 7, 2022, at 7:03 AM, Carsten Bormann  wrote:
> 
> In the IETF we focus on making building blocks, which are then used to create 
> products and deployments.
> 
> Personally, I generally focus on creating quality building blocks and try to 
> ignore whether those ultimately lead to design wins or not.
> 
> But I can’t help seeing a whole little industry creep up that is interested 
> in creating alternative building blocks that appear to be of interest to the 
> creators so they can attain control over them and perform rent seeking from 
> that control.
> 
> This is, of course, an old game in standardization, but it is reaching new 
> heights in the area of standards for signing things.
> 
> Under the guise of writing tutorials about this subject field, IETF building 
> blocks are disparaged and the “new” wares are peddled instead.  Within the 
> bubbles created by this, it may seem the IETF standards are done with and the 
> “alternatives” can be presented as the way to go.
> 
> Marketing is a necessary component of technology development, but it should 
> not be built out of hatchet jobs and, er, alternative facts.
> 
> For those looking for an example, try exhibit [1].  After a brief tutorial 
> (which is always welcome), various approaches are discussed.  JOSE (with JWS 
> and JWT) is correctly presented as the “elephant in the room”, but then 
> immediately disqualified because of the single misfeature that JOSE stores 
> the algorithm identifier with the signature.  The author mentions RFC 8725, 
> but either hasn’t read it or doesn’t want to mention that this immediately 
> deflates his only(!) argument against JOSE.
> 
> Note that exhibit [1] is from August 2021, but doesn’t even mention COSE.  
> Probably because COSE is a convincing successor to JOSE in the space he is 
> targeting, with implementations out there that have taken lessons from early 
> JOSE implementations.
> Instead, the piece presents [2] as evidence that “PASETO is progressing 
> toward an IETF standard”, but then quickly deflects any potential response 
> that it isn’t, by saying "it is important to note that [IETF] acceptance does 
> not really matter from a security perspective" ([2] itself says the same 
> thing in other words as well).  Of course, he later argues against crypto 
> agility, “any of the SHA-2 functions are fine. Pick one and use it 
> everywhere, don’t try to design in agility at the protocol level”.
> 
> I’m going to spare you from further analysis of this pamphlet and will only 
> add [3] as a link offering a probably explanation why this piece was written.
> 
> I’m wondering whether we (the set of individuals interested in this, 
> certainly not the WG as an IETF construct) need do to more in offering 
> factual material to the channels that are being used for this “marketing”.
> 
> Grüße, Carsten
> 
> [1]: https://dlorenc.medium.com/signature-formats-9b7b2a127473
> [2]: https://github.com/paseto-standard/paseto-rfc
> [3]: https://chainguard.dev/posts/2021-10-07-introducing-chainguard
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Using SSH keys for COSE signatures

[Laurence Lundblade]

Hi Maik,

I don’t know much about ssh, but I read the blog post by Andrew Ayer that you 
included.

Are you after something that does what the following line does, but outputs 
COSE format?

ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n file file_to_sign

Maybe make modifications to ssh so it can work with the COSE format and still 
use the ssh key files? 

Nothing wrong with that IMO. It might be useful in some cases to have a command 
line that can sign and verify (and encrypt and decrypt) COSE in files. OpenSSL 
can do this for the CMS format. I’ve thought about adding this to xclaim.

LL


> On May 20, 2022, at 8:43 AM, Maik Riechert 
>  wrote:
> 
> Hi all,
>  
> A few weeks ago I’ve done some experiments on using SSH keys to sign claims 
> using COSE. This was in the context of SCITT which meant that the 
> corresponding public key would also have to be published through a DID, and 
> that worked fine by converting it to JWK. 
>  
> I’d like to confirm whether using SSH keys in this context is a sensible 
> thing to do, given that SSH keys are also used for user and host 
> authentication within the SSH protocol.
>  
> OpenSSH added support for “SSH signatures” for arbitrary content in 2019:
> https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig 
> 
>  
> SSH signatures are defined in terms of a custom envelope (see 1. and 2.) and 
> sig structure (see 3.), which are different from what’s used in the SSH 
> protocol.
>  
> It says for the signature input:
> “The preamble is the six-byte sequence "SSHSIG". It is included to ensure 
> that manual signatures can never be confused with any message signed during 
> SSH user or host authentication.”
>  
> There is a more detailed analysis of why this preamble is sufficient at:
> https://www.agwa.name/blog/post/ssh_signatures 
> 
>  
> The main insight of that post is that the first three bytes of SSH protocol 
> signature input are always zero, and since the first three bytes of SSH 
> signatures are always “SSH” it all works out.
>  
> The same argument can be made for COSE, here for COSE_Sign1:
>  
> The signature input is the CBOR serialization of the Sig_structure array:
> [“Signature1”, body_protected, sign_protected, aad, payload, [signature]]
>  
> In hex, the array length is 86, the context string length is 6A, and the 
> context string is 5369676E617475726531. This means the first three bytes are 
> always 86 6A 53, which is different than zero bytes and also different from 
> the SSH signature preamble (“SSH” which is 53 53 34).
>  
> Is this a sensible analysis? Anything else to watch out for?
>  
> Maik
> ___
> COSE mailing list
> COSE@ietf.org 
> https://www.ietf.org/mailman/listinfo/cose 
> 
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Using SSH keys for COSE signatures

[Laurence Lundblade]

On May 21, 2022, at 8:26 AM, Ilari Liusvaara  wrote:
> 
>> 
>> The same argument can be made for COSE, here for COSE_Sign1:
>> 
>> The signature input is the CBOR serialization of the Sig_structure
>> array:
>> ["Signature1", body_protected, sign_protected, aad, payload, [signature]]
>> 
>> In hex, the array length is 86, the context string length is 6A, and
>> the context string is 5369676E617475726531. This means the first three
>> bytes are always 86 6A 53, which is different than zero bytes and also
>> different from the SSH signature preamble ("SSH" which is 53 53 34).
>> 
>> Is this a sensible analysis? Anything else to watch out for?
> 
> That Sig_structure does not match my reading of RFC 8152. The RFC seems
> to have Sig_structure to have either 4 or 5 elements, not 6. And there
> are context strings other than just "Signature1". The new counter-
> signatures draft adds possibility to have 6 element sig_structure.

Sig_structure is internal to COSE. It never appears on the wire. It is 
constructed and hashed independently by both the sender and the receiver.

If you’re putting COSE in a file, it would probably be good to always use a 
COSE tag so you know if it signed, encrypted or what. Then the first bytes will 
be 0xD2, 0x84, or 0xd8 0x62, 0x84, or  0xd8 0x60, 0x84 or a few others. Seems 
like it would still never be “SSH”.

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] empty KID values

[Laurence Lundblade]

By RFC 9052:
? 4 => bstr,; key identifier

which says kid is either entirely absent from the header parameters or  h’’ or 
some byte string value . Don’t think it can be NULL or “”.  I didn’t allow 
those in my implementation.

Maybe this is different in YANG, but pretty sure this is the requirement in 
CBOR.

LL

> On Jul 5, 2022, at 9:29 AM, Orie Steele  wrote:
> 
> > Should I treat a null/empty kid as if there were no kid field at all, 
> 
> IMO Yes.
> 
> > and then use some other heuristic to find the right verification key
> 
> Or just throw an error, if your use case requires `kid`... or would benefit 
> from requiring it.
> 
> I'd avoid offering to do work to process data where the issuer didn't bother 
> doing their job (which is to make your job easier).
> 
> Regards,
> 
> OS
> 
> 
> On Mon, Jul 4, 2022 at 12:29 PM Michael Richardson  > wrote:
> 
> RFC9254-to-be/yang-cbor says:
>Data nodes implemented using a CBOR array, map, byte string, or text
>string can be instantiated but empty. In this case, they are encoded with
>a length of zero.
> 
> When encoding/dealing with the COSE Sign0 in
> draft-ietf-anima-constrained-voucher, we have some puzzling about what to do
> with:
> 
> kid: null
> or: kid: ""
> or: kid: h''
> 
> so, two remarks.  First, the kid: field is in the Sign0 structure, not
> actually in the YANG-CBOR, so arguably the above comment does *NOT* apply!
> 
> My puzzling is about kid.  Should I treat a null/empty kid as if there were
> no kid field at all, and then use some other heuristic to find the right
> verification key, or should I treat it as a entry null, which must match
> a null/""/h'' entry in a database for the key.
> Normally, it might be a hash of a public key, so seeing h'xx..xx' would be
> reasonable.
> 
> I'm curious what COSE people say.
> KID is annoyingly use case specific :-(
> 
> --
> Michael Richardson mailto:mcr%2bi...@sandelman.ca>>   
> . o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> ___
> COSE mailing list
> COSE@ietf.org 
> https://www.ietf.org/mailman/listinfo/cose 
> 
> 
> 
> -- 
> ORIE STEELE
> Chief Technical Officer
> www.transmute.industries
> 
>  
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] Sign twice but hash only once?

[Laurence Lundblade]

Hello,

There may be no good answer to this, but I wanted to check.

- The payload is large, say a big chunk of SW, maybe a SW update.
- The HW hash engine is costly to spin up
- Signing twice, once with ECDSA once with LMS for PQ is required

Because of the way COS_Signatures and the Sig_structure works the hashes signed 
by ECDSA and LMS are not the same. One of the reasons they’re not the same is 
that the hash covers the algorithm ID. You have to hash all the bytes in the 
payload twice.


Here’s Sig_structure today:

Sig_structure = [
context : "Signature" / "Signature1",
body_protected : empty_or_serialized_map,
? sign_protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr
]

If the COSE design was different with Sig_structure ordered like this:
Sig_structure = [
context : "Signature" / "Signature1",
external_aad : bstr,
payload : bstr,
body_protected : empty_or_serialized_map,
? sign_protected : empty_or_serialized_map
]
it would have been possible to hash up through the payload and clone the hash 
context. But, that is not the case and we’re not going to change this part of 
COSE now.


It seems like the thing to do here is add a level of hashing indirection — hash 
the actual payload bytes, then that hash becomes the COSE payload. Probably the 
right way to do this to define this:

Hash_structure = [
context : "Hash",
body_protected : empty_or_serialized_map,
payload : bstr,
]

as the bytes to hash. That way the algorithm identifier and other body 
protected headers are covered. 

This could be the basis of another signature format for COSE. Call it 
COSE_SignIndirect. The body algorithm ID header parameter is the hash over the 
Hash_structure. Then:

Indirect_Sig_structure = [
context : “IndirectSignature",
sign_protected : empty_or_serialized_map,
external_aad : bstr,
Hash_structure_hash : bstr
]

This would be roughly equivalent to what is done for the encryption formats 
with the symmetric encryption algorithm.

But given we’re probably not going to create COSE_SignIndirect, I can still get 
most of what I need by creating a new header parameter called body_hash_alg, 
and by making the above Hash_structure the body for a COSE_Sign. The actual 
payload bytes would be transmitted separately outside of COSE.

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Call for adoption of draft-looker-cose-cwt-claims-in-headers-00

[Laurence Lundblade]

I support this.

LL


> On Jun 14, 2022, at 10:24 AM, Ivaylo Petrov  wrote:
> 
> Dear all,
> 
> This message starts the call for adoption of the following draft as working 
> group item:
> 
> * draft-looker-cose-cwt-claims-in-headers-00
>   - https://datatracker.ietf.org/doc/draft-looker-cose-cwt-claims-in-headers/ 
> 
> 
>  
> In
>  light of the discussion during the last IETF and the request by my co-chair, 
> there seems to be some interest in the working group to work on that 
> document. If you have read the draft, please indicate whether you support its 
> adoption as a working group item or not. 
> 
> We would also like to remind you that adoption does not mean a document is 
> finished, only that it is an acceptable starting point.
> 
> This call will run for two weeks, ending on June 28. Please try to respond 
> before that date.
> 
> Best regards,
> 
> - Ivaylo on behalf of the COSE Working Group Chairs
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Sign twice but hash only once?

[Laurence Lundblade]

To get more sharp on what an addition to standard COSE would look like:

A new signature type, COSE_SignIndirect is defined. It looks the same as 
COSE_Sign. A new CBOR tag is created for it and all.

COSE_SignIndirect = [
Headers,
payload : bstr / nil,
signatures : [+ COSE_Signature]
]

Hash_Structure is defined:

Hash_Structure = [
context: “Hash”,
body_protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr
]

SigIndirect_structure is defined as an alternative to Sig_structure. They are 
different enough that I don’t think it is worth tweaking Sig_structure.

Sig_structure = [
context : “SignatureIndirect",
sign_protected : empty_or_serialized_map,
body_hash: bstr
]

When signing:
- Select the hash function you are going to use and put its ID in a body 
protected header (hash function is always required, so no need to mark critical)
- Create any other body protected headers of interest, perhaps a salt (mark 
them critical if they are)
- Create the Hash_Structure (use deterministic encoding)
- Run Hash_Structure through the selected hash function
- For each signature
  - Select the signing algorithm and put it in a signer protected header
  - Create any other signer protected headers of interest
  - Create the SigIndirect_structure (use deterministic encoding)
  - Sign it using the selected signing algorithm

This seems the cleanest and most in line with the rest of COSE. It allows for 
all the protected and unprotected headers one could want. It allows for AAD 
and/or payload.

Does this seem right for a standard proposal?



What it doesn’t do is allow an implementor of this to use an off-the-shelf COSE 
implementation. The implementation would have to be modified quite a bit to 
support this.

LL
 

> On Jun 18, 2022, at 6:19 AM, Ilari Liusvaara  wrote:
> 
> On Fri, Jun 17, 2022 at 10:03:54AM -0700, Laurence Lundblade wrote:
>> Hello,
>> 
>> There may be no good answer to this, but I wanted to check.
>> 
>> - The payload is large, say a big chunk of SW, maybe a SW update.
>> - The HW hash engine is costly to spin up
>> - Signing twice, once with ECDSA once with LMS for PQ is required
>> 
>> Because of the way COS_Signatures and the Sig_structure works the
>> hashes signed by ECDSA and LMS are not the same. One of the reasons
>> they’re not the same is that the hash covers the algorithm ID. You
>> have to hash all the bytes in the payload twice.
>> 
>> 
>> It seems like the thing to do here is add a level of hashing
>> indirection — hash the actual payload bytes, then that hash becomes
>> the COSE payload. Probably the right way to do this to define this:
>> 
>> Hash_structure = [
>>context : "Hash",
>>body_protected : empty_or_serialized_map,
>>payload : bstr,
>> ]
>> 
>> as the bytes to hash. That way the algorithm identifier and other body
>> protected headers are covered. 
>> 
>> But given we’re probably not going to create COSE_SignIndirect, I can
>> still get most of what I need by creating a new header parameter
>> called body_hash_alg, and by making the above Hash_structure the body
>> for a COSE_Sign. The actual payload bytes would be transmitted
>> separately outside of COSE.
> 
> There is something a bit similar in JOSE: The unencoded singature
> option. That thing is a bit messy, but looks to be workable (I have
> actually implemented it). And looking at COSE signature format, the
> body_hash_alg does not look to be much worse.
> 
> The way it is done looks to be relevant:
> 
> - MUST be in protected bucket.
> - MUST be marked critical.
> 
> There are some differences tho: This parameter would be int/bstr, not
> false (the JOSE parameter has weird polarity: false means unencoded).
> 
> And Hash_structure needs to specify canonical encoding. Which in this
> case means using 0x83 for the array, and single fragments with minimal
> lengths for the bstr's.
> 
> And might be a good idea to require at least 256 bit hash output length,
> in order to cut out crap like SHA-1 (-14) and overtruncated SHA-2 (-15).
> 
> 
> Then folks might want to use salted hashes in order to prevent some
> attacks. Fortunately seems like COSE registries already have salt
> parameter (-20). With hash_structure as given above, sticking that into
> body_protected does the trick.
> 
> 
> 
> -Ilari
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Sign twice but hash only once?

[Laurence Lundblade]

> On Jun 20, 2022, at 4:18 AM, Ilari Liusvaara  wrote:
> 
> On Sun, Jun 19, 2022 at 12:46:28PM -0700, Laurence Lundblade wrote:
>> To get more sharp on what an addition to standard COSE would look like:
>> 
>> A new signature type, COSE_SignIndirect is defined. It looks the same as
>> COSE_Sign. A new CBOR tag is created for it and all.
>> 
>> COSE_SignIndirect = [
>>Headers,
>>payload : bstr / nil,
>>signatures : [+ COSE_Signature]
>> ]
> 
> If it is the same as COSE_Sign, is it needed as separate type?
> 
> And I do not think new tag gives reliable separation.

It is an array with the same exact items as COSE_Sign, but the signatures are 
computed quite differently.

I don’t see what we have other than a CBOR tag and/or media types to 
distinguish it from COSE_Sign.

If you mix them up, it certainly will not validate so no security hole.


> ...
>> 
>> Does this seem right for a standard proposal?
> 
> Yes, this seems to be in the right direction.


Thank you kindly for looking this over!

LL

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] ECDH vs HPKE for COSE public key encryption

[Laurence Lundblade]

This is a bit of an implementation question, not so much a standards question, 
so apologies for taking up some bandwidth here up front and feel free to 
ignore. :-)

I’m a bit confused about HPKE vs ECDH for encryption given that ECDH was just 
published yet we seem to be moving on from it to HPKE.


HPKE has momentim
HPKE seems to be where the momentum is so that should be implemented even 
though there will be challenges to arrive quickly at commercial implementation 
because the widely deployed versions of OpenSSL and MbedTLS don’t support it.

Can’t say I’ve seen a good description of why HPKE is better. Would have been 
nice to put such in an appendix in RFC 9810. The main thing I can see is that 
you can do both encryption and authentication at once without the need for two 
layers of COSE. There’s probably some other attacks it mitigates too.  


ECDH is OK, right?
I haven’t seen anyone say there is anything wrong with ECDH encryption in RFC 
9053 (e.g. ECDH-ES + HKDF-256 ID -25.) Seems like it is OK to me. The move to 
HPKE is not because of a problem in ECDH.

Some people might use ECDH instead of HPKE because it is a published standard 
now, better supported in libraries and maybe takes less object code. That is 
OK, right?

It is probably a lower priority than HPKE, but a complete COSE implementation 
should probably support it. Sound right?

It’s kind of a shame that ECDH in the just-published RFC 9053 is kind of 
obsolete already.


Actually implementing HPKE
My understanding is that HPKE is built on top of existing cryptographic 
algorithms and is NOT a new algorithm. It is built on Diffie-Helman and common 
hashes and symmetric ciphers. These make up the KDF, AEAD and such parts used 
by HPKE.

I can see work is underway to add it to MBedTLS and OpenSSL, but it is not 
official supported yet and it will be years before it is in the OpenSSL and 
MbedTLS libraries bundled with OS’s, Linux distros that people use day-day.  I 
want t_cose to work out of the box in those places.

Probably what is best is for t_cose to support HPKE, but have it off by default 
so users get a good out-of-box experience. Then if they want HPKE they go get a 
more recent version of OpenSSL or MbedTLS and turn it on.

Another option is to put HPKE right into t_cose and rely on the crypto 
libraries only for what they are known to broadly support. This is possible 
because no new crypto algs are required for HPKE. The good thing about this is 
that it can be enabled by default in t_cose. This is of course a lot more work. 
There are several downsides to this. When HPKE is in a shared OpenSSL or 
MBedTLS library, t_cose won’t take advantage of it, an issue on small devices. 
Another is that eventually this code will probably be thrown out in favor of 
what is in the popular crypto libraries.

Another choice here is about curves and key formats. Flexibility would of 
course be nice, but that is work (particularly for a quality commercial library 
rather than a prototype for demonstration).


Thanks for any feedback! Send it to me privately if you want to keep list 
traffic down.

LL






___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

[COSE] Format of pkE/enc in HPKE

[Laurence Lundblade]

Jumping into this… hopefully I’m up to speed enough to not say something dumb….

The pkE starts out on the sender side represented in the internal data 
structure that the crypto library likes. It has to be because it is input the 
the DH function. This is neither a COSE_Key nor the byte string serialized 
format that is the output of SerializePublicKey(). It might be an MbedTLS key 
handle or whatever OpenSSL uses.

The library-format key has to be converted to the byte string serialized format 
for SerializePublicKey() by the sender as that is needed as input to make the 
kem_context as part of implementing Encap().

It then has to be put on the wire to be sent and there are two choices:

1) COSE_Key — This requires some code to take the pkE in library format and 
output it COSE_Key format. This is work, but not that much because that 
function probably already exists in a COSE library.
2) Serialized byte string — No work here. Just output the same thing you fed 
into making the kem_context.

So serialized byte string wins on the sending side. What about the receiving 
side?

1) COSE_Key — You have to decode the COSE_Key format and turn it into the 
structure the crypto library uses. Probably you have a function to do it so not 
too much work, but it is something.
2) Serialized byte string — This needs a deserialize function to take the bytes 
off the wire and turn it into the structure for the crypto library. Looks like 
it is needed nowhere else in RFC 9180, but you probably still have it around 
because it is not uncommon to do this and the format is standard for a key type.

Looks like a draw on the receiving side.

That kind of means serialized byte string wins overall from this particular 
line of thinking, but I don’t think it’s a large victory.

LL





___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Format of pkE/enc in HPKE

[Laurence Lundblade]

Below...

> On Nov 1, 2022, at 2:21 AM, Ilari Liusvaara  wrote:
> 
> On Mon, Oct 31, 2022 at 11:45:51AM -0700, Laurence Lundblade wrote:
>>> On Oct 31, 2022, at 2:50 AM, Ilari Liusvaara  
>>> wrote:
>>> 
>>> On Sun, Oct 30, 2022 at 11:29:46PM -0700, Laurence Lundblade wrote:
>>>> Jumping into this… hopefully I’m up to speed enough to not say
>>>> something dumb….
>>>> 
>>>> The pkE starts out on the sender side represented in the internal
>>>> data structure that the crypto library likes. It has to be because
>>>> it is input the the DH function. This is neither a COSE_Key nor the
>>>> byte string serialized format that is the output of SerializePublicKey().
>>>> It might be an MbedTLS key handle or whatever OpenSSL uses.
>>> 
>>> HPKE does _not_ guarantee that pkE even exists. Note that it is defined
>>> in section 4.1, which concerns how to turn Diffie-Hellman function into
>>> a KEM.
>> 
>> The only KEM defined in 9180 is DHKEM. For an RFC 9180 implementation
>> you do have to have a pkE in some form, right? 
>> 
>> I could see how a KEM defined outside of 9180 might have something
>> else instead of a pkE (note that 9180 is my main source of info about
>> HPKE so far).
> 
> It seems to me that:
> 
> - RFC 9180 was designed to use generic KEM with unified API.
> - DHKEM was defined in order to construct KEM from ECDH.
> - There are no ready-to-use dedicated KEMs with benefits over using
>  ECDH as KEM, so RFC 9180 did not define any.
> - However, in the future there are expected to be KEMs not based on
>  DHKEM.
>  - Those are to be usable without any API changes.
>  - E.g., Kyber1024 or Kyber/ECDH hybrids.

Makes sense.

Agree that we want to think about this in the encoding of enc/COSE_HPKE_Sender,


>>> When pkE exists, it starts as public Diffie-Hellman key, generated for
>>> each encapsulation. It SHOULD be generated using the method described
>>> in HPKE specification, but using any non-broken keygen works (other
>>> than some test vectors).
>>> 
>>> In my HPKE implementation, for NIST curves, pkE is actually byte string
>>> in output format, and SerializePublicKey() is identity.
>> 
>> That’s because the input to your DH algorithm API/library can work on a
>> serialized pkE, right?
> 
> Actually, it is because DHKEM does not do anything with pkE except to
> serialize it. It is the private part that is used in DH operation.

Right. On the sending side, pkE is only serialized put in the kem_context plus 
it is sent in the COSE message. On the receiver side it is put in the 
kem_context and is input to DH().

I’m pretty convinced that COSE_Key is not the right thing for the encoding of 
enc/COSE_HPKE_Sender.

LL


___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] Format of pkE/enc in HPKE

[Laurence Lundblade]

Hi Ilari,


Below.

> On Oct 31, 2022, at 2:50 AM, Ilari Liusvaara  wrote:
> 
> On Sun, Oct 30, 2022 at 11:29:46PM -0700, Laurence Lundblade wrote:
>> Jumping into this… hopefully I’m up to speed enough to not say
>> something dumb….
>> 
>> The pkE starts out on the sender side represented in the internal
>> data structure that the crypto library likes. It has to be because
>> it is input the the DH function. This is neither a COSE_Key nor the
>> byte string serialized format that is the output of SerializePublicKey().
>> It might be an MbedTLS key handle or whatever OpenSSL uses.
> 
> HPKE does _not_ guarantee that pkE even exists. Note that it is defined
> in section 4.1, which concerns how to turn Diffie-Hellman function into
> a KEM.

The only KEM defined in 9180 is DHKEM. For an RFC 9180 implementation you do 
have to have a pkE in some form, right? 

I could see how a KEM defined outside of 9180 might have something else instead 
of a pkE (note that 9180 is my main source of info about HPKE so far).


> 
> When pkE exists, it starts as public Diffie-Hellman key, generated for
> each encapsulation. It SHOULD be generated using the method described
> in HPKE specification, but using any non-broken keygen works (other
> than some test vectors).
> 
> In my HPKE implementation, for NIST curves, pkE is actually byte string
> in output format, and SerializePublicKey() is identity.

That’s because the input to your DH algorithm API/library can work on a 
serialized pkE, right?


> For X* stuff,
> pkE is byte array, and SerializePublicKey() is trivial byte string
> conversion. If I were to add compact NIST curves, SerializePublicKey()
> would be nontrivial (substring extraction).
> 
> 
>> The library-format key has to be converted to the byte string
>> serialized format for SerializePublicKey() by the sender as that is
>> needed as input to make the kem_context as part of implementing
>> Encap().
> 
> Assuming pkE exists.
> 
> 
>> It then has to be put on the wire to be sent and there are two choices:
>> 
>> 1) COSE_Key — This requires some code to take the pkE in library
>> format and output it COSE_Key format. This is work, but not that much
>> because that function probably already exists in a COSE library.
> 
> This breaks down when pkE does not exist. 
> 
> And even when pkE exists, uncompressed NIST curves are probably the
> only ones where such conversion could be in any way useful.
> 
> 
>> 2) Serialized byte string — No work here. Just output the same thing
>> you fed into making the kem_context.
> 
> And this byte string is actually guaranteed to exist.
> 
> 
>> So serialized byte string wins on the sending side. What about the
>> receiving side?
>> 
>> 1) COSE_Key — You have to decode the COSE_Key format and turn it
>> into the structure the crypto library uses. Probably you have a
>> function to do it so not too much work, but it is something.
> 
> In my COSE-HPKE implementation, this is actually substantial amount
> of code (many hundreds of lines, but I could reuse code I had earlier
> written for a different purpose).
> 
> 
>> 2) Serialized byte string — This needs a deserialize function to
>> take the bytes off the wire and turn it into the structure for the
>> crypto library. Looks like it is needed nowhere else in RFC 9180,
>> but you probably still have it around because it is not uncommon
>> to do this and the format is standard for a key type.
> 
> The kem_context is also present on decapsulation side, so one needs
> the serialized byte string anyway (and in cases where pkE does not
> exist, the KEM consumes the serialized byte string directly).

Yes. I missed that. That leans the the receiving side to byte string too.


> 
>> Looks like a draw on the receiving side.
>> 
>> That kind of means serialized byte string wins overall from this
>> particular line of thinking, but I don’t think it’s a large victory.
> 
> Serialized byte string is also more forward compatible, because there
> will be KEMs (Kyber, anyone?) that only have serialized byte string
> form and no pkE at all.

Thanks for your comments.

LL


> 
> 
> 
> -Ilari
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] ECDH vs HPKE for COSE public key encryption

[Laurence Lundblade]

> On Oct 31, 2022, at 1:51 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Laurence, 
>  
> It is true that HPKE has been selected in favor over Ephemeral-Static (ES) DH 
> already defined in COSE. The claimed benefits of using HPKE are described in 
> Section 1 of RFC 9180:
>  
> Here is a copy:
> “
>Currently, there are numerous competing and non-interoperable
>standards and variants for hybrid encryption, mostly variants on the
>Elliptic Curve Integrated Encryption Scheme (ECIES), including ANSI
>X9.63 (ECIES) [ANSI 
> <https://datatracker.ietf.org/doc/html/rfc9180#ref-ANSI>], IEEE 1363a 
> [IEEE1363 <https://datatracker.ietf.org/doc/html/rfc9180#ref-IEEE1363>], 
> ISO/IEC 18033-2 [ISO <https://datatracker.ietf.org/doc/html/rfc9180#ref-ISO>],
>and SECG SEC 1 [SECG 
> <https://datatracker.ietf.org/doc/html/rfc9180#ref-SECG>].  See [MAEA10 
> <https://datatracker.ietf.org/doc/html/rfc9180#ref-MAEA10>] for a thorough 
> comparison.  All
>these existing schemes have problems, e.g., because they rely on
>outdated primitives, lack proofs of indistinguishable (adaptive)
>chosen-ciphertext attack (IND-CCA2) security, or fail to provide test
>vectors.
> “

Yeah, I read that like three times. Also this paper by C. Woo 
<https://blog.cloudflare.com/hybrid-public-key-encryption/>d. Didn’t really 
find them particularly informative.
- They don’t mention ECDH defined in RFC 9053
- Lack of test vectors is not a reason to invent new stuff
- They don’t mention the combined encryption and authentication
- Why are the primitives outdated and why does it matter?
- Are the proofs impossible or has no one done them?

I’m not questioning whether HPKE is the way to go or not, just saying that 
coming in fresh to this as I am, these explanations weren’t that compelling and 
there probably could be better ones that would have avoided me writing this 
message.


> We had this discussion in the SUIT group in the early days of adoption the 
> firmware encryption draft. Ephemeral-Static (ES) DH cannot be used out of the 
> boxes – it has to be profiled for a specific use case, which we could have 
> done in SUIT. To my knowledge nobody has implemented this functionality in 
> any COSE library. COSE comes with a lot of different variants and I suspect 
> that no library will implement all of them (or any of them).

So there’s no EC-based implementation-ready interoperable encryption 
specification for COSE today even after year of work and two rounds of 
published RFCs (then why I was beat up for EAT profiles?). 

It is what it is. I’m happy to pitch in and make HPKE work in t_cose. :-)

>  
> Regarding your implementation-specific questions: As you know, my approach 
> was to add HPKE to Mbed TLS anticipating that it will be needed in the future 
> as part of the Encrypted Client Hello draft anyway. The same is true for 
> OpenSSL. Putting the HPKE code tentatively into t_cose is also fine for me. 

Good to understand. Thx.

LL



>  
> Ciao
> Hannes
>  
> From: COSE mailto:cose-boun...@ietf.org>> On Behalf 
> Of Laurence Lundblade
> Sent: Sunday, October 30, 2022 9:57 PM
> To: cose mailto:cose@ietf.org>>
> Cc: Richard Barnes mailto:r...@ipv.sx>>; 
> karthikeyan.bharga...@inria.fr <mailto:karthikeyan.bharga...@inria.fr>; 
> i...@benjaminlipp.de <mailto:i...@benjaminlipp.de>; c...@heapingbits.net 
> <mailto:c...@heapingbits.net>
> Subject: [COSE] ECDH vs HPKE for COSE public key encryption
>  
> This is a bit of an implementation question, not so much a standards 
> question, so apologies for taking up some bandwidth here up front and feel 
> free to ignore. :-)
>  
> I’m a bit confused about HPKE vs ECDH for encryption given that ECDH was just 
> published yet we seem to be moving on from it to HPKE.
>  
>  
> HPKE has momentim
> HPKE seems to be where the momentum is so that should be implemented even 
> though there will be challenges to arrive quickly at commercial 
> implementation because the widely deployed versions of OpenSSL and MbedTLS 
> don’t support it.
>  
> Can’t say I’ve seen a good description of why HPKE is better. Would have been 
> nice to put such in an appendix in RFC 9810. The main thing I can see is that 
> you can do both encryption and authentication at once without the need for 
> two layers of COSE. There’s probably some other attacks it mitigates too.  
>  
>  
> ECDH is OK, right?
> I haven’t seen anyone say there is anything wrong with ECDH encryption in RFC 
> 9053 (e.g. ECDH-ES + HKDF-256 ID -25.) Seems like it is OK to me. The move to 
> HPKE is not because of a problem in ECDH.
>  
> Some people might use ECDH instead of HPKE because it is a published standard 
> 

Re: [COSE] COSE-HPKE: Moving Forward

[Laurence Lundblade]

I’m in favor of both of these.

In addition to previous reasons in favor of #2, the use of COSE’s mechanism for 
distinguishing one sort of parameter (parameter labels) seems better than 
making up a new mechanism (polymorphism of a parameter). COSE implementations 
already have to decode header parameter labels and switch on them. Many will 
have code handy for this.

LL


> On Jan 11, 2023, at 4:51 AM, Hannes Tschofenig  
> wrote:
> 
> Hi all,
>  
> To move forward with the COSE-HPKE draft two open issues need to be 
> addressed. I posted a mail in December, see
> https://mailarchive.ietf.org/arch/msg/cose/Cv-UumRRmmXWzrDHAhOAk0iV6fI/ 
> 
>  
> The two open issues (IMHO) are: 
>  
>  
>   1. Should we make the kem_id in the encapsulated_key structure mandatory, 
> as Laurence suggested.
>   2. Should we avoiding the polymorphic approach for the encapsulated_key 
> registration, as Daisuke suggested.
>  
> To make it easier to understand these two issues, let me point you the 
> current version of the PR:
> https://github.com/cose-wg/HPKE/blob/9914fa6f84b28046ee29762551798760dbaa3b7f/draft-ietf-cose-hpke.md
>  
> 
>  
> Regarding issue#1, we are talking about changing the encapsulated_key 
> structure
>  
> from 
>  
>encapsulated_key = [
>kdf_id : uint,   ; kdf id
>aead_id : uint,  ; aead id
>enc : bstr,  ; enc
>? kem_id : uint, ; kem id
>]
>  
> to:
>  
>encapsulated_key = [
>kdf_id : uint,   ; kdf id
>aead_id : uint,  ; aead id
>kem_id : uint,   ; kem id
>enc : bstr,  ; enc
>]
>  
>  
> Regarding issue#2, the change relates to how the encapsulated_key structure 
> is registered in the COSE IANA registry (under COSE header parameters).
>  
> Change from:
> Name: encapsulated_key
> Label: TBD2 (Assumed: -4)
> Value type: bstr / [any] / { any => any }
> Value Registry: N/A
> Description: Encapsulated key for KEM-like algorithms
> To:
> Name: encapsulated_key
> Label: TBD2 (Assumed: -4)
> Value type: Array
> Value Registry: N/A
> Description: Encapsulated key for KEM-like algorithms
>  
> In a future, if the HPKE gets extended to algorithms that are not compatible 
> with the encapsulated_key structure then a new one has to be defined due to 
> the lack of extensibility of the array and its fixed set of fields.
>  
> Your feedback will be valuable and allows me to resubmit a new draft version.
>  
> Ciao
> Hannes
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you. 
> ___
> COSE mailing list
> COSE@ietf.org 
> https://www.ietf.org/mailman/listinfo/cose 
> 
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] HPKE Proposals: Something for the group to decide

[Laurence Lundblade]

> On Nov 30, 2022, at 9:26 AM, Carsten Bormann  wrote:
> 
> On 2022-11-30, at 18:17, Laurence Lundblade  wrote:
>> 
>> the HPKE version
> 
> Where is that concept defined?

Daisuke mentioned it a few messages back. Agree that it is not very well 
defined in 9180.

> 
> RFC 9180 does not discuss versions.
> (It does cargo-cult a “-v1” into some strings.  Duuh.)

Enjoyed the parenthetical. https://en.wikipedia.org/wiki/Cargo_cult

LL
___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] HPKE Proposals: Something for the group to decide

[Laurence Lundblade]

Hello,

> On Nov 30, 2022, at 6:00 AM, AJITOMI Daisuke  wrote:
> 
> I also agree with the idea that HPKE version information can be included in 
> alg whether implicitly ("HPKE-BASE") or explicitly ("HPKEv1-BASE"). In HPKE, 
> an encrypted message does not contain the version information and the 
> recipient needs to know it in advance to decrypt it. However, that doesn't 
> mean we need to include the version information in the COSE message to be 
> sent.


Seems pretty important that the recipient be able to know the HPKE version from 
the message. Seems like our work would be incomplete if that needed to be 
conveyed by the surrounding protocol. Also seems kind of a layering violation 
to have the version number outside the message.

I think we could register HPKE-BASE and say it is v1 in the text of the IANA 
registration. If there is a v2, then when it gets registered it is as 
HPKEv2-BASE. Or we could just register HPKEv1-BASE to start with.

If version numbers are going to change more frequently, then it should go into 
a separate parameter. I don’t have a good sense of how frequent changes will 
be. Hope it’s infrequent!

LL





___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] HPKE versions

[Laurence Lundblade]

> On Dec 10, 2022, at 11:53 AM, Ilari Liusvaara  
> wrote:
> 
> On Sat, Dec 10, 2022 at 09:48:04AM -0700, Laurence Lundblade wrote:
>> +1 for HPKE-v1-BASE
>> 
>> Re title the draft "HPKE Base Mode for COSE” or similar because it’s
>> not a definition of all of HPKE for COSE
>> 
>> Use a fixed array for the sender info that is tied to HPKE-v1-BASE.
>> If there becomes a need to change the array, then we’ll use.an
>> algorithm identifier different from HPKE-v1-BASE. For example, we
>> could have a different array for HPKE-v1-AUTH (if/when someone gets
>> around to it and there is actual need for it to be different).
> 
> However, parameters with short identifers are not cheap. So if both
> are to have short parameter identifier, one needs to be able to reuse
> the same parameter for both.
> 
> (The reason why my proposal was written in a bit odd way is to enable
> that sort of reuse. Yes, I realize this is a bit controversal.)

Hi Ilari,

I assume you mean registered COSE header parameters with ID’s between -24 and 
24 are not cheap. Initially, we’ll only require one. I assume HPKE is important 
enough that we’ll easily get one for the sender info for HPKE-v1-BASE and then 
another later for HPKE-v1-AUTH if needed.

From a first glance, it looks the ID(s) should be from the COSE Header 
Algorithm Parameters 
<https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-parameters> 
range (-1 to -65536). There are 16 free here now (-19 to -4) and HPKE is 
important, so I expect little objection from experts to us using 2 if needed. 

Even if we discover in a few years, we defined sender info wrong for 
HPKE-v1-BASE and need a sender info v2, I think we’ll be OK. I’m also confident 
we can get it right now.

And even if we can’t get the one-byte ID, a two-byte ID is only one more byte. 
There are hundreds of two-byte IDs available. 

Parameter IDs don't seem like a critical resource that constrains what we do 
now. So, I don’t see this as a reason for making the sender info array variable.

LL___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Re: [COSE] HPKE versions

[Laurence Lundblade]

+1 for HPKE-v1-BASE

Re title the draft "HPKE Base Mode for COSE” or similar because it’s not a 
definition of all of HPKE for COSE

Use a fixed array for the sender info that is tied to HPKE-v1-BASE. If there 
becomes a need to change the array, then we’ll use.an algorithm identifier 
different from HPKE-v1-BASE. For example, we could have a different array for 
HPKE-v1-AUTH (if/when someone gets around to it and there is actual need for it 
to be different).

I’m pretty sure HPKE and COSE are well enough understood that we can fix the 
array now. A fixed array is definitely less code than a map or a variable 
array. For example with a map you have to do duplicate detection.

LL


(BTW, I noticed that MLS 
,
 an HPKE-centric message encryption, defines ciphersuites for HPKE. It is near 
publication, so not just some early draft a fair number of people think 
ciphersuites for HPKE are a good idea.. For example it defines 
MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. If you really want to reduce code 
and message size this is the way to go. There’s definitely few bytes on the 
wire and you are only decoding one integer (plus the enc) That saving is 
probably why most of the public key crypto in COSE is ID’d by ciphersuite).



> On Dec 9, 2022, at 6:16 AM, Ilari Liusvaara  wrote:
> 
> On Fri, Dec 09, 2022 at 11:17:32AM +, Hannes Tschofenig wrote:
>> Hi all,
>> 
>> I would like to get some clarity from the version discussion.
>> 
>> At the beginning we discussed the following question: Do we need
>> something other than base mode for HPKE when used with COSE?
> 
> IMO, not currently. However, we should ensure, that such things can be
> added in future without allocating new parameters. Which in turn impiles
> that HSI (HPKE Sender Info) is either dictionary or polymorphic.
> However, since each mode is its own special snowflake, I do not see need
> for IANA registry.
> 
> 
>> Then, the discussions moved into how to encode future versions of HPKE
>> into the algorithm identifier. To me the discussion is a bit abstract
>> since there is (at least to my knowledge) to plan to work on a new
>> version of HPKE (given that the current version is not old).
> 
> Situation with future versions is even worse than with auth-MAC: With
> auth-MAC, one at least knows what information needs to be encoded. But
> with future versions, nobody even knows what is needed.
> 
> So beyond ensuring HSI parameter is extensible, there is nothing that
> can be done.
> 
> 
> 
> So in summary:
> 
> - Do just HPKE-v1 base mode for now.
>  - Possibly other stuff in future.
> - Define HSI so that set of fields can change.
>  - Parametrized by alg.
>  - No need for registry.
> 
> 
> 
> 
> -Ilari
> 
> ___
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

___
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose