ISSUE-35 - Wrap/Unwrap - Why JOSE?

Out of curiosity when reviewing wrap/unwrap, what technical reasons
are there to require the format be JOSE?

To put it differently, if it is to be implemented, why can it not be
treated simply as a specialized form of export+encrypt/decrypt+import,
where, just like export/import, it takes a key format specifier.

Recall that we have the key formats "raw", "pkcs8", "spki", and "jwk".

The current wrap/unwrap proposal can ONLY be used with JWKs, which
creates a divergence from the support for import/export, which
supports more than just JWK.

Was this an arbitrary design decision, or are there some set of
technical requirements? It seems like the JOSE support (including
transliteration of JOSE algorithms, params, SPIs, etc) can all be
handled via polyfill, and that a simple, composed,
"export-but-then-encrypt" or "decrypt-and-then-import" is more robust
and useful.

For example, the current proposal of wrap/unwrap would effectively
prevent any security benefits from being realized from applications
which use PKCS#11, as they make use of PKCS#8 ( see
http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-30m1-d7.pdf ,
Section 6.5 ). Likewise, CNG equally supports PKCS#8 ( see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa376263(v=vs.85).aspx
).

This seems to address at least one criticism, and seems like it would
greatly reduce the testing overhead.

The question is - will it work, and if not, why not?

Received on Friday, 26 April 2013 21:50:47 UTC