On 6/5/2013 8:31 PM, Tim Hudson wrote:
Why do you have "
all pertinent key attributes" in the seal-key document? It needs
to be all attributes with no exceptions to be useful IMHO if the
intent is off-device storage that is application managed.
Actually, no. I stated it this way because occasionally, some of
the attributes are redundant to others, or aren't actually stored
internally as PKCS11 attributes. This was an attempt to not specify
implementation. Also, "pertinent" here means the attributes that
are specific to that type of object (e.g. CKA_PUBLIC_MODULUS is not
a pertinent attribute for an EC private key).
Why limit sealing to a SECRET_KEY only? Why a symmetric approach
only?
Why not define an actual output format? A requirement to protect
the integrity of the attributes?
You have done that for the certify output - in the global values
proposal - why not for seal
Because the certify may need to verified by something besides the
originating device, but the seal is designed specifically to prevent
that key from being loaded on any token other than the token from
which it was sealed. Really and truly the definition of an OPAQUE
object.
If there was an interop issue, I'd have defined a format. There
isn't.
As for why secret key only - again - this is designed specifically
to allow an export of key material from a device and reimport to
that self-same device. I can think of no case in which having the
wrapping key be an asymmetric key is useful in that scenario.
Would you care to suggest one?
With respect to the protection of the integrity of the attributes -
it is necessary. But that's sort of implicit in the statement:
The
unwrap
operation reverses the wrap operation and MUST produce exactly
the same
object as was wrapped.
X-NONE
X-NONE
But I can be more explicit here if necessary. I *really* don't care
how they do this - could be an embedded SHA, could be an integrity
protected wrap algorithm, could be a combination of an encryption
mode and an integrity mode. It really is a don't care for the
purposes of the spec.
This does not however solve the
export-from-one-device, import-to-another-device context which is
the other problem that these proposals I think are not discussing.
At this point I'm confused about which proposals you're reading.
This proposal is ONLY to deal with the ability to import and export
data that otherwise couldn't be imported or exported from the
token. The data CANNOT be re-imported to a token other than the
originating token and that is by design (and the main point of the
design).
What you want to do is supported for all CKA_EXTRACTABLE=true
objects for all other key wrapping mechanisms.
As for your proposal - please write it up and I'll give it the same
review treatment you're giving mine. I don't actually think it will
accomplish what I want to accomplish, but you haven't provided
enough rigorous detail for me to make a reasonable determination
either way.
Mike
