Bug 27471 - Provide even more informative text over key wrapping?

[mwatson2]

Bug 27471 from Bugzilla:

Just noting that I removed the following pre-CR from Section 14, as we have I believe resolved that we cannot address execution environment level issues in this spec after very long debate. That being said, informative text that clarifies that unwrapping unextractable trees are hard to guarantee without special treatment that is not to be normatively expected from the text (but could be provided by implementations in theory) might be useful. I also removed the reference from the example.

Or we could just keep the remark deleted.

REMOVED:

Editorial note:

ISSUE-35:

          The specification for wrapKey/unwrapKey does not specify how authors that do not trust  the execution environment may indicate required attributes for keys that are unwrapped. An example is unwrapping a key with a non-extractable key, marking  the newly unwrapped key as non extractable, and then further indicating that all keys unwrapped with the newly unwrapped key are also non-ex

[hhalpin]

I do think we should note the unusual lack of guarantees around unwrapping wrapped keys, as otherwise developers may shot themselves in foot as pointed out by Graham Steel etc. earlier. Is this about right? "Wrapped keys are exported and so only extractable keys can be wrapped. Thus, unwrapped key material is extractable and it not guaranteed that usages for a key have been preserved after the key have been wrapped."

[hhalpin]

For the export, it has extractable, but not for unwrapped. Could you hand a key to the test-suite to make sure you can unwrap a private key and maintain its un-extractability?

[mwatson2]

I'll make a proposal.

[mwatson2]

Please review PR #134.

This issue is that a JWK marked non-extractable cannot be created by the wrapKey method, because only extractable keys can be wrapped.

However, JWKs marked non-extractable that are created elsewhere can be unwrapped.

[ericroman920]

The note added in PR #134 LGTM.

That said, I don't think this behavior was ambiguous prior to the comment.