-
Notifications
You must be signed in to change notification settings - Fork 24
Meetingminutes Minutes09062021
Bob Relyea edited this page Mar 5, 2025
·
1 revision
- Roll call (Tony) - quorum achieved.
- Tony taking minutes.
- Attendance noted in KAVI
- Agenda
- Roll call
- Review / approval of the agenda
- Approve Minutes (May 26, 2021)
- PKCS#11 V3.1
- WD04
- IKE (extra text)
- Wiki & Actions Items Review (Closing off v3.1)
- Line by line review
- PKCS#11 v3.2
- FIPS indicator
- New Business
- Next meeting
- Call for late arrivals
- Adjourn
- Tim C moved, Hamish C seconded. No objections, comments or abstentions. Agenda approved.
- Minutes posted for May 26, 2021
- Greg S moved, Greg S seconded. No objections, comments or abstentions. Minutes approved.
- Tony C noted WD04 and matching markup had been uploaded. Thanks to Dieter and Daniel for handling much of the work.
- Daniel noted the extra text would be added shortly (per May 26 minutes)
- Tony C noted that now WD04 had been uploaded, the TC needed to review the content on the wiki. Requested members to perform review.
- Two items regarding the FIPS indicator - one can be tracked internally, the other related to how the indicator was to be exposed. Darren J pointed out that this could be handled by session info as an attribute on the object itself (rather than using a query).
- Jonathan S asked if the attribute was static or could be modified if the NIST spec changes and the key size is no longer covered.
- Bob R noted that this was more in line with key generation rather than in its usage. Session info is variable depending on where you are in the session.
- Hamish asked if the mech info flag was the desired path.
- Bob indicated that that both the session and the object had FIPS indicator. The proposal attribute to be queried to return the current FIPS state and a flag on a session to provide the FIPS state.
- Bob stated that modules MAY enforce FIPS rules. If Modules enforce all FIPS rules - they meet the spec and the indicator can be used all the time (in FIPS state). In practice things can be done on a FIPS module that aren't FIPS compliant, therefore the sessions aren't FIPS compatible. In this case, an application must have a path to determine its FIPS status. The aspects about how you handle the FIPS status at an application level are not in the spec as these are really development learnings.
- Tim noted that you can continue to have a global FIPS-2 static approach or move to the FIPS-3 approach, however the published FIPS-3 programming guidance raises more questions than it answers.
- Hamish described the nCipher approach for FIPS-2 > 3 handling
- Tim H asked how this would apply with an imported key (noted as FIPS-3) with no way to check that the status is actually valid.
- Tim H clarified key importation problem with compliance.
- Bob R indicated that the proposal specifies what can be done within the FIPS 140-3 spec. There is no guarantee that NIST won't insist that a given key must be checked to ensure it is compliant.
- Tim H suggested an indicator to note that the key is imported (and therefore not guaranteed as compliance)
- Bob R is willing to consider proposals on covering that (import vs generation)
- Bob R noted that by putting the indicator in the object (rather than session) it would cover single shot operations as well as covering a cascaded process can be covered.
- Tim H noted that current guidance states that unless you are making a global assertion, each step must be noted as compliant (or not). Tim gave an example where the key size is covered but the DRBG used to generate the key is outside the FIPS-3 limits, therefore the items need to be tracked independently.
- Bob R to revisit proposal and come back to the group.
- None
- Next meeting will be June 23, 2021.
- 0 noted
- Tim H moved. Daniel M seconded. No objections, comments or abstentions. Meeting adjourned.