Add a descripiton and examples of key representation.

[dajiaji]

@hannestschofenig @OR13 @laurencelundblade

I have written a description and examples of key representation for COSE-HPKE.

Could you please review it to see if it matches your assumption?

Closes #46

[ilaril]

I think that key ops stuff is not correct. Looks like empty key_ops makes the key unusable, and DeriveBits is very strange operation for decryption (since it is explicitly not for keys).

Here is what I think, from reading RFC 9052 (but I am not sure this is correct):

• For one-layer structure, the correct key operations are 3/4 (Encrypt/Decrypt).
• For two-layer structure, the correct key operations are 5/6 (Wrap/Unwrap).
• There should be no restrictions on what key ops are allowed beyond RFC 9052.
  • Some combinations are not a good idea, but that is BCP stuff.

[dajiaji]

@ilaril Thanks for your comment.

I think that key ops stuff is not correct.

First of all, although the alg value is defined as the combination of KEM/KDF/AEAD, the alg parameter for COSE_Key is optional and I think the key_ops parameter is only for the KEM keys. Unless considering this way, I think we cannot keep the consistency with the previous definition of the use of key_ops below:

The section 6.3.1 (Direct ECDH) in RFC9053 says that the key_ops must be used as follows:

If the "key_ops" field is present, it MUST include "derive key" or "derive bits" for the private key. If the "key_ops" field is present, it MUST be empty for the public key.

In the case of the section 6.4 (ECDH with Key Wrap):

If the "key_ops" field is present, it MUST include "derive key" or "derive bits" for the private key. If the "key_ops" field is present, it MUST be empty for the public key.

In addition, unless defining key_ops in this way, the key cannot be available on the Web Cryptography API. It will be considered an invalid key (this is the case of JWK but we have to consier the consistency with JWK definition).

Looks like empty key_ops makes the key unusable,

Actually, my implementation also has a bug in the processing of key_ops (I have to fix it as soon as possible), but are there any other examples that the keys that have empty key_ops cannot be used?

and DeriveBits is very strange operation for decryption (since it is explicitly not for keys).

I agree that deriveBits is a strange thing.

However, since the Web Cryptography API used to implement a HPKE KEM operation is deriveBits, not deriveKey, I think we should limit the use of key_ops to deriveBits. In fact, the shared_secret generated as a result of KEM is not a key, just keying material.

[laurencelundblade]

The COSE HPKE draft may not define identifiers and uses for PQ algorithms, but it will allow them in the future, right? That means the key type might not be EC2 or OKP, so you can't just say the key type must be EC2 or OKP. When RFC 9053 says that, it is for specific algorithms.

We need to do similar to what 9053 does. Something like listing the ciphersuites for which a particular definition of a COSE_key applies.

[ilaril]

Ugh, this key_ops stuff looks like a total mess. The webcrypto key operations just are not expressive enough:

• There are no ECDH/KEM public key operations.
• There is no direct encryption operation (like one-layer HPKE).
• However, there are "Key Transport Encryption" and "Key Wrap Encryption", which are public key operations (as well as "Verify"). What is the difference? Are any algorithms capable of both?

I wonder if the best way out would be to do whatever dumb thing WebCrypto requires (with disclaimers that this was due to shortcomings of WebCrypto) and define key_ops2 with actually sane semantics.

Regarding key types, the acceptable key (sub)types should be listed by HPKE KEM:

• KEM 16/19 use EC2/1
• KEM 17/20 use EC2/2
• KEM 18/21 use EC2/3
• KEM 22 uses EC2/8
• KEM 32 uses OKP/4
• KEM 33 uses OKP/5
• KEM 48 uses OKP/TBD (needs to be defined)

(Of course, the list should be restricted to entries that are actually used.)

All the entries happen to use EC2 or OKP, and this will probably continue to hold, but there are no guarantees it will continue to hold. Some KEMs might even be able to use multiple key subtypes.

[laurencelundblade]

On Nov 9, 2023, at 12:05 PM, ilaril @.**@.>> wrote:

Regarding key types, the acceptable key (sub)types should be listed by HPKE KEM

No and yes.

No because we are using ciphersuites now, not KEM IDs.

Yes, because they vary by KEM and the COSE-HPKE draft is for current AND future KEMS

LL

[ilaril]

Each cipher suite maps to one KEM (signature -> 1), and each KEM maps to key subtypes (signature 1 -> ).

So specifying key subtypes for cipher suites directly would be denormal.

[laurencelundblade]

Agreed that it denormal and we could specify by KEM with some text that says there is mapping to the ciphersuite.

But denormal is not a big deal here because there aren't that many and they will be added rarely so it could be by ciphersuite too.

[dajiaji]

The COSE HPKE draft may not define identifiers and uses for PQ algorithms, but it will allow them in the future, right? That means the key type might not be EC2 or OKP, so you can't just say the key type must be EC2 or OKP. When RFC 9053 says that, it is for specific algorithms.

I also anticipate adding key types for post-quantum hybrid KEM in the future, and I have taken care not to limit it to just EC2 and OKP. Would the following description be insufficient?

* The "kty" field MUST be present, and it MUST be one of the key types for HPKE KEM.
* If the "kty" field is "OKP" or "EC2", the "crv" field MUST be present
  and it MUST be a curve for HPKE KEM.

I intended to include future-defined KEMs in the statement "the key types for HPKE KEM.”

We need to do similar to what 9053 does. Something like listing the ciphersuites for which a particular definition of a COSE_key applies.

Okay. I'll add it.

[dajiaji]

I wonder if the best way out would be to do whatever dumb thing WebCrypto requires (with disclaimers that this was due to shortcomings of WebCrypto) and define key_ops2 with actually sane semantics.

I agree with your thoughts on key_ops to some extent. However, regarding the key_ops, I'd like to proceed with this PR as it is.

KEM 48 uses OKP/TBD (needs to be defined)

Hmm, I don't think OKP can be used for KEM48. I think we should define an additional key type for Hybrid KEM, which looks like HPKE-KEM that I proposed before.

[ilaril]

Well, key_ops2 stuff would be different draft, just leaving note that the weird stuff is because of WebCrypto compatibility.

OKP can be used for KEM48 specifically, and should be, because it is the matching keyshape.

HPKE-KEM key type would have been very useful with a'la carte stuff, but it is less useful now with cipher suites.

[dajiaji]

@ilaril @laurencelundblade

I have added a mapping table of alg, kty and crv. Could you check whether it's in line with your thoughts?

[dajiaji]

HPKE-KEM key type would have been very useful with a'la carte stuff, but it is less useful now with cipher suites.

I would like to make this my last post for the hybrid KEM since it is not related to this PR, but I envision the following, not HPKE-KEM as is, but specialized for concatenated keys for post-quantum hybrid KEM (and digital signature?).

 {
  "kty": "Hybrid",
  "alg": "HPKE-Base-X25519Kyber768-SHA256-AES256GCM",
  "pub": "<concatenated public key>",
  "priv": "<concatenated private key>"
 }

[OR13]

Let's avoid signatures for this draft, there is work at cfrg that is still being worked out for hybrid signatures.

[selfissued]

Agreed. Let's limit our dependencies to completed standards.

-- Mike

---

From: Orie Steele @.> Sent: Saturday, November 11, 2023 4:55:35 AM To: cose-wg/HPKE @.> Cc: Subscribed @.***> Subject: Re: [cose-wg/HPKE] Add a descripiton and examples of key representation. (PR #47)

Let's avoid signatures for this draft, there is work at cfrg that is still being worked out for hybrid signatures.

— Reply to this email directly, view it on GitHubhttps://github.com/cose-wg/HPKE/pull/47#issuecomment-1806665192, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB2KJ7UJB7URQLRN4UMEKALYD3ZLPAVCNFSM6AAAAAA66J7S46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGY3DKMJZGI. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[panva]

@ilaril Thanks for your comment.

I think that key ops stuff is not correct.

First of all, although the alg value is defined as the combination of KEM/KDF/AEAD, the alg parameter for COSE_Key is optional and I think the key_ops parameter is only for the KEM keys. Unless considering this way, I think we cannot keep the consistency with the previous definition of the use of key_ops below:

The section 6.3.1 (Direct ECDH) in RFC9053 says that the key_ops must be used as follows:

If the "key_ops" field is present, it MUST include "derive key" or "derive bits" for the private key. If the "key_ops" field is present, it MUST be empty for the public key.

In the case of the section 6.4 (ECDH with Key Wrap):

If the "key_ops" field is present, it MUST include "derive key" or "derive bits" for the private key. If the "key_ops" field is present, it MUST be empty for the public key.

In addition, unless defining key_ops in this way, the key cannot be available on the Web Cryptography API. It will be considered an invalid key (this is the case of JWK but we have to consier the consistency with JWK definition).

Looks like empty key_ops makes the key unusable,

Actually, my implementation also has a bug in the processing of key_ops (I have to fix it as soon as possible), but are there any other examples that the keys that have empty key_ops cannot be used?

and DeriveBits is very strange operation for decryption (since it is explicitly not for keys).

I agree that deriveBits is a strange thing.

However, since the Web Cryptography API used to implement a HPKE KEM operation is deriveBits, not deriveKey, I think we should limit the use of key_ops to deriveBits. In fact, the shared_secret generated as a result of KEM is not a key, just keying material.

I haven't undergone a WebCryptoAPI based implementation yet, but i will soon in the jose module. That being said, I believe that, considering the current editor's draft of WebCryptoAPI as well as use of Secure Curves

• the JWK import operations don't limit the alg value of a JWK, which is good
• key_ops are empty for public keys
• key_ops are limited to derive_bits and/or derive_key

And so the definition in this PR is consistent with what WebCryptoAPI allows you to import/generate and the keys will be usable given this PR is in place AS-IS.

I will come back when I have more implementer's feedback under the current WebCryptoAPI state constraints.

---

The above may not be applicable to COSE_Key representations, but for the JOSE based implementation I think it's in line with the expectations and limits put forth by WebCryptoAPI.

[OR13]

@panva thanks for your review.

I found that I needed to remove the unrecognized HPKE alg values before importing JWKs for use with dhkem.

I have a sorta side by side comparison of your library and my hacky attempt at HPKE using @dajiaji 's library at hpke.dev, but you should ignore it if you want to attempt a blind implementation based only on the specs.

[panva]

I found that I needed to remove the unrecognized HPKE alg values before importing JWKs for use with dhkem.

Why? Which webcrypto implementation/runtime?

[panva]

Nevermind, answered myself - https://github.com/panva/jose/actions/runs/6833462247/job/18585240434, i'll open bug reports for both firefox and workerd and add WPTs for this behaviour. These bugs in implementations shouldn't drive the spec tho.

edit:

• https://github.com/cloudflare/workerd/issues/1403
• https://bugzilla.mozilla.org/show_bug.cgi?id=1864262

[dajiaji]

Let's avoid signatures for this draft, there is work at cfrg that is still being worked out for hybrid signatures.

Needless to say, the JWK/COSE_Key expression for the PQ/T hybrid scheme should be defined as a separate spec independent of this COSE-HPKE spec :-)

[dajiaji]

@hannestschofenig Could you review and merge this PR? As far as I can see, there seems to be no opposition to the current status of the PR.

[hannestschofenig]

I would like to merge this PR. Further refinements can then be made on top of it.

[laurencelundblade]

Let's be sure an capture the comments as issues if you merge. The PR doesn't correctly say how to use alg and curve yet.

[dajiaji]

Thank you all for your reviews and comments. I will be able to get some time to update this PR this weekend. Please wait for a while.