These values are now included in the -37 drafts, at these locations:
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-37#appendix-A.2.1
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-37#appendix-A.1.3
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-37#appendix-A.2.3

                                                                -- Mike

From: Mike Jones
Sent: Wednesday, November 19, 2014 11:10 AM
To: [email protected]
Cc: 'Alok Menghrajani'
Subject: RE: comment on 
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#appendix-A.1.3

Given the WebCrypto decision to not import RSA private keys unless the CRT 
parameters are also present, I think it makes sense to include these parameter 
values (p, q, dp, dq, qi) in the examples.

The places these values would be added are:
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36#appendix-A.2.1
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#appendix-A.1.3
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#appendix-A.2.3

I’ll plan to do this in the next drafts unless I hear objections.

                                                                -- Mike

From: Alok Menghrajani [mailto:[email protected]]
Sent: Wednesday, November 19, 2014 10:32 AM
To: Mike Jones
Subject: comment on 
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#appendix-A.1.3

Hello Mike,

I am working on a piece of javascript code which uses the web crypto api and 
jwe. When writing some unittests, I noticed that the example JWK in 
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36, appendix 
A.1.3 contains a "d" parameter (this is also the case with some of the other 
examples).

On one hand, the example mentions "recipient's public key" and only encrypts 
data, so I think the JWK should not have a "d" parameter.

On the other hand, it might make sense to have the private key to help anyone 
who would want to decrypt the example's cipher text.

It turns out that the current browser crypto API is pretty unfriendly: it won't 
import the example's JWK key as a public key unless the "d" parameter is 
omitted and it won't import the JWK as a private key unless the remaining key 
parameters are there; the API doesn't compute them for you.

Do you agree the "d" parameter should be removed or do you think the remaining 
key parameters should be included?

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

Reply via email to