[Cscwg-public] CSCWG Minutes of April 8 2021 call
Dean Coclin
dean.coclin at digicert.com
Mon Apr 19 13:03:58 UTC 2021
FINAL MINUTES OF SUBJECT CALL
Role Call
- Adriano Santoni
- Andrea Holland
- Atsushi Inaba
- Bruce Morton
- Corey Bonnell
- Dean Coclin
- Daniela Hood
- Ian McMillan
- Inigo Barreira
- Tim Hollebeek
- Tomas Gustavsson
- Sebastian Schulz
Anti-Trust Statement is read
Doug Beattie joins later
Daniela makes an Announcement on behalf of GoDaddy:
- Starting June 1st GoDaddy will no longer Code Signing
certificates
- GoDaddy will retire from the CA/B Forum Working Group
- No new certificates can be issued, no rekeying will be
possible
Thomas Zermeno joins later
Dimitris Zacharopoulos joins later
Chris Kemmerer joins later
Intel Membership
- Will NOT be joining as certificate consumer now
- Wil join as interested party only for now, on invite-only
basis
"Clean-up" items:
- Combine ballot for "cleaning up BR" with pending ballot?
- General Agreement is tending to "NO", have a separate
ballot
- Bruce Morton to hold a small a separate small meeting to identify items
for clean-up ballot, with the below
- Tim
- Corey
- Ian
- Bruce
Dedicated Roots for Code Signing:
- What should be the scope of a dedicated Code Signing Root?
- Bruce: Scope being everything that's addressed by CS BRs
- Ian: From MS perspective, this seems like a favorable
approach
- Bruce: Going down path of Dedicated Root for Code Signing
- Test certificates are a concern, as they
are normally addressed by TLS
- Dimitris: Appendix C wasn't meant to be in CS BR.
Requirement should be to create test CS certs
- Bruce: Document is inappropriately calling out SSL BRs,
there weren't any issues yet
- Dimitris: CAs should be mandated to maintain an
expired/revoked/valid Code Signing certificate
- No agreement from the audience on the
above
- Doug: Should this also be for timestamps?
- Dimitris, Tim: Testing should be more the responsibility
of the CAs
- Corey: Requirement for maintaining the test service isn't
per Root
- Dimitris: Do CAs really need to maintain their own TSA?
- Ian: From MS side, that is not required
- CS BRs only require a CA to offer a TSA,
not that it's used together with the certs of that CA
- In reality, TSA and Code Signing
signatures are often mix & match
- Doug: Why do CAs even have to maintain
test sites then?
- Bruce: CAs SHOULD maintain test sites, as
Oracle requires that (Dimitris confirms that from recent experience)
- Ian: Indeed shouldn't be a MUST
requirement for now
- Bruce and Dimitris to address this
- Daniela has to leave the call
Presentation from Tomas Gustavsson:
"Common Criteria Re-Mystified"
- CC Profiles, FIPS certification and audit standards are often
misinterpreted by customers
- Common Criteria Recognition Arrangement (CCRA)
- Menat to allow international recognition of products
- Issued certificates and security targets are available online
- Security target: Define target of evaluation, claims performance to
protection profile
- protection profile: document created by user community
which identifies security devices
- Certification without protection profile is pretty much
useless
- Assurance levels (Evaluation assurance levels)
- EALS 1-6 represent "level of effort"
- non-EAL collaborative protection profile (cPP) does not
specify a EAL level, but rather specifies intended usage
- EU Cyber Security Act: Basic, Substantial and High -
correlating with the associated risk of using service or product
- Different requirements of certifications in different areas
- SOG-IS in EU
- NIAP in US
- Forces vendors into multiple certifications
- writing requirements
- strong recommendation to specify protection profile
- eIDAS, FIPS 140-2 L2 or L3
- Public procurement may refer to eIDAS,
Common Criteria, FIPS
- Audits may also attempt to meet
requirements
- What's practical?
- Currently many different modules are available
- FIPS or Common Criteria seems to prevent shady/homegrown
certifications
- Tim: Both FIPS and CC are very dependent on process and
documentation
- CC may be "misused": Broad/invalid requirements, vendor lock-out and
lock-in, vulnerabilities in "certified versions", audit inconsistencies
- FIPS doesn't always clarify which tools are FIPS certified, no guarantee
FIPS mode is enabled, auditor mileage may vary
- Dimitris: Better to have a certified device than "just
anything"
- Relevant to Code Signing: Good randomness
for the key generation and key protection
- Tim: Many standards only refer to CC or FIPS to ensure key
protection
- Adriano: Requirements for certifications aren't always
clear (FIPS does that best, being holistic for all components of a hardware
device)
- Tim: FIPS also only covers the crypto module
- Dimitris: relevant controls are covered by evaluation of
the crypto module
- Tim: Neither FIPS nor CC were meant to focus on key
management evaluation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210419/57ba3daa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CABForum-CSCWG-Common-Criteria-TomasG-8april2021.pdf
Type: application/pdf
Size: 647309 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210419/57ba3daa/attachment-0001.pdf>
-------------- 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/20210419/57ba3daa/attachment-0001.p7s>
More information about the Cscwg-public
mailing list