Subject: Re: [COSE] New Version Notification for draft-mattsson-cose-cbor-cert-compress-05.txt

From: John Mattsson <[email-masked]>
Date: Wed, 2 Dec 2020 08:49:34 +0000

Thanks again for all the good comment and discussions on the list!

We have submitted -05. Changes are:

- Added reference to IEEE 802.1AR DevID and made optimization for IEEE 802.1AR DevID.
- Rephrased "compress" in the whole document. We will change the file name later.
- Made it more clear that X.509 version in included in the CBOR certificate type.
- Omitted 'signature' instead of 'singatureAlgorithm'. Now the algorithm comes just before the signature value.
- Added support of emailAddress / IA5String in issuer and subject. This was easy.
- changed so utf8Strings have a positive sign.
- Change time to unwrapped CBOR epoch time (~time). This saves 1 byte for time > 2050
- Added that the value "99991231235959Z" (no expiration date) is encoded as CBOR null. This is quite commonly used in IoT certificates. This saves 4 bytes when used.
- Use CDDL for CBOR OID as defined in draft-ietf-cbor-tags-oid
- Added CBOR encoding for uthorityKeyIdentifier and subjectKeyIdentifier which are heavily used by IEEE 802.1AR DevID (at least one of them are mandated depending on type of cert).
- Added optimization for the hardwareModuleName type of otherName, which is mandatory to use in IEEE 802.1AR DevID
- Added CBOR encoding for cRLDistributionPoints and authorityInfoAccess, which are both used in basically all HTTPS certificates on the web.
- Added support for registeredID. This was trivial and registeredID is used e.g. by the GSMA eUICC PKI Certificate Policy (SGP 14).
- Added considerations for expert reviewers.
- Moved SHA-1 signature algorithms to negative 2 byte encodings: -256 and -255
- Added a public private ECDSA key pair turning the example certificates into test vectors. An implementation can now create and verify the example RFC 7925 certificates.

Cheers,
John

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, 2 December 2020 at 08:56
To: Göran Selander <[email-masked]>, Göran Selander <[email-masked]>, Martin Furuhed <[email-masked]>, Shahid Raza <[email-masked]>, John Mattsson <[email-masked]>, Joel Hoglund <[email-masked]>, John Mattsson <[email-masked]>, Joel Höglund <[email-masked]>
Subject: New Version Notification for draft-mattsson-cose-cbor-cert-compress-05.txt

A new version of I-D, draft-mattsson-cose-cbor-cert-compress-05.txt
has been successfully submitted by =?utf-8?q?John_Preu=C3=9F_Mattsson?= and posted to the
IETF repository.

Name:		draft-mattsson-cose-cbor-cert-compress
Revision:	05
Title:		CBOR Encoding of X.509 Certificates (CBOR Certificates)
Document date:	2020-12-01
Group:		Individual Submission
Pages:		29
URL:            https://www.ietf.org/archive/id/draft-mattsson-cose-cbor-cert-compress-05.txt
Status:         https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress
Htmlized:       https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-mattsson-cose-cbor-cert-compress-05

Abstract:
   This document specifies a CBOR encoding of X.509 certificates.  The
   resulting certificates are called CBOR Certificates.  The CBOR
   encoding supports a large subset of RFC 5280, while at the same time
   significantly reduces the size of certificates compatible with RFC
   7925 and IEEE 802.1AR (DevIDs).  When used to re-encode DER encoded
   X.509 certificates, the CBOR encoding can in many cases reduce the
   size of RFC 7925 profiled certificates with over 50%.  The CBOR
   encoding can also be used encode "natively signed" CBOR certificates,
   which does not require re-encoding for the signature to be verified.
   The document also specifies COSE headers as well as a TLS certificate
   type for CBOR certificates.

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.

The IETF Secretariat

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Dec 2020 14:02:00 -0800

I don’t think it works very well at all to directly sign encoded CBOR. It should be wrapped in a byte string.

In particular issuerSignatureValue should probably be the signature over a byte string that contains an encoded TBSCertificate. This is what COSE does.

The main reason for this is to allow implementation with off-the-shelf CBOR encoders and decoders. From some that I’ve looked at and one I’ve written myself, CBOR decoders don’t allow access a sub-part of the encoded CBOR so it can be input into the hash. There would be no way to get just the encoded bytes of the TBSCertificate out of the CBOR decoder unless you went in and hacked its source code in a special way.

Has anyone implemented verification of Natively Signed CBOR Certificates? What CBOR decoder was used? Maybe I’m wrong about this?

I realize byte string wrapping TBSCertificate might cause upheaval in the overall design because cborCertificateType would be inside the byte string wrapping.

Another approach might be to just use COSE for Natively Signed CBOR Certificates. The COSE payload would be a TBSCertificate. COSE would take care of the byte string wrapping issues. This would increase the on-the-wire size of the certificate by about 10 bytes, but might decrease code size of the implementation by re use of a COSE implementation.

LL

> On Dec 2, 2020, at 12:49 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Göran Selander <[email-masked]>
Date: Mon, 14 Dec 2020 13:18:49 +0000

Hi Laurence,

I’m aware of two implementation activities: by John (type 1) and by Stefan (type 0).

Göran

On 2020-12-07, 23:02, "COSE" <[email-masked]> wrote:
I don’t think it works very well at all to directly sign encoded CBOR. It should be wrapped in a byte string.

LL

> On Dec 2, 2020, at 12:49 AM, John Mattsson <john.mattsson=[email-masked]<mailto:john.mattsson=[email-masked]>> wrote:
>
> From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> To: Göran Selander <[email-masked]<mailto:[email-masked]>>, Göran Selander <[email-masked]<mailto:[email-masked]>>, Martin Furuhed <[email-masked]<mailto:[email-masked]>>, Shahid Raza <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>, Joel Hoglund <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>, Joel Höglund <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

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

---

From: "Hristozov, Stefan" <[email-masked]>
Date: Mon, 14 Dec 2020 13:50:48 +0000

Hi Laurence,

I am using the C library tinycbor [1] for my native CBOR certificate decoder.
During parsing the certificate I am calculating also an offset from its beginning after each parsed element. Tinycbor provides a function for getting the length of the byte or text string cbor_value_calculate_string_length [2], which is helpful for that.

Does this answer your question?

Best regards,
Stefan

[1]: https://github.com/intel/tinycbor
[2]: https://intel.github.io/tinycbor/current/a00047.html#gad5b2dd803244946b15603e09ce147044

On Mon, 2020-12-14 at 13:18 +0000, Göran Selander wrote:
Hi Laurence,

Göran

LL

--

Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC
Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. +49 89 32299 86 157
[email-masked]<mailto:[email-masked]>
https://www.aisec.fraunhofer.de/

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 14 Dec 2020 11:09:12 -0800

Hi Stefan,

First on the implementation — my understanding is that you’d have to hash from the byte offset of the first byte of the CBOR encoded head of cborCertificateType to the last byte of the Extensions to correctly implement this. Since the cborCertificateType is the first item in the sequence, its offset is zero, so that’s easy.

I’m not sure how you’d use cbor_value_calculate_string_length since many of the items in the TBSCertificate are not strings. Maybe you calculate the length of the issuerSignatureValue and go back from the end? That wouldn’t account for CBOR encoded head of issuerSignatureValue though.

So, I don’t understand how this works with tinyCBOR or that it is even correct.

It would be good to see an implementation in Python or Go or such to see if it's possible with those type of CBOR decoders.

Second on the design — I still believe this design is counter to conventions used in CBOR for signing/hashing data. I think the folks that designed COSE thought this issue through.

(My first design of of EAT did the hashing the way it is being done here. This was before COSE was publishes as an RFC. The folks using an off-the-shelf Python CBOR decoder had to hack that decoder to get the verification to work. Then EAT switched to COSE and I came to understand the reasons COSE works as it does.)

LL

> On Dec 14, 2020, at 5:50 AM, Hristozov, Stefan <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> [1]: https://github.com/intel/tinycbor <https://github.com/intel/tinycbor>  
> [2]: https://intel.github.io/tinycbor/current/a00047.html#gad5b2dd803244946b15603e09ce147044 <https://intel.github.io/tinycbor/current/a00047.html#gad5b2dd803244946b15603e09ce147044>
> 
>> > On Dec 2, 2020, at 12:49 AM, John Mattsson <john.mattsson=[email-masked] <mailto:john.mattsson=[email-masked]>> wrote:
>> > 
>> > From: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> > To: Göran Selander <[email-masked] <mailto:[email-masked]>>, Göran Selander <[email-masked] <mailto:[email-masked]>>, Martin Furuhed <[email-masked] <mailto:[email-masked]>>, Shahid Raza <[email-masked] <mailto:[email-masked]>>, John Mattsson <[email-masked] <mailto:[email-masked]>>, Joel Hoglund <[email-masked] <mailto:[email-masked]>>, John Mattsson <[email-masked] <mailto:[email-masked]>>, Joel Höglund <[email-masked] <mailto:[email-masked]>>
>> > URL:            https://www.ietf.org/archive/id/draft-mattsson-cose-cbor-cert-compress-05.txt <https://www.ietf.org/archive/id/draft-mattsson-cose-cbor-cert-compress-05.txt>
>> > Status:         https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ <https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/>
>> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress <https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress>
>> > Htmlized:       https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-05 <https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-05>
>> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-mattsson-cose-cbor-cert-compress-05 <https://www.ietf.org/rfcdiff?url2=draft-mattsson-cose-cbor-cert-compress-05>
>> > 
>> > Abstract:
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
>>  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
>>  
>>  
> -- 
> Stefan Hristozov
> [email-masked] <mailto:[email-masked]>
> https://www.aisec.fraunhofer.de/ <https://www.aisec.fraunhofer.de/>_______________________________________________
> COSE mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>

---

From: Joel Höglund <[email-masked]>
Date: Tue, 15 Dec 2020 12:19:03 +0100

Hi Laurence,

Thank you for your observations and comments!

I can't answer for what operations Stefan are using in his implementation,
but to continue discussing the possible solutions I'm interested in
clarifying the expectations on an off-the-shelf CBOR implementation:

When you talk about using off-the-shelf CBOR implementations, do you expect
to not have to do any other byte-level operations at all? Such as
knowing/updating an offset to step into a sequence, or byte level array
copying. I fully support that we should provide an encoding solution that
does not require hacking the CBOR implementation itself, so I think the
discussion should be which extra decoding/encoding operations we think are
acceptable on top of an existing CBOR implementation.

(For me, with the minimal on the wire size perspective, to change the CBOR
cert definition to completely align with COSE seems like a less attractive
option, but this is of course open for discussion, if the advantages are
deemed to outweigh the drawbacks.)

Best Regards

Joel Höglund

On Mon, 14 Dec 2020 at 20:09, Laurence Lundblade <[email-masked]>
wrote:

> Hi Stefan,
>
> First on the implementation — my understanding is that you’d have to hash
> from the byte offset of the first byte of the CBOR encoded head of
> cborCertificateType to the last byte of the Extensions to correctly
> implement this. Since the cborCertificateType is the first item in the
> sequence, its offset is zero, so that’s easy.
>
> I’m not sure how you’d use cbor_value_calculate_string_length since many
> of the items in the TBSCertificate are not strings. Maybe you calculate the
> length of the issuerSignatureValue and go back from the end? That
> wouldn’t account for CBOR encoded head of issuerSignatureValue though.
>
> It would be good to see an implementation in Python or Go or such to see
> if it's possible with those type of CBOR decoders.
>
>
> Second on the design — I still believe this design is counter
> to conventions used in CBOR for signing/hashing data. I think the folks
> that designed COSE thought this issue through.
>
>
> (My first design of of EAT did the hashing the way it is being done here.
> This was before COSE was publishes as an RFC. The folks using an
> off-the-shelf Python CBOR decoder had to hack that decoder to get the
> verification to work. Then EAT switched to COSE and I came to understand
> the reasons COSE works as it does.)
>
> LL
>
>
>
> On Dec 14, 2020, at 5:50 AM, Hristozov, Stefan <
> [email-masked]> wrote:
>
> Hi Laurence,
>
> During parsing the certificate I am calculating also an offset from its
> beginning after each parsed element. Tinycbor provides a function for
> getting the length of the byte or text string
> cbor_value_calculate_string_length [2], which is helpful for that.
>
> [2]:
> https://intel.github.io/tinycbor/current/a00047.html#gad5b2dd803244946b15603e09ce147044
>
> In particular issuerSignatureValue should probably be the signature over a
> byte string that contains an encoded TBSCertificate. This is what COSE does.
>
> The main reason for this is to allow implementation with off-the-shelf
> CBOR encoders and decoders. From some that I’ve looked at and one I’ve
> written myself, CBOR decoders don’t allow access a sub-part of the encoded
> CBOR so it can be input into the hash. There would be no way to get just
> the encoded bytes of the TBSCertificate out of the CBOR decoder unless you
> went in and hacked its source code in a special way.
>
> Has anyone implemented verification of Natively Signed CBOR Certificates?
> What CBOR decoder was used? Maybe I’m wrong about this?
>
> I realize byte string wrapping TBSCertificate might cause upheaval in the
> overall design because cborCertificateType would be inside the byte string
> wrapping.
>
> Another approach might be to just use COSE for Natively Signed CBOR
> Certificates. The COSE payload would be a TBSCertificate. COSE would take
> care of the byte string wrapping issues. This would increase the
> on-the-wire size of the certificate by about 10 bytes, but might decrease
> code size of the implementation by re use of a COSE implementation.
>
> LL
>
>
> > On Dec 2, 2020, at 12:49 AM, John Mattsson <
> john.mattsson=[email-masked]> wrote:
> >
> > - Added that the value "99991231235959Z" (no expiration date) is encoded
> as CBOR null. This is quite commonly used in IoT certificates. This saves 4
> bytes when used.
> > - Added CBOR encoding for uthorityKeyIdentifier and subjectKeyIdentifier
> which are heavily used by IEEE 802.1AR DevID (at least one of them are
> mandated depending on type of cert).
> > - Added optimization for the hardwareModuleName type of otherName, which
> is mandatory to use in IEEE 802.1AR DevID
> > - Added CBOR encoding for cRLDistributionPoints and authorityInfoAccess,
> which are both used in basically all HTTPS certificates on the web.
> > - Added support for registeredID. This was trivial and registeredID is
> used e.g. by the GSMA eUICC PKI Certificate Policy (SGP 14).
> > - Added a public private ECDSA key pair turning the example certificates
> into test vectors. An implementation can now create and verify the example
> RFC 7925 certificates.
> >
> > Cheers,
> > John
> >
> > To: Göran Selander <[email-masked]>, Göran Selander <
> [email-masked]>, Martin Furuhed <
> [email-masked]>, Shahid Raza <[email-masked]>, John
> Mattsson <[email-masked]>, Joel Hoglund <[email-masked]>,
> John Mattsson <[email-masked]>, Joel Höglund <
> [email-masked]>
> > Subject: New Version Notification for
> draft-mattsson-cose-cbor-cert-compress-05.txt
> >
> >
> > URL:
> https://www.ietf.org/archive/id/draft-mattsson-cose-cbor-cert-compress-05.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress
> > Htmlized:
> https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-05
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-mattsson-cose-cbor-cert-compress-05
> >
> > Abstract:
> [email-masked]

---

From: "Hristozov, Stefan" <[email-masked]>
Date: Tue, 15 Dec 2020 15:33:30 +0000

Hi Laurence,

i don't have an implementation in higher languages such as Python or Go, so i decided to code it today in Rust ( just for fun). Find my implementation attached. I tested this implementation with test vector A.1.1.

I have a function called decode_native which returns a struct containing the decoded certificate fields "decoded_data", the encoded certificate fields "signed_data" and the signature "signature".  To verify the certificate we need to provide the  signed_data and signature to a verification function, which I was not cable to do because the public key of the CA is not given in the test vector.

Decoding test vector A.1.1 my implementation generates the fowling result:

-----------------------------------------------------
cbor_cert_type is: 1
cert_serial_number is: [01, f5, 0d]
issuer is: [82, 70, 67, 32, 116, 101, 115, 116, 32, 67, 65]
validity_not_before is: 1577836800
validity_not_after is: 1612224000
subject is: [01, 23, 45, 67, 89, ab]
subject_pk_alg is: 1
subject_pk is: [02, b1, 21, 6a, b9, 6e, 5b, 3b, 33, 40, f5, bd, f0, 2e, 69, 3f, 16, 21, 3a, 04, 52, 5e, d4, 44, 50, b1, 01, 9c, 2d, fd, 38, 38, ab]
extensions is: 1
issuer_sgn_alg is: 6
signed_data is: [01, 43, 01, f5, 0d, 6b, 52, 46, 43, 20, 74, 65, 73, 74, 20, 43, 41, 1a, 5e, 0b, e1, 00, 1a, 60, 18, 96, 00, 46, 01, 23, 45, 67, 89, ab, 01, 58, 21, 02, b1, 21, 6a, b9, 6e, 5b, 3b, 33, 40, f5, bd, f0, 2e, 69, 3f, 16, 21, 3a, 04, 52, 5e, d4, 44, 50, b1, 01, 9c, 2d, fd, 38, 38, ab, 01, 06]
signature is: [44, 5d, 79, 8c, 90, e7, f5, 00, dc, 74, 7a, 65, 4c, ec, 6c, fa, 6f, 03, 72, 76, e1, 4e, 52, ed, 07, fc, 16, 29, 4c, 84, 66, 0d, 5a, 33, 98, 5d, fb, d4, bf, dd, 6d, 4a, cf, 38, 04, c3, d4, 6e, bf, 3b, 7f, a6, 26, 40, 67, 4f, c0, 35, 4f, a0, 56, db, ae, a6]
-----------------------------------------------------

Very similar code can be achieved also with tinyCBOR in C. Many values are not strings you are right so cbor_value_calculate_string_length cannot be used but integers therefore to get their length is not difficult.

I hope this code helps.

What exactly do you mean by hacking the decoder? Do you mean to track the offset? What are the alternatives?

Best regards,
Stefan

PS: I know the code contains a lot of copy+paste and needs to be refactored.

On Mon, 2020-12-14 at 11:09 -0800, Laurence Lundblade wrote:
Hi Stefan,

LL

On Dec 14, 2020, at 5:50 AM, Hristozov, Stefan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Laurence,

Best regards,
Stefan

Göran

On 2020-12-07, 23:02, "COSE" <[email-masked]<mailto:[email-masked]>> wrote:
I don’t think it works very well at all to directly sign encoded CBOR. It should be wrapped in a byte string.

LL

> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>

--

Stefan Hristozov

--

Stefan Hristozov

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Dec 2020 17:53:59 +0100

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

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.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 15 Dec 2020 12:38:11 -0800

> On Dec 15, 2020, at 8:53 AM, Carsten Bormann <[email-masked]> wrote:
> 

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.

> 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

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 15 Dec 2020 12:46:19 -0800

> On Dec 15, 2020, at 7:33 AM, Hristozov, Stefan <[email-masked]> wrote:
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Dec 2020 01:27:43 +0100

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

One valid use of CBOR is to prefix a single CBOR data item to a byte sequence (not itself packaged as a CBOR string).  Any CBOR implementation that supports this usage can be used here.  (E.g., in the Ruby cbor-diag gem or in Elixir excbor, the relevant interface method would be “decode_with_rest”; in the C/Ruby cbor gem, it gets only slightly more complicated with StringIO, unpackers, and buffers.)

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Wed, 16 Dec 2020 14:46:10 +0000

Hi,

Thank the great discussion. I hope we can discuss some more during today’s interim.

Stefan Hristozov wrote:
> which I was not cable to do because the public key of the CA is not given in the test vector.

In version -05 of the draft, the public and private key of the CA are included:

   All of the the above example certificate were signed and can be
   verified with the following key pair where the private key is encoded
   as in COSE [RFC8152<https://tools.ietf.org/html/rfc8152>].

   issuerPublicKeyAlgorithm :
   1 (id-ecPublicKey + secp256r1)

   issuerPublicKey :
   h'02AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF678867845E'

   issuerPrivateKey :
   h'DC66B3415456D649429B53223DF7532B942D6B0E0842C30BCA4C0ACF91547BB2'

(Version -06 of the draft will also include the private key of the subject in the example certificate. This makes it possible to use the example certificate in e.g., EDHOC test vectors)

Göran Selander wrote:

I have so far only implemented DER -> CBOR (type 1). I started in C++17 but have now moved to Rust. I wrote my own DER decoder and CBOR encoder. The reason I wrote everything myself was to make sure I understand all the nitty gritty details of DER and CBOR. I plan to release the source code when I have cleaned it up a bit.

John

From: "Hristozov, Stefan" <[email-masked]>
Date: Tuesday, 15 December 2020 at 16:34
To: "[email-masked]" <[email-masked]>
Cc: John Mattsson <[email-masked]>, Göran Selander <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [COSE] bstr wrapping for native signed (was Re: New Version Notification for draft-mattsson-cose-cbor-cert-compress-05.txt)

Hi Laurence,

I hope this code helps.

Best regards,
Stefan

LL

Best regards,
Stefan

[1]: https://github.com/intel/tinycbor<https://protect2.fireeye.com/v1/url?k=5c0bb111-03908852-5c0bf18a-861fcb972bfc-06cd73c092163b93&q=1&e=5e295a93-a44c-4f30-9642-65f681a6b5ec&u=https%3A%2F%2Fgithub.com%2Fintel%2Ftinycbor>
[2]: https://intel.github.io/tinycbor/current/a00047.html#gad5b2dd803244946b15603e09ce147044<https://protect2.fireeye.com/v1/url?k=73373c09-2cac054a-73377c92-861fcb972bfc-798ce0d2767b9e63&q=1&e=5e295a93-a44c-4f30-9642-65f681a6b5ec&u=https%3A%2F%2Fintel.github.io%2Ftinycbor%2Fcurrent%2Fa00047.html%23gad5b2dd803244946b15603e09ce147044>

Göran

LL

--

Stefan Hristozov