Hi Tim,
thanks for providing the Profiles working draft. A quick review:
-
Note that CK_INTERFACES, CK_FUNCTION_LISTS, C_GetFunctionLists might change based on the discussion of my proposal. This also fixes the wrong section (see your comment on 3.3.2 no 4b)
-
In 3.3.2 and 3.6.2, it is not necessary to add item 5
âSupports the following objectsâ since
we already have item 3 with the same name. Thus, CKO_PROFILE can be added there.
-
In 3.5.2 no 6, shall it actually have the value CKP_EXTENDED_PROVIDER instead of CKP_BASELINE_PROVIDER? If not, remove no 6 since it is inherited from the baseline provider. If yes, can
it be integrated in or replace no 4? If not, it should be before no 4 so that both object items are close by.
-
Since all profile specifications usually contain data types, objects, functions, and mechanisms (even if it just says
ânone specifiedâ) we should data types
for authentication tokens and data types and functions for public certificates tokens just for consistency.
Thanks,
Daniel
From:
pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Tim Hudson
Sent: Mittwoch, 5. September 2018 10:30
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Groups - pkcs11-profiles-v3.0-wd01.docx uploaded
Submitter's message
Incorporated known updates - adjusted base profile for new functions and attributes; added publicly readable certificate profile (renamed Public Certificates Token profile)
Noted that the flag values for CKA_PROFILE_ID are not documented in the base specification (yet).
Noted missing CKP_PUBLIC_CERTIFICATES_TOKEN flag value (for the additional profile).
-- Tim Hudson