cose-wg / examples Goto Github PK

This file says:

     "key":{
        "kty":"EC",
        "kid":"11",

but, page 38 of draft-ietf-cose-msg-24.txt says:

o  The 'kty' field MUST be present and it MUST be 'EC2'.

while the kty field is not part of the signature this did raise some concern that I'm verifying with the wrong group! Please confirm that this file using the NIST 'nistp256' curve? (not secp256XX?)

I'm feeding the following digest into the signature validation:
(byebug) sha256.unpack("H*")
["45e243bb7071e72a288416ccb9cfbd2932fe1926916fe85b344141ecce91e4bb"]

(byebug) sig01_pub_key
#<ECDSA::Point: nistp256, 0xbac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a09eff, 0x20138b0b706db558af8254ab7804a3a64b6d72ccf5adbedbb4a2eff045f8>

(byebug) signature
#<ECDSA::Signature:0x00000001f1df00 @s=51765963774164195565914350724151000343397507914291589008366842864028004758943, @r=106251839252054433277813174560343063247957774643926440805394321619487281072353>

I wonder if I've gotten something trivial screwed up? Order or r/s maybe.

Heya,

I'm running into an issue where the decoded CBOR for the "EdDSA-sig-02: EdDSA - 448 - sign1" example contains "kid":"3d448" while the actual kid is:

The signature verifies successfully if I ignore the kid mismatch, so the key seems to be otherwise correct?

In the following example, the unprotected map has two items, the "alg" and "kid":

But in the encoded data, we find label 5:

According to https://www.iana.org/assignments/cose/cose.xhtml#header-parameters, "kid" is 4 and "IV" is 5.

In provided examples for RSA OAEP Cose Decrypt objects RSA-OAEP algorithm type is put into unprotected section of recipient.
It sounds more accurate to me to to put it into "protected" section of recipient.
RFC8230 and RFC8152 are not precisely defining where "alg" should be put for RSA-PSS and RSA-OAEP objects.

The README mentions a tool. Is this available somewhere?

I am trying to implement my own COSE library and I would like to include these examples in my repository for testing purposes and bits of them in unit tests, however, there is clear no license associated with these examples, so I am not sure if I am allowed to copy or transform them in any way.

This repo seems to contain only ES256 examples.

A previous version of this repo had ecdsa-01 (or probably -02) using cose_sign1.
The latest version is using cose_sign, which moves the algorithm identifiers into the array[4], rather than the global protected bucket. Bad on my code for not handling both, but I wanted to make sure that the change was intentional, and query whether there are any cose_sign1 examples.

The y-value listed in the file:

 "y":"IBOL-C3BttVivg-lSreASjpkttcsz-1rb7btKLv8EX4",

is not valid base64! "-" is not a base64 character according to https://en.wikipedia.org/wiki/Base64 and RFC4648. My ruby decoding does not automatically process it. Your encoding is base64url encoded.

Base64.urlsafe_decode64(str) solves this problem, but I wonder if the examples should be coded
into stock base64?

From https://datatracker.ietf.org/doc/html/rfc8152#section-3.1 alg:

This parameter MUST be authenticated where the ability to do so exists... This authentication can be done either by placing the header in the protected header bucket or as part of the externally supplied data.

But the example https://github.com/cose-wg/Examples/blob/master/sign1-tests/sign-pass-01.json puts the alg in the unprotected bucket, the protected bucket is a0 (empty) and there is no externally supplied data.

Also, what does "Redo protected" mean in "title":"sign-pass-01: Redo protected"?

Hi,

When attempting to verify RSA-PSS example I am not able to verify correctly if enforcing the salt length in https://tools.ietf.org/html/rfc8230#section-2. E.g. 32 for PS256.

It does verify correctly if I let the salt length be calculated automatically based on the signature.

Am I missing something here?

Thank you.