Inline:
> In short, "draft-ra-cose-hybrid-encrypt", registered "alg" values that are
> "suites", so you can switch on a single string or integer...
No, the "alg" values in this draft are not "suites" at least in the context
of our discussions on the "alg" for COSE-HPKE.
The "alg" values are just only for KEM and nobody wants to separate and
parameterize the cryptographic components that make up KEM.
and it makes the "alg" value mandatory for the new "kty" "HYBRID".
If you don't want a bunch of JOSE / COSE algorithms that are "super close,
but not compatible", you cannot make the "alg" values mandatory, because
the definition of the "alg" parameter in RFC7517(JWK) is as follows:
[image: image.png]
> I might be reading this wrong, but it seems that "x25519_kyber768",
> assumes a KDF and a Hash Function.
Yes, but the KDF/hash functions are NOT for the blue part of the existing
HPKE ciphersuite below, BUT for the red part of it.
DHKEM(X25519, HKDF-SHA256) + HKDF-SHA256 + AES-128-GCM
> It does not expose them as parameters that an implementer chooses to
> support.
Again, nobody wants to expose the cryptographic components in the KEM as
parameters that an implementer chooses to support.
In other words, they seem to have added KEMs in the most natural way to the
> existing ECDH-ES+A256KW ecosystem.
The most natural way to follow the existing ECDH-ES definition, is
undoubtedly using "KEM" that Ilari mentioned in his previous email.
Does the string "ECDH-ES" contain specific curve information and other
parameters related to key agreement?
Given that the "alg" parameter in JWK and COSE_Key is optional in the
JWK/COSE_Key spec, it is sufficient for "alg" to represent a rough category
of algorithms that can be omitted without issues.
>From this perspective, I believe that the "ECDH-ES" and "EdDSA" can be
regarded as best practices and are well integrated with the W3C Web
Cryptography API.
And it goes without saying that the current COSE-HPKE spec
("HPKE-v1-Base"(-KEM)) adopts the same approach.
Adopted in a CRFG registry... Not a COSE or JOSE registry.... meaning no
> expert review from COSE or JOSE experts.
...HPKE is a specification for the hybrid public key encryption scheme,
while COSE is a specification for data container/formats for cryptographic
operations.
They are completely separate things and the layers in which both exist are
also completely different.
Given the existence of the HPKE framework, if there are specific KEM, KDF,
or AEAD algorithms that you would like to use for public key-based
end-to-end encryption, it is advisable to request their addition to the
HPKE framework rather than defining them separately in COSE/JOSE layer.
No, hopefully the elaboration above clarifiers.
It seems that you have misunderstood some aspects of this specification,
and I apologize, but I feel there is a lack of consistency in what you are
saying.
Best,
Daisuke
2023年7月12日(水) 1:30 Orie Steele <[email protected]>:
> In short, "draft-ra-cose-hybrid-encrypt", registered "alg" values that are
> "suites", so you can switch on a single string or integer... and it makes
> the "alg" value mandatory for the new "kty" "HYBRID".
>
> Inline for the rest:
>
> On Tue, Jul 11, 2023 at 10:47 AM AJITOMI Daisuke <[email protected]>
> wrote:
>
>> Hi Orie,
>>
>> Sorry for not keeping up with the recent discussion on the "alg" design
>> policy (I'll take some time this weekend to catch up).
>>
>> I'm a bit confused because it seems like you support this draft.
>>
>> This draft is identical to my proposal in that it limits the "kty" to KEM
>> ("HPKE-KEM" in my proposal), and in that it limits the "alg" design to the
>> scope of the KEM (not including KDF or AEAD, which are not related to its
>> key operation).
>>
>> Are you saying that you have dropped your argument that "all
>> KEM-KDF-AEADs should be included in the alg value" ?
>>
>
> I am saying I like this part of their draft:
>
>
> https://datatracker.ietf.org/doc/html/draft-ra-cose-hybrid-encrypt-00#name-kem-combiner
>
> I might be reading this wrong, but it seems that "x25519_kyber768",
> assumes a KDF and a Hash Function.
>
> It does not expose them as parameters that an implementer chooses to
> support.
>
> I also like this part:
>
>
> https://datatracker.ietf.org/doc/html/draft-ra-cose-hybrid-encrypt-00#section-6
>
> For example: "secp384r1_kyber768+A256KW" - P-384 + Kyber768 parameter +
> CEK wrapped with "A256KW" ...
> ... I am assuming this also means "KMAC256" and "SHA3-384" are applied as
> well... given the definition above.
>
> In other words, they seem to have added KEMs in the most natural way to
> the existing ECDH-ES+A256KW ecosystem.
>
> I would still like to see HPKE support in JOSE do the same, but perhaps
> JOSE and COSE will part ways on encryption envelopes.
>
>
> Also, my proposal focuses only on algorithms that can be adopted in HPKE
>> (carefully selected for HPKE), whereas this draft is a proposal that more
>> strongly promotes crypto-agility, which you criticized.
>>
>
> I don't think that's correct.
>
>
>> Specifically, there are four KEMs proposed in this draft, excluding key
>> wrapping, but only one of these (X25519Kyber768) is adopted by HPKE.
>>
>
> Adopted in a CRFG registry... Not a COSE or JOSE registry.... meaning no
> expert review from COSE or JOSE experts.
>
>
>> The point is that in the HPKE world, the experts have been very selective
>> in choosing one quantum resistant KEM.
>>
>>
> I don't think HPKE registry maintainers are expected to be experts on JOSE
> or COSE,
> and I would expect HPKE registry to contain entries for all crypto that
> people want, not just crypto that we think is a good fit for JOSE and COSE.
>
>
>> I know you claimed that you wanted to reduce the number of algorithm
>> choices and use algorithms carefully selected by experts, does this mean
>> that you have changed your mind on this idea as well?
>>
>>
> No, hopefully the elaboration above clarifiers.
>
>
>> I don't think we want a bunch of JOSE / COSE algorithms that are "super
>>> close, but not compatible"...
>>
>>
>> At least, I very much agree with this view and think that the design
>> policy of "alg" and key representation for JOSE and COSE should be the same
>> (should be synchronized), which is why I wrote the following draft,
>> separated from the COSE-HPKE.
>> https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/
>>
>
>
> I agree HPKE needs to be synchronized with JOSE and JOSE Key and Envelope
> formats.
>
> I think this draft is currently proposing a better path forward for key
> types and envelope formats.
>
> I am hopeful we can get alignment on the registry part of this, I see
> value in JOSE and COSE specific kem registry...
> since JOSE and COSE already have registries for elliptic curves.
>
> - https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves
> - https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve
>
> It seems more natural to do similar for KEMs, and less natural to rely
> directly on HPKE CFRG registry.
>
> I had originally suggested this approach for COSE HPKE... in a massive
> thread with Ilari that probably nobody read : ),
> and it was rejected because of the authors desire to rely on the HPKE CFRG
> registry,
> which I continue to assert is not a good design choice.
>
> Regardless of any final design solutions I do think we need to get some
> better conventions regarding registries for JOSE and COSE, and hopefully
> that will happen now that we have competing proposals for where KEMs are
> registered.
>
>
>>
>> Best,
>> Daisuke
>>
>> 2023年7月11日(火) 22:59 Ilari Liusvaara <[email protected]>:
>>
>>> On Tue, Jul 11, 2023 at 05:49:45PM +0530, tirumal reddy wrote:
>>> > Hi all,
>>> >
>>> > The new draft
>>> https://datatracker.ietf.org/doc/draft-ra-cose-hybrid-encrypt/
>>> > defines the use of traditional and PQC algorithms, a hybrid
>>> post-quantum
>>> > KEM, for JOSE and COSE. Hybrid key exchange refers to using multiple
>>> key
>>> > exchange algorithms simultaneously and combining the result with the
>>> goal
>>> > of providing security even if all but one of the component algorithms
>>> is
>>> > broken.
>>> >
>>> > Comments and suggestions are welcome.
>>>
>>> To me, this seems greatly overcomplicated.
>>>
>>>
>>> 1) The mess of N algorithms can be reduced to just two by making
>>> method polymorphic in key, just like ECDH-ES has always been.
>>>
>>> - KEM
>>> - KEM+A256KW
>>>
>>> Only AES-256 because:
>>>
>>> - This is intended for post-quantum.
>>> - Security level of even Kyber512 could be significanly above AES128.
>>> - AES-192 is poorly supported.
>>>
>>> And for simplicity, fixedInfo should use the same format as for
>>> ECDH-ES. Specifically:
>>>
>>> - For COSE, Core Deterministic Encoding of the COSE_KDF_Context.
>>> - For JOSE, the concatenation format with the same inputs as used
>>> for ECDH.
>>>
>>>
>>> 2) It would be simpler for implemeters to always use KMAC256. Most of
>>> the code can be shared with Kyber, which is _not_ guaranteed for
>>> KMAC128. And the speed difference is minor.
>>>
>>>
>>> 3) The mess of the key format could be reduced to just concatenating
>>> the parts into OKP key with new "curves".
>>>
>>> Yes, OKP was designed for such stuff from the very begninning.
>>>
>>> And even if it is philosophically wrong, this could technically even be
>>> appiled to ciphertexts in order to stick the ciphertext into "eph".
>>>
>>>
>>> 4) I don't think the use of K is allowed by kem-combiners. AFAIK, the
>>> minimum length of K for KMAC256 is 32 bytes, but some of stuff using it
>>> has 21 byte K.
>>>
>>>
>>>
>>> > ---------- Forwarded message ---------
>>> > From: <[email protected]>
>>> > Date: Wed, 5 Jul 2023 at 17:56
>>> > Subject: New Version Notification for
>>> draft-ra-cose-hybrid-encrypt-00.txt
>>> >
>>> > Name: draft-ra-cose-hybrid-encrypt
>>> > Revision: 00
>>> > Title: Hybrid key exchange in JOSE and COSE
>>> > Document date: 2023-07-05
>>> > Group: Individual Submission
>>> > Pages: 30
>>> > URL:
>>> > https://www.ietf.org/archive/id/draft-ra-cose-hybrid-encrypt-00.txt
>>> > Status:
>>> > https://datatracker.ietf.org/doc/draft-ra-cose-hybrid-encrypt/
>>> > Html:
>>> > https://www.ietf.org/archive/id/draft-ra-cose-hybrid-encrypt-00.html
>>> > Htmlized:
>>> > https://datatracker.ietf.org/doc/html/draft-ra-cose-hybrid-encrypt
>>>
>>>
>>>
>>>
>>> -Ilari
>>>
>>> _______________________________________________
>>> COSE mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/cose
>>>
>>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
