[Cscwg-public] Final Minutes of CSCWG meeting Feb 11, 2021

[Dean Coclin]

Here are the final minutes of the subject call:

 

1.	Attendees: Dean Coclin, Bruce Morton, Atsushi Inaba, Corey Bonnell,
Daniella Hood, Ian McMillan, Jeff Ward, Karthik Ramasamy, Karina Sirota,
Sebastian Schulz, Tim Crawford, Tomas Gustavsson
2.	Minute takers: Minutes takers were assigned to future meetings. Note
that Atsushi will not have to take minutes as he is working in the middle of
the night. Minute takers through May 2021 are:

*	Feb 11: Bruce
*	Feb 25: Daniela
*	March 11: Corey
*	March 25: Ian
*	April 8: Karthik
*	April 22: Sebastian
*	May 6: Tim C
*	May 20: Tomas

3.	AntiTrust statement was read by Dean
4.	Minutes from prior call: Although it was suggested that the minutes
from 28 January 2021 did not have enough detail, the meeting was not
recorded so there are issues with updating the minutes. The minutes for 28
January 2021 meeting were approved and will be sent to public list.
5.	Ballot Status: CSCWG-7 has been approved and is now in IPR review
until 5 March 2021. 
6.	Pandoc versions: It was suggested that the document should first be
migrated to RFC 3647 format, then moved into the new pandoc version
software. The Infrastructure group will help us with this formatting.
7.	OCSP in timestamping certs: From Dimitris email, where it was asked
"I would like to ask for Members to consider requiring either CRL or OCSP
information to be required in end-entity certificates used for
Time-stamping. The rationale is that Time-stamping Certificates are very few
compared to other end-entity certificates and CRLs should be considered
sufficient because their size is not significant." Corey had stated that
Microsoft requirements state that CRL and OCSP is required for end entity
certificates. Dimitris had thought that TSA certificates were CA
certificates, so the OCSP requirement did not apply. Ian needs to sync with
Microsoft internal personnel before saying if we can have an exception for
TSA certificates. There were follow on discussion about TSA certificate
validity period which is allowed to be 135 months, which allows a signature
to be verified for a long time. Note that the key must be updated every 15
months which helps protect compromise. There was other discussion that TSA
is open to the Internet with no access control or authentication to use,
which allows anyone in the world to get one or many time-stamps. It was
decided that protection of the TSA to have proper time is paramount. Ian
wants to know whether to remove OCSP requirement or reduce the TSA
certificate validity period. Ian will get back to discuss time-stamp
certificate requirements which will also address the OCSP question.
8.	Subscriber Key Protection: Ian took feedback and revamped to state
"FIPS-140 Level 2 or CC EAL 4+ based on CEN PP EN 418 221-5." Tomas stated
that the common criteria is very confusing, so the reference is confusing.
Need to make sure that we say the a crypto module needs to EAL 4+. Tomas is
volunteering for he and maybe some other to discuss this topic on a future
meeting. There is also issue for how to validate that the subscriber is
using a crypto module. Ian added "and with compliance being confirmed by
means of an audit on the attestation records received by the CA from the
Subscriber to accepting the terms of the subscriber agreement." It was
suggested that the subscriber should respond to accept the terms and provide
the make/model of the HSM. There could be 3 options: 1) subscriber accept
the terms, 2) subscriber provide evidence, or 3) third party provide
evidence. The subscriber could provide make/model or use a public-cloud
which meets requirements. How do we confirm that the public-cloud meets the
requirements? Public-cloud states what they meet, so you need to make sure
they use the right service. Are there issues with unknown public-cloud? Ian
is confident that the public-cloud disclosure is correct. There will be
reuse requirements as customers will want to issue many certificates on one
HSM. Have not found an answer for an independent confirmation from a
manufacturer or service. 
9.	High Risk Requests: Ian talked to Reversing Labs. They have been
active in researching code signing and CA abuse. They are interested to
share their information and possibly make a community platform to share
data. Group is in favor of having Reversing Labs present at the 25 February
meeting. Ian also stated that in CSBR 11.5,  we should remove High Risk
Region of Concern and call a high risk applicant 1) a victim of a take-over
attack or 2) identity rejected for some reason, such as failed validation.
How can we allow a company to categorize themselves as high risk, then
something else has to be done? This would require a central or common data
store. This is already a problem as the current high risk will only be for
one CA and not all.
10.	Status of suitable tokens to meet June reqts: We do not have a list
of tokens that support 3072/4096 RSA and are certified. Is SafeNet 5110CC
certified? There is a CC portal to confirm compliance; however, sometimes
there are issues with the name. Agreed to use the list to communicate.
11.	Next Meeting Feb 25th , Daniela will be the note taker

 

 

Bruce Morton

CSWG Vice Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210225/a8a9547c/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/20210225/a8a9547c/attachment-0001.p7s>