-
Notifications
You must be signed in to change notification settings - Fork 14
MeetingMinutes20241106
Bob Relyea edited this page Mar 5, 2025
·
1 revision
- Roll call taken by Bob R, quorum achieved.
- Valerie F took minutes.
- Attendance: Robert Relyea, Valerie Fenwick, Darren Johnson, Jonathan Shultze-Hewett, Scott Marshall, Tony Cox, Dieter Bong, Simo Sorce
- Roll call
- Review / approval of the agenda
- Approve Minutes (October 23, 2024)
- PKCS#11 v3.2
- Work Items
- Action Items
- Public Comments Items
- PKCS#11 V3.0 Errata
- New Business
- Next Meeting
- Call for late arrivals
- Adjourn
- Motion: That the agenda for this meeting be approved.
- Moved: Jonathan. Seconded: Darren. No objections, abstentions or comments. Agenda approved.
- Motion: That the minutes posted for October23, 2024 be approved.
- Moved: Simo. Seconded: Darren. No comments. No abstentions. No objections. Minutes approved.
- Items tracked in Wiki
- Item 21: There has been a lot of discussion on the list.
- Open questions on mechanisms and parameters, if someone did manage to implement then they will be deprecated.
- Bob noted the mechs will still be in the header, and will be removed (but not quickly, based on past experience).
- Simo is concerned with remaining existing implementations.
- Bob is not seeing 2 definitions in the headerfile, seems maybe the conflicts are just in the spec?
- Dieter noted there is other confusion of TLS 1.2 referencing a SSL3 structure (Bob believes the structure name changed, but not what it did).
- Dieter will take Simo's proposal, double check against the headerfiles (which structures/names already exist) and keep them as they are in the headerfiles. Not adding the 1.2, but adding the TLS 1.2 for mechanisms.
- Open questions on mechanisms and parameters, if someone did manage to implement then they will be deprecated.
- ML-DSA and similar (See Simo's email to listserv)
- Concerns about the name seed and CKA_SEED discussed
- Do we need definitions to cover these new key types? NIST defines how to encode as a byte array, IETF will have an ASNI format. Will we need a structure? Typically IETF would define a structure (though not always)
- Is there enough in the spec to describe how to format? Concerns with hardware tokens.
- The private key will not have the seed, and it cannot be computed backward.
- Could we add another attribute called seed? You will know if you have it or not, but it may not be the right representation for the public.
- Some people just want to store the seed and regenerate the private key on first use.
- Could we say this is seed or this value? End with the seed? Would be up to application to set the field.
- RSA is similar, we have a dedicated attribute for each key component to avoid any confusion with RSA. Though since RSA, we have not done the same thing.
- Same issue will apply to signing keys.
- IETF is also looking at this. There is some pseudocode that is confusing, expecting conformance and FIPS guidance to come in the near future.
- Bob will make a proposal for adding a seed parameter to ML-KEM and ML-DSA, but not to SLH-DSA keys, where it is not necessary because the private key already includes the seed as part of the standard definition.
- Header files
- Note from Bob on how to get header files:
- [rrelyea@localhost]$ pwd
- Note from Bob on how to get header files:
- [rrelyea@localhost]$ git remote -v
- also available as https://github.com/oasis-tcs/pkcs11/tree/master/published/3-01
- Email from: Robert Künnemann (shared by Darren Johnson)
- Outstanding action: Valerie to add the substantive changes to 3.3 work item list.
- Pending Jira ticket/action.
- None.
- Simo moved to set next meeting for Nov 20, 2024. Seconded: Darren. No objections, abstentions, or comments. Meeting date set.
- None.
- Motion: That the meeting be adjourned.
- Moved: Darren. Seconded: Dieter. No objections, abstentions, or comments. Meeting adjourned.
- Meeting Adjourned 1:59 PM PT.