Re: [pkcs11] New Mechanisms subgroup Part 3 or 4, new AES

[Sven Gossel <sven.gossel@charismathics.com>]

All

I am not sure I am getting this right, but would also like to raise some concerns regarding the interoperability and exchangeability of products and take this discussion as an example. It appears to me that there has to be "a" defined way of doing stuff rather than multiple options. So I fully support Mike's statement.

One should not be able to claim being P11 compliant and then use functions that although defined in the standard create a de-facto lock into a customer. We are facing this on the token side on an almost daily base. 


Best regards

Sven Gossel
CEO charismathics inc.
cell: +1 (408) 607-3035

(sent while traveling)

On May 1, 2013, at 6:38 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:

> On 5/1/2013 11:01 AM, mark powers wrote:
>>> 
>>> I think that adding a mode simply because you don't want to move bits 
>>> around is probably a bad idea.
>> 
>> I believe there is value in being able to connect mechanisms mentioned 
>> in a spec to mechanisms supported
>> by PKCS11. Not everyone is going to dig deeper to figure out that 
>> mechanism X is the same as Y when
>> certain parameters are set. I'm obviously wearing "marketing" hat today.
> 
> The issue here is there are lots of mechanisms that use truncated hashes 
> or MACs.  Rather than put in possibly 100 new mechanisms, I'd much 
> rather generalize the mechanisms so that we can subsume all of those.
> 
> So instead of CKM_AES_XCBC_MAC_96 let's do CKM_AES_XCBC_MAC_GENERAL as 
> that seems to be the common approach.
> 
> In the same way, I'm thinking that it might be useful to define a 
> generic signature mechanism in which you specify separately the summary 
> (hash mechanism with padding) and the actual public key operation as 
> part of the mechanism info.  That would give a path for new hash/PK 
> combos without waiting for PKCS11 to act.
> 
> Mike
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>