RE: Bug 24457 - AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long

I agree that this is definitely NOT normative text.

The only obvious place I can think of is in the generic wrapKey description
for placement.

I am neutral on the proposed text and it's inclusion in the document.  It is
not clear to me that it will help, but on the other hand I don't believe it
is harmful in anyway.

Jim



From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Friday, February 28, 2014 8:41 AM
To: public-webcrypto@w3.org
Subject: Bug 24457 - AES-KW can only wrap a JWK key if its serialization
happens to be 8*n bytes long

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24457

Alexey re-opened this bug with:
"A WebCrypto implementation can pad JWK with spaces for AES-KW, but the same
padding can destroy the ability to wrap with RSA-OAEP, because you can run
out of size limit. So, any padding should be conditional on which algorithm
will be used for encryption in a later step of wrapping algorithm.

I think that it would be appropriate to have normative text. But even if
it's simply a note, it should be:
1. Substantially more elaborate than suggested above.
2. Added as part of this bug (so it seems like the bug should remain open
until the note is added)."
I would suggest that any such note be non-normative:
- There has been strong objection to specifying our own padding scheme

- There is no _need_ for normative specification to ensure interoperability:
so long as the serialization is valid JSON, we are good.

A note (I am not sure where it would be) might look something like:
"Note: Some algorithms used for key wrapping place constraints on the
payload size. For example AES-KW requires the payload to be a multiple of 8
bytes in length and RSA-OAEP places a restriction on the length. For key
formats that offer flexibility in serialization of a given key (for exmaple
JWK), implementations may choose to adapt the serialization to the
constraints of the wrapping algorithm."
Comments ?
...Mark

Received on Friday, 28 February 2014 17:51:58 UTC