[Cscwg-public] Final minutes of CSCWG November 4, 2021

[Dean Coclin]

Here are the final minutes of the subject call.

 

Code Signing Workgroup Minutes 2021-11-04

Attendees:
Dean Coclin
Inigo Barreira
Ian McMillan
Tim Crawford
Chris Kemmerer
Bruce Morton
Ben Wilson
Atsushi Inaba
Martijn Katerbarg
Andrea Holland
Michael Sykes
Dimitris Zacharopoulo
Joanna Fox
Corey Bonnell
Tim Hollebeek
Janet Hines
Sebastian Schulz
Tomas Gustavsson

Minute Taker: Martijn

Anti-Trust statement
Dean read the anti-trust statement

Previous Minutes
Minutes from October 13th and October 21st are approved. Dean will send them
out to the public list

SC-50 - Remove the requirements of 4.1.1. 
Bruce: SC50 In the Server Certificate working group s a ballot where they
would change 4.1.1 to say "No Stipulation". Do we care about this or not,
and do we want to add any additional information here. An email was sent out
about this on the 1st of November.

Basically our CSC BR call up a specific version of the BR's due to which it
will not impact us. Now the question is if we want this to impact us, do we
just delete it?

Tim: No we just handle it the same way we handle the process to stay in sync
with BR updates. Next time we review we can just update the version number.
We will need to review the text when we do that

Bruce: In two weeks that ballot will be approved or not. After that we can
take steps to see if we need to change anything.

Tim: Are we going to review every time they pass ballots now?

Bruce: I think we should do that. Sometimes it makes sense to have a
different process but CA's don't like having different processes for
different certificate types when they don't have to. 

To be kept on the agenda for the next meeting

 

Ballot status on ballots 11 and 12

Bruce provided an update on both:

*	CSC-11 has gone though IPR review and is now complete. The version
of the CSC BR document has been sent out and published.
*	CSC-12 is now out for IPS review running through December 3rd 2021.

 

CSC-6 Subscriber key protection

*	Ian has sent out a draft on November 3rd based on CS BRs version
2.5. If needed a redline based on 2.6 can be created and sent out. All
changes are centered around section 16.3
*	A few changes were received from Bruce regarding signing services
which was mainly cleanup items in terms of EV vs non-EV.
*	EV references and stipulation date removed from 16.2
*	Short discussion on the required FIPS level ensued: 

*	Corey: In 16.2 we're specifying FIPS level 2, which with current
wording would prohibit higher levels. Don't we want this to say "Meets or
Exceeds" or "At Least"?
*	Ian: Yes indeed. This needs to be updated. 
*	Dimitris:  From 16.3 we removed the equivelant part?
*	Ian: Yes. 
*	Dimitris: But we keep it in the signing services
*	Ian: Is it? We should get rid of that too
*	Dimitris: So we only recognize FIPS and Common Criteria (CC)?
*	Ian: Correct

*	Subsection 16.3.1 was added. We're creating a common bar for all CS
certs and how keys are generated and protected.
*	TPM and software protected keys are no longer supported
*	Subscriber needs to host a hardware crypto module that meets the
specified requirements, or a cloud based key generation protection solution
that meets those requirements and is configured in a way to log all access
operation and configuration changes on the resource securing that private
key.
*	Ian: One thing that has come up for discussion around MS is the
increasing popularity of confidential computing mechanisms such as SGX
Enclaves and other competitive solutions with none of them meeting FIPS
compliance or certification as far as we are aware. In the future I can see
subscribers wanting to leverage these. I don't want to say no to something
new, but I don't believe we need it for now.
*	Private Key Verification was for EV only previously, now for all. We
also changed that a CA can now ship with or without a preinstalled key pair.
Previously this was only with a preinstalled key pair. This way subscribers
can generate their own keys on it.
*	A discussion is started on key verification:             

*	Sebastian: Could we have this say that CA makes sure the appropriate
module is received. I want to keep it more open that the subscriber can
receive the token a different way for example by a third party contractor.
*	Inigo: In fact sometimes users buy their own token.
*	Dimitris: If you are delegating this to a third party that is part
of your audit, I don't think we need a different language.
*	Sebastian: Yes, making the requirements that the subscriber must
receive a module, leaves to interpretation and have the CA ship it directly,
or have a hardware vendor or third party do that.
*	Tim: Is the CA able to make sure that the subscriber received the
token? The CA might ship it, but it might not get there.
*	Dimitris: I actually like the original text. The original text makes
sense, the new text, it doesn't really matter. The subscriber can go buy
their own module from the local store. For preinstalled keys, yes they must
ship it, but without preinstalled keys, the subscriber should be able to buy
their own. I think we should separate the 2. 
*	Bruce: Yes we should indeed. Preinstalled key is 1 item.  But how do
we verify when it's not preinstalled.
*	Dimitris: Any of the other items, such as an Audit verifying they
generated the key on the module.
*	The wording is discussed further, there being a strong favour for
key attestation to be used. Ian will make adjustments to the suggested text
for the ballot.

*	If a CA comes up with new means they shall publish it in their CPS
and they must propose this to the CA/B forum within 6 months. Dimitris adds
that we should have that as item 7, Any other method

CS BR Format Change 
Corey went through the CS BR's and did a section by section comparison with
the TLS BR's. It looks mostly consistent. The next step will have to be a
review to see there haven't been made any mistakes and then get it up for a
vote.

Other Business
None

Next Meeting
November 18th

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211118/77c79b24/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211118/77c79b24/attachment-0001.p7s>