On 2022-03-15 13:20, Mike Prorock wrote:
Anders,
What are your thoughts on a kty for hash based, one for lattice, and then later for
isogeny or other families as required? That seems in line with the definition of kty
from 4.1 of the jwk rfc "The 'kty' (key type) parameter identifies the cryptographic
algorithm family used with the key"
Hi Mike, I must confess that my insights in the actual algorithms are fairly
modest (big understatement); I see this exclusively from an architectural point
of view.
To avoid talking in riddles, consider the initial part of current X.509 public
key definitions:
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1)
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1.2.840.10045.2.1)
OBJECT IDENTIFIER NIST-P-256 (1.2.840.10045.3.1.7)
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER Ed25519 (1.3.101.112)
X.509 public keys follow the top-level identifier concept I'm advocating. I
would be very surprised if the PKIX folks lump all known PQ key algorithms
under a single identifier even if it would be technically feasible. If we want
COSE/JOSE keys to eventually become first class citizens (like X.509) in
cryptographic subsystems, a rethink may be necessary.
Yes, taking on such a scheme will require a bunch of RFCs but they would all be
very short.
"One key container to rule them all!" I hope not :)
Cheers,
Anders
https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
<https://datatracker.ietf.org/doc/html/rfc7517#section-4.1>
Mike Prorock
mesur.io <http://mesur.io>
On Tue, Mar 15, 2022, 00:04 Anders Rundgren <[email protected]
<mailto:[email protected]>> wrote:
Hi Orie,
To me PQK represents overloading since the anticipated crypto systems seem
to be more or less unrelated. Overloaded identifiers make the introduction of
new algorithms more difficult and is at odds with pluggability.
To avoid overloading kty:CRYD3 could be a possible choice. For DH keys (if
applicable), I would consider kty:CRYD3-DH which would give you basic algorithm
separation.
BouncyCastle which has been the leading crypto provider for Java (until
Java17), have indeed defined a unique key type for the single PQC algorithm
they currently support:
https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/pqc/jcajce/spec/SPHINCSPlusParameterSpec.java
<https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/pqc/jcajce/spec/SPHINCSPlusParameterSpec.java>
It would be valuable knowing what the PKIX folks are planning here since
they have basically the same problem. Russ?
Thanx,
Anders
On 2022-03-14 21:19, Orie Steele wrote:
> > I believe there’s insufficient reason to make things different for
this new class of algorithms.
>
> If that's the case, we will need to register a new "crv" like property for post
quantum keys, let's call it "pset" for now, as we had originally intended to register this
property, and it's still present in the current draft.
>
> And then define a mapping between that new property and every supported
alg.
>
> For example:
>
> - kty:EC, crv:P-256 -> alg:ES256 / alg:ECDH-ES+A256KW
> - kty:EC, crv:secp256k1 -> alg:ES256K
> - kty:OKP, crv:Ed25519 -> alg:EdDSA
> ...
> - kty:RSA, n / e -> alg:PS256 / RS256 ?
> - kty:EC, crv:secp256k1... ? -> alg:ES256K / alg:SS256K?
> ...
>
> - kty:PQK, pset: CRYD3 -> alg: CRYD3
> - kty:PQK, pset: CRYD5 -> alg: CRYD5
> - kty:PQK, pset: xmss.public_key.SHA2_10_256 -> alg: xmss.SHA2_10_256 ?
>
> We have learned a lot since JOSE was first created.
>
> In particular we have learned that handling optional parameters is a source of
security issues, especially related to "alg".
>
> New registrations should not make this problem worse.
>
> If we can't make "alg" required for "kty:PQK" we will need to define a new
"pset" or similar, and it will have to have a mapping for every registered `alg`.
>
> So for a dilithium example:
>
> kty: PQK (required)
> pset: CRYD3 (required)
> x: ... (required)
> alg: CRYD3 (optional)
>
> Obviously JWK thumbprint will need to be aware of all required fields,
and will need to drop all optional fields in order to be useful.
>
> If we don't define something like "pset" and we don't make "alg" required for "kty:PQK"... the only optional will be to
explode based on mismatched keys / signatures... unless I am missing something... we have the same problem with P-256 keys today... when "alg" is not
present, you can't tell if the key is for "signing" or "key agreement"... which means that any JWE / JWS can target that key, and the key
representation won't catch what the key was intended for... unless "alg" and "use" are present... which nobody can rely on, because they are
marked optional.
>
> Take a look at:
https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties
<https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties>
<https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties
<https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties>>
>
> Notice that they include "alg" and "use"... if both are optional, why
include them in such an example?
>
> FWIW I think making "alg" required is the best thing to do for new key
types moving forward (it addresses future ambiguity / explicit over implicit makes me feel
safer).
>
> Extra language regarding thumbprint computation seems "worth it" for
removing parameter kty type to alg type ambiguity.
>
> Keep in mind we will have this same issue for the families of lattice, hash, and
isogeny... So if we set a precedent of registering an alternative for 'crv' for lattices
say. "pset", we will need to follow through with the others as well, either
reusing that new parameter or creating a new one for each family.
>
> @Mike Jones
>
> Should there be 1 new "crv' like property or 1 per family (3 in total).
>
> What would you suggest for the new "crv" like parameter name? "pset" ?
>
> Do you have an alternative proposal?
>
> OS
>
>
> On Mon, Mar 14, 2022 at 11:19 AM Mike Jones <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
>
> Requiring “alg” in a JWK for one class of algorithms and/or key type
values would be non-parallel to other algorithms and/or key type values. This
matters not just for aesthetic reasons but also because it would make the JWK
Thumbprint calculations [RFC 7638] have to special-case these algorithms and/or
key type.____
>
> __ __
>
> Yes, you always need to know the “alg” when using a key – but in
JOSE and COSE you already authoritatively get that from the JOSE or COSE header
parameters. I believe there’s insufficient reason to make things different for
this new class of algorithms.____
>
> __ __
>
> -- Mike____
>
> __ __
>
> *From:* COSE <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> *On Behalf Of * Orie Steele
> *Sent:* Monday, March 14, 2022 8:20 AM
> *To:* Russ Housley <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> *Cc:* Ilari Liusvaara <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>; [email protected]
<mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>
> *Subject:* Re: [COSE] draft-prorock-cose-post-quantum-signatures
[Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]____
>
> __ __
>
> Refocusing on the "kty" : "OKP" vs "PQK" issue.
>
> As I understand it, "alg" is optional even when "kty": "OKP"... so a main reason to choose "kty": "PQK"
would be to say that "alg" is now required... If we think overloading "OKP" would cause harm, we should make the new "kty" bring more to the
table, such as mandating the presence of "alg".
>
> I expect we will be marking "alg" values as forbidden (when the become unadvisable), and not marking whole
"kty" families as forbidden in the future... having the "alg" be required in "kty" "PQK"
seems like it provides a better security posture in that context, but eager to hear from others.
>
> Regards,
>
> OS____
>
> __ __
>
> On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> wrote:____
>
>
>
> > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
> >
> > On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
> >>
> >>
> >>> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
> >>>
> >>> NISTPQC signatures would fit into signature keys "subtype",
but NISTPQC
> >>> KEMs will not fit into the key agreement keys "subtype", so
that would
> >>> be a third "subtype" (all NISTPQC algorithms have OKP-style
key format,
> >>> as this was required by NIST).
> >>
> >> Right. It makes sense to add support for KEM. We can
figure that out
> >> without waiting for NIST to announce Round 3 winners. We
can do the
> >> work based on RFC 5990.
> >
> > One idea how (modelled on ECDH-ES, as operation of KEMs is
very similar
> > to ECDH-ES):
> >
> > - Add new alg values KEM+{A{128,192,256}KW,HKDF-{256,512}},
mirroring
> > the ECDH-ES ones.
> > - Add new new header algorithm parameter "encapsulated
ciphertext"
> > (bstr) that carries the KEM ciphertext.
> > - Sender procedure:
> > - Select the public key to encrypt to.
> > - Apply the KEM encapsulate operation to the public key.
> > - Use the encapsulate secret output as input for key
derivation, just
> > like in ECDH-ES.
> > - Write the encapsulate ciphertext output into the
"encapsulated
> > ciphertext" header algorithm parameter.
> > - Receiver procedure:
> > - Retretive the private key to use.
> > - Read the ciphertext input from the "encapsulated
ciphertext" header
> > algorithm parameter.
> > - Apply the KEM decapsulate operation to the private key and
the
> > ciphertext. If decapsulate fails, fail.
> > - Use the decapsulate secret output as input for key
derivation, just
> > like in ECDH-ES.
> >
> >
> > A word of cauntion: Altough it might seem that the
"encapsulated
> > ciphertext" header can be reused for HPKE, there is a subtle
issue:
> > This mechanism can not trivially support compressing the
ciphertext. So
> > reusing it would require HPKE to define compact NIST curves,
so COSE
> > could just forget about key compression.
>
> If you are talking about ECC Point Compression, I agree that
COSE should ignore it. For a very long time, the patent kept many implementations
from supporting it. Now that patent has expired, but the engineering effort to
add support for ECC Point Compression is significant, and everyone will have to be
prepared to encounter implementations that are not yet prepared to handle
compression. The savings of 32 bytes does not seem worth the transition pain.
>
> Russ
>
> _______________________________________________
> COSE mailing list
> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> https://www.ietf.org/mailman/listinfo/cose
<https://www.ietf.org/mailman/listinfo/cose> <https://www.ietf.org/mailman/listinfo/cose
<https://www.ietf.org/mailman/listinfo/cose>>____
>
>
> ____
>
> __ __
>
> -- ____
>
> *ORIE STEELE*____
>
> Chief Technical Officer____
>
> www.transmute.industries <http://www.transmute.industries
<http://www.transmute.industries>>____
>
> __ __
>
> <https://www.transmute.industries/
<https://www.transmute.industries/>>____
>
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries <https://www.transmute.industries>>
>
> _______________________________________________
> COSE mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/cose
<https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________
COSE mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
<https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
