[Cscwg-public] Final minutes of CSCWG Call March 25, 2021
Dean Coclin
dean.coclin at digicert.com
Thu Apr 8 16:20:16 UTC 2021
Here are the final minutes of the subject call:
Meeting Date: 3/25/2021 09:00 AM
Participants:
* Dean Coclin
* Adriano Santoni
* Atsushi Inaba
* Bruce Morton
* Corey Bonnell
* Daniela Hood
* Inigo Barreira
* Tim Crawford
* Tim Hollebeek
* Ian McMillan
Notes:
* Anti-Trust Statement read by Dean
* Approval of prior meeting minutes (2/25 and 3/12)
o Approve meeting minutes from the past two meetings
* CSC-8 Ballot Discussions
o Ian summarized the state of the ballot and areas of discussion period's
feedback
o Tim H - CRL requirement not having the accuracy of the CRL requirement
being on Timestamp and Code Signing certificates
* We should state what is required for CRLs and prefer to get this aligned
with the BR requirements
* Goal to reduce ambiguity with what are the CRL requirements for each
layer
* End entities, and non-Self-Signed certs (sub Cas)
* Agreed to add this change to the next clean up ballot to clear the way to
get this ballot out with the key protection update needed to meet the 3072
key length date coming up on June 1, 2021
o Tim H/Corey - Appendix B with regards to AIA requirements specify root
CA previously and now say issuing CA, but this should never be the root CA.
The parent issuing CA URL should be there, but this extension must NOT be
included if the parent CA is the root CA.
* AIA should never download the root CA certificate, CTLs do this in the
platform.
* You do not download self-signed certificates
* Cross-signed roots are sub issuing CA of the root that signed it
(caveat to the point above regarding downloading self-signed certs
* Take this to the mailing list and the next ballot needs to clean this up,
and will combine with other clean up items Bruce has and the CRL specifics
o Tim H - in section 13.2.2 with regards to the Timestamp Certificate
Status #2 for OCSP status it should NOT say "Subordinate CA" but "Timestamp"
in the below sentence:
If the CA provides OCSP responses, the CA SHALL update information provided
via an OCSP response at least (i) every twelve months and (ii) within 24
hours after revoking a Subordinate CA Certificate.
o Ian - No confirmation on the Oracle Java SE behavior with timestamp
certificate validity being within the validity period at the time of
validation
* Bruce - believes Java SE does not respect timestamps on JAR signature
* Need to get confirmation from Oracle
* The pain/oddity with a 135 month certificate that is replaced every 15
months
* MS 1st party Timestamp certificates will continue to be 15 months at most
because this is a MAX validity
* Need to consider the language here with MAX validity or we can leave it
(CA can choose to limit it to any validity period less than 135 months)
* If we get the confirmation from Oracle we can change this to 15 months,
if not, leave it as is for now
o CSC-6 Key Protection - focus on how we support public cloud services
for a key generation and protection
* Number change by Bruce helps separate the two components of the
requirements: (1) key protection, (2) key protection verification
* Goal in key protection to remove the acceptance of software
protected keys and add cloud-based key protection solutions that meet the
crypto module requirements (FIPS 140-Level 2,
* Ian asked what is the common practice for subscriber keys being
generated by the subscribers or are they pre-generated
* Bruce and Tim H said the common practice is subscribers generate
keys, but not in the case of signing services (CA that provides a signing
service can generate the keys on behalf of the subscriber)
* Adriano asked if we can address the topic he raised on the mailing
list regarding single supplier issue and the interpretation of the
requirements for a crypto module's certification
o Adriano - Single supplier issue that meets the CC EAL 4+ requirement,
and the interpretation of the requirements for a crypto module's
certification
* Ask is if the group agrees with Tomas' interpretation of the ambiguity in
the wording of the requirement?
* Adriano's question is centered on if the programable interface or
applications leveraging the crypto module needs to be also certified? What
is the group's collective opinion.
* Tomas pointed out that the certification is on the crypto module
itself and that will satisfy this requirement.
* Dean points out we should make sure this is not ambiguous for
auditors like Tim Crawford
* Ian sees the specifics of the requirements is about the
certification of the crypto module
* Adriano would like this written with better clarity
* Tim H sees the current language of the requirement with Tomas'
interpretation is clear that the certification is required for the crypto
module (and we state that in the meeting notes)
* The evaluation of the software that is certified can be part of a
certification
* Devices on the market that have hardware crypto module that is
certified, but the applet/API that exposes the crypto operations may not be
included in the certification
* All modern HSMs have custom code options, and this code is not
able to tamper with the trust/security boundary of the crypto module that is
certified
* Ask for Adriano to provide better text suggestions to address the
ambiguity he sees in the current text
* The key protection change is part of the draft for CSC-6
* Ian not interested in moving the June 1, 2021 date for 3072 key lengths
on RSA
* How does the group address the lack of suppliers issue in terms of the
tokens with longer key lengths (is this our business to address this)?
* Timeline for a FIPS certification is still 18 months for suppliers
* This requirement has been out there since 2015 (this was a January
1, 2021 deadline originally)
* Signing Service and cloud-based key protection solutions are also
valid options for subscribers
* Competition should be the driver
o Back to the key protection change with cloud-based solution in CSC-6
* The group is okay with the current key protection language Ian proposed
* Second part on key protection verification is the harder part.
* Counter-signed CSRs with manufacture's certificates is extremely
rare
* Great solution, maybe the best means, but not broadly available
* No one knows why this is rare, and may be only because it is a
recent trend
* CA's shipping suitable hardware crypto module should state with or
without pre-installed keys
* Shipping without pre-installed keys is better option
* Need to have multiple options to help satisfy the requirements
* Suitable IT audit gives a lot of flexibility
* Tim Crawford never encounters this as an acceptable means to
satisfying the requirements
* Self-assertion is part of the subscriber agreement requirements
* Had to cut the discussion off that this point due to end of the meeting
hour, will continue this discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210408/39d88932/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/20210408/39d88932/attachment-0001.p7s>
More information about the Cscwg-public
mailing list