Subject: Re: [jose] PKCS #11 for JWK

From: Simo Sorce <[email-masked]>
Date: Sat, 01 Jul 2017 04:00:51 -0400

On Fri, 2017-06-30 at 17:33 -0400, Nathaniel McCallum wrote:
> I have prepared an initial stab at a draft for offloading JWK private
> key data to PKCS #11.
> 
> You can find the document here:
>    https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt
> 
> Thanks for your consideration!

It's a nice start.
A few immediate comments:

   JWKs that wish to offload their private key material using PKCS #11
   will provide a JSON property named "p11" instead of the private key
   material.

JWKs are inanimate objects, hard to have them have any wish :-)

I would say:
"Users that wish to offload their JWKs private key material to an HSM
..."

Later on you talk about performance penalty and say:

   Implementations SHOULD perform public
   key operations, such as asymmetric signature verification or
   asymmetric encryption, without using PKCS #11

I think this should be at most a MAY. If I wanted to be more pedantic I
would say you should take in consideration there may be PKCS#11 modules
that are already smart enough to implement such functions in software
so that they do not incur in performance penalties, so the whole this
would have to be wrapped in something like:
 "If the PKCS#11 implementation perform public key operation in hardare
that may result in poor performance then implementations MAY perfrom
public ..."

Curious to see example JWKs in the appendix.

HTH,
Simo.

---

From: Nathaniel McCallum <[email-masked]>
Date: Sat, 1 Jul 2017 08:42:22 -0400

> JWKs are inanimate objects, hard to have them have any wish :-)

You've never heard of personification? ;) You're right. I'll change it.

> that may result in poor performance then implementations MAY perfrom

If we downgrade this recommendation, then we probably need to discuss
how implementations would correlate public key and private key object
URIs. That is, "p11" refers only to the private key. For public key
crypto operations, we need a URI that refers to the public key. Thus,
we would need a way to either:

1. Store the public key URI.
2. Transmute the private key URI into a public key URI implicitly.

I'm not sure we can do #2. Sometimes keys are differentiated by id=.
Sometimes they are differentiated by object=. Thus we can't do a
single s/private/public/ on type= and expect things to work.
Therefore, I expect #1 is our only option.

Thoughts?

> Curious to see example JWKs in the appendix.

Will do!

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 1 Jul 2017 21:08:24 +0200

Looks good!

+1 to have examples included.

Question: When I parse a JWK with a "p11" parameter, should the p11 URI
syntax be validated? What constitutes a syntactically valid p11 URI?

---

From: Nathaniel McCallum <[email-masked]>
Date: Sat, 1 Jul 2017 15:16:24 -0400

Section 3 states:

'The "p11" property MUST contain a valid PKCS #11 URI [RFC7517] that
points to a private key object (that is, type=private).'

As I understand this sentence, the "p11" URI should be validated
according to RFC 7517 with the additional constraint that it must have
type=private.

---

From: Nathaniel McCallum <[email-masked]>
Date: Sat, 1 Jul 2017 15:17:42 -0400

(That does appear to be a typo. The RFC should be 7512.)

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 1 Jul 2017 22:23:14 +0200

Thanks, this answered my question.

Now, if the p11 URI must point to a private key object, shouldn't "type"
in section 4 be declared REQUIRED?

BTW, did you also consider using the p11 URIs for JWKs of type "oct"?

---

From: Nathaniel McCallum <[email-masked]>
Date: Sat, 1 Jul 2017 16:43:48 -0400

> in section 4 be declared REQUIRED?

Probably so. I think we need to answer the question about public key
URI (see other emails in this thread) first. But, yes, I agree.

> BTW, did you also consider using the p11 URIs for JWKs of type "oct"?

Yes, the document does this implicitly. Section 3 states: "Private key
material is defined by the Parameter Information Class of Section
8.1.1 of RFC 7517 [RFC7517]."

This section defines "k" as private key material for JWKs of type
"oct". It should probably be spelled out in the actual draft that
symmetric keys do not have public key material. The draft should
probably also make explicit that this is usable for "oct" JWKs. This
would help with clarity.

>From an implementation perspective, symmetric keys are probably most
useful for the key wrap algorithms since we probably don't want to
offload full data encryption (for performance reasons).

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 2 Jul 2017 16:49:34 +0300

> we would need a way to either:

One another thing to note is that some pieces of codebases can easily
work with external private keys but not external public keys.

That is, those pieces of code expect to work with private keys using
signer interface (which can easily encapsulate PKCS#11 operation), but
deal with public keys directly (so PKCS#11 there would be a major
change). Some codebases even expect to be able to directly load the
public key parts.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 03 Jul 2017 09:42:59 +0200

> 2. Transmute the private key URI into a public key URI implicitly.

PKCS#11 mentions the following:
"The CKA_ID attribute is intended as a means of distinguishing multiple
public-key/private-key pairs held by the same subject (whether stored
in the same token or not)."

That field is also expected to match a certificate's subject key
identifier field:
"Note that with the version 3 extensions to X.509 certificates, the key
identifier may be carried in the certificate. It is
intended that the CKA_ID value be identical to the key identifier in
such a certificate extension, although this will not be enforced by
Cryptoki."

Thus you can certainly rely on that, and if you have control on how the
public/private key pair is generated, you can require this field to
adhere to the above properties.

regards,
Nikos

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 5 Jul 2017 09:04:57 -0400

> that may result in poor performance then implementations MAY perfrom

I did some reflection on this over the long weekend. If we wanted to
support offloading public key operations to PKCS #11, we'd need to
have a "p11pub" JWK property which defines the URI to the public key
to perform the operation on. This duplicates the existing public key
information in the JWK.

We could allow three modes:
1. pubkey-only; no PKCS #11
2. URI-only; PKCS #11
3. both; optional PKCS #11

In mode #3, there is a possibility for public key mismatch. However,
no attacks exist which don't also exist for mode #1.

My worry is that this is a lot of complexity for minimal gain. JOSE
implementations already have to support #1. At best, mode #2 is going
to be as fast as #1. I just don't see any compelling reason to support
public key URIs. Do you?

As an aside, I do see value in exporting X.509 material from
certificate URIs and placing them in the already established JWK
parameters. However, I do not think standardization is required to
support this; implementations can do this in a compatible way without
any new RFCs once they have "p11".

---

From: Simo Sorce <[email-masked]>
Date: Wed, 05 Jul 2017 10:26:27 -0400

> any new RFCs once they have "p11".

I do not think we need to explicitly add a p11public parameter.
As Nikos noted (unless I misunderstood) implementations can infer the
public key from the private one. So implementations may chose to use
the corresponding public key via pkcs11 if they so desire. Otherwise
they can use the current stuff which is just fine.

Simo.

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 5 Jul 2017 10:45:54 -0400

I believe that this will work in most, but not all, situations. The
correlation of keys using the id= parameter is only a recommendation.

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 5 Jul 2017 15:01:03 -0400

I have updated the draft from the comments everyone has provided.
However, document uploads are currently locked due to the IETF
meeting, so I have attached the document here. Your feedback is
greatly appreciated.

---

From: Simo Sorce <[email-masked]>
Date: Thu, 06 Jul 2017 03:57:48 -0400

> correlation of keys using the id= parameter is only a recommendation.

I think it is ok to rely on the recommendation and fail otherwise, all
JWK libraries must be prepared to handle public keys on their own
anyway, so they can always just do that.

Simo.

> > > > so that they do not incur in performance penalties, so the
> > > > whole
> > > > this

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 6 Jul 2017 23:07:12 +0200

Great!

The "k" parameter appears to be mandatory for "oct" JWKs. How can we
reconcile that with the p11 spec? Ideas?

https://tools.ietf.org/html/rfc7518#section-6.4.1

---

From: Jim Schaad <[email-masked]>
Date: Thu, 6 Jul 2017 14:49:58 -0700

This would require that this document update RFC 7518 to make one or the
other be present.

You probably want to have a general update of some type that says you either
have the 'p11' element or the private fields but not both for all key types.

Jim

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, July 6, 2017 2:07 PM
To: Nathaniel McCallum <[email-masked]>; [email-masked]
Cc: Nikos Mavrogiannopoulos <[email-masked]>; Daiki Ueno
<[email-masked]>; Sorce, Simo <[email-masked]>
Subject: Re: [jose] PKCS #11 for JWK

Great!

>>    https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 7 Jul 2017 09:05:38 +0200

> https://tools.ietf.org/html/rfc7518#section-6.4.1

It gets even more fun with OKP JWKs:

https://github.com/cyberphone/java-cfrg-spec

Anders

---

From: Simo Sorce <[email-masked]>
Date: Fri, 07 Jul 2017 05:56:46 -0400

> https://tools.ietf.org/html/rfc7518#section-6.4.1

I wonder if an empty value would be properly handled by implementations
or would cause them to leak information instead of encrypting it, or
worse fall over themselves.

Worst case we could define a new type "hwoct" ? Sounds a bit silly tho.

Simo.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Jul 2017 13:31:53 +0300

> It gets even more fun with OKP JWKs:

Actually from what I can gather, RSA and OKP require the private key
material for private keys. EC and OCT do not (at least I can't find
explicit language saying they have to).

So sounds like updating to RFC 7518 and RFC 8037 is in order.

(Of course, I don't think presently OKP keys can be used with PKCS#11,
but that is due to lack of specification, so it could change...)

-Ilari

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 7 Jul 2017 16:23:21 +0200

Regarding section 4 of the proposed -01 spec:

When dealing with "oct" JWKs, shouldn't the PKCS#11 URI type parameter
become "secret-key"?

Vladimir

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 7 Jul 2017 10:25:02 -0400

Yes. Thank you for correcting my oversight!

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 10 Jul 2017 08:02:58 +0200

On Wed, 2017-07-05 at 09:04 -0400, Nathaniel McCallum wrote:
> to be as fast as #1. I just don't see any compelling reason to
> support public key URIs. Do you?

As long as you have the tooling to extract that public key/cert from
the HSM, I can think of no reason using the HSM for public key
operations.

regards,
Nikos