Re: [pkcs11] Proposal: Define CKA_JAVA_MIDP_SECURITY_DOMAIN constants

[Michael StJohns <msj@nthpermutation.com>]

On 6/26/2013 12:15 PM, Stef Walter wrote:
> On 24.06.2013 18:16, Michael StJohns wrote:
> > On 6/24/2013 12:11 PM, Stef Walter wrote:
> > > > > I don't have strong feelings on this, but if we're going to throw away
> > > > > the enum model, we should do it with eyes wide open.
> > > Fair enough, and that's why I posted this question last week. Nobody
> > > responded to that email.
> > Yup - sorry about that.  I had way too many things to look at. Finally
> > getting around to i.
> So what's the next step here, Mike? Nobody else seems to care but you
> and I. :D

Heh.  Just remember that silence doesn't necessarily mean a lack of 
interest.

For this, I'm loath to let this look like the OTP stuff, as I think that 
was done in error.  Part of the idea of this PKCS11 API is to be able to 
project it onto other languages besides C and it would be useful if 
fields that were should actually be considered as enums (or a fixed set 
of values) were typed that way.  Unfortunately, all we can do is use 
appropriate naming conventions.

Table 2 has "Data type or general constant" as the description of CK_.  
CK_OTP_XXX or CK_MIDP_XXX don't appear to be "general" constants in that 
meaning (unlike the other 5 you mentioned CK_FALSE etc).

> Should we just choose CKV_? That's the option that seems more broadly
> acceptable. In that case, will you make a proposal to update the OTP stuff?

So CKV_OTP_*, CKV_MIDP_* and CKV_CERTCAT_*?  Sure I can't talk you into 
CKCM_ and CKCC_?

To table 2 we add "CKV_" "General enumerations"?  (Or alternately, we 
add these two prefixes.)



The OTP stuff is a mess - It will require some surgery to fix the naming 
conventions.  But its mostly a set of synonyms and new typedefs.  Let's 
see if there's any interest - I think its editorial in nature.  I'm 
willing to provide the edits if there's interest. I think I'd probably 
try and grab CKE_ for otp (E for ephemeral) and use that for all of the 
sub enums.  So CKER_  CKEF_ and CKEP_ for requirements, format and OTP 
param type


For your proposals, you should define CK_MIDP_DOMAIN, 
CK_MIDP_DOMAIN_PTR, CK_CERTIFICATE_CATEGORY, CK_CERTIFICATE_CATEGORY_PTR 
and update the attribute typing for CKA_CERTIFICATE_CATEGORY (table 23) 
and CKA_JAVA_MIDP_SECURITY_DOMAIN (table 24) to point to those types. 
(One of the reasons I like CKCM_ et al is because for your description 
of those types you can just point to the appropriate prefix as being 
part of the type rather than doing an enumeration in multiple places).

> Stef