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] Proposal: Define CKA_JAVA_MIDP_SECURITY_DOMAIN constants

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).


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