OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY

On 6/4/2013 2:28 PM, Chris Zimman wrote:

I have some concerns with the concept of CKM_SEAL_KEY.  This seems like very token specific behavior,

I'm pretty sure that is by design.  By design, a key sealed with this mechanism is only guaranteed to be restorable (unsealed) to the token from which it originated.  I consciously avoided specifying  the actual cryptographic mechanism used to seal and the format of what was sealed and the format of the sealed blob for that reason.

and also, it violates CKA_NEVER_EXTRACTABLE without informing one that it’s been done.

Actually, no.  It takes a conscious effort to bypass this - the only way the normal controls are bypassed is if you use the CKA_GLOBAL seal key (defined in the other document).

  I’d want to get some guidance on if and how supporting this might affect FIPS 140 evaluations. 

This should be fine.  A number of devices already do this implicitly.  And we're doing a device that uses this concept to deal with storage.  I also refer you to several TPMs which support this and are FIPS140 certified.

In terms of CKM_SEAL_KEY, which algo does it use?  If I were implementing this, I’d want something that does enc + auth for example.

I'll add this guidance to the draft, but I won't specify the mechanism.  That's up to each and every token manufacturer to select.  (But CKA_AES_KEYWRAP_PAD might be a good choice... )  The main reason for avoiding specifying this is that various regulatory domains (e.g. countries) may have specific guidance on which types algorithms can be used for this purpose.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]