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

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

[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. I assume this is because the COSE protocol doesn’t have a need because they are

Re: [COSE] A couple of COSE questions

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

Re: [COSE] ECIES key transport?

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 k

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

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

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

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

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

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

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

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 &

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

gt; > 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&g

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

> On Apr 27, 2020, at 5:00 AM, Göran Selander > wrote: > > [GS] The rationale for native CBOR certificates is to reuse the same encoding > as in the compression scheme defined for RFC 7925, but signing the CBOR > instead of signing the uncompressed data. This provides a roadmap with >

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

> 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? … … > >

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

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 >

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

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

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

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

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

; > > > 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>> &

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

020, 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 >> spe

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

> 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>>

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

> 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

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

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

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

> 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

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

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.

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

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... >> >&

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

> 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

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

> 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 >

[COSE] Gap in registration of application/cwt?

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

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

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

[COSE] GitHub issues and -08 release

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

[COSE] Identifying the end-entity cert

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

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

> 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;

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

> 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

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

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. > >

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

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

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

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

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

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, 20

[COSE] magic number, file format and tags

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

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

> 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.

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

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

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

> 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

Re: [COSE] C509 Certification Request (CSR)

> 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

Re: [COSE] C509 Certification Request (CSR)

> 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

Re: [COSE] C509 Certification Request (CSR)

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

Re: [COSE] C509 Certification Request (CSR)

> 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

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

> 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

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

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 algo

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

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

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

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

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

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

Re: [COSE] "CBOR Certificates"

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) ? > > >

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

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

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

> 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

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

mentations 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 m

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

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

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

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

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

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:

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

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 includ

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

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

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

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.

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

e 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 > Sen

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

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

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

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 >> -

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

(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} &

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

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,

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

py 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...@a

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

> 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

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

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,

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

> 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

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

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

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

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

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

> 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 lengt

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

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

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

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

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

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 sens

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

> 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

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

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

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

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

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

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=40er

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

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

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

; > > > 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 > > > > > > Fr

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

> 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

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

> 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 t

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

> 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 definitel

Re: [COSE] COSE X509 x5t hash algorithm identifier

+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

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

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

Re: [COSE] Using SSH keys for COSE signatures

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

Re: [COSE] Using SSH keys for COSE signatures

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

Re: [COSE] empty KID values

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

[COSE] Sign twice but hash only once?

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

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

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 > -

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

. 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

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

> 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 loo

[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

[COSE] Format of pkE/enc in HPKE

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

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

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

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

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 o

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

y. 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, Octo

Re: [COSE] COSE-HPKE: Moving Forward

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

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

> 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. >

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

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

Re: [COSE] HPKE versions

> 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 o

Re: [COSE] HPKE versions

+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

  1   2   >