[Cscwg-public] Approved Minutes of CSCWG Virtual F2F Meeting June 16, 2021

[Dean Coclin]

Here are the final minutes of the subject meeting:

 

Attendance: Dean Coclin, Atsushi Inaba, Bruce Morton, Dimitris
Zacharopoulos, Don Sheehy, Nick France, Paul van Brouwershaven, Thomas
Zermeno, Tim Hollebeek, Vijay Kumar, Eva van Steenberge, Tim Callan, Ian
McMillan, Sebastian Schulz, Clemens Wanko, Janet Hines, Andrea Holland,
Tadahiko Ito, Corey Bonnell, Chris Kemmerer 

Part 1: Minutes of prior meeting approved. 

Bruce led the discussion on the signing service. The slides are here: Code
Signing Service
<https://wiki.cabforum.org/_media/csbr_signing_service_v2.pdf>  The slides
cover most of the topics discussed in the meeting. Additional commentary is
below: 

Discussion about 2 factor authentication to a signing service. Suggested to
analyze all use cases before coming up with minimum authentication
requirements. Already some of this is in use in the EU. May not need to
reinvent the wheel. 

Discussion about allowing FIPS 140-2 Level 2, why not something more
stringent? Ian said it's challenging for activation and key export/import
(especially regarding Android). 

Different models of signing service discussed. It was suggested that a
rewrite of the signing services section would be more beneficial than trying
to improve the existing sections. All agreed. 

Bruce put up some discussion items about signing services (see slides).
Dimitris added that for the first bullet, it should say that the service
generates keys on behalf of the subscriber. 

Ian said we should not allow import of subscriber keys but allow transfer of
keys between services for protection purposes. Tim said he was aware of a
rule that states the keys can only be imported/exported if they are from the
same HSM world. 

Discussion about separating out the audit of a signing service. Certain
sections of the requirements come into play, especially if the CA is
operating the signing service. Dimitris said the signing service audit
requirements should be the same. Bruce suggested we review the audit
documents. 

Discussion about issuing certs to subscribers vs. signing services. Should
this be allowed? How to determine if a subscriber takes his cert and sets up
a signing service? Breach of subscriber agreement. Multi tenant
architectures discussed. 

Suggested to add multi-factor authentication for key activation. Agreed. 

Reviewed various signing service models (last slide) 

Looking at ways to move forward, a subcommittee was suggested to work on
signing services requirements. Volunteers include Bruce (head), Dimitris,
Tim H, Corey, Tomas, Ian, Nick F, Chris K. Tim suggested a larger block of
time to kick this off. A separate meeting will be setup to address. Bruce
will kick it off. June 24th at noon, kickoff meeting. 

Is a signing service the way forward to secure private keys? Ian said that
was a fair statement. Preference that ISVs use signing services. Overall a
signing service is a preferred approach to code signing (but not a
requirement). Signing services should make it easy to use which will
encourage use. Commercial services exist with or without the CA. Open source
projects exist. The key is to make the solution better for all to use.
Concern over no mandate to use such a service which if not implemented, will
still allow for theft of private keys. 

How to determine if code is safe? Sometimes all the code is submitted to the
signing service vs. the hash. Could the code be checked prior to signing?
Ian said it's hard to do and can be evaded as well as being a high cost.
Overall makes an automated service much less attractive. Not in scope for
CSBRs. 

Part 2 

References: Simply moving the references from the definition to the
reference section. Deleted the version in the references and the
definitions. 8.2.1. Took out a section regarding. It's not applicable to
CAs, it's discussing platform requirements, and also pulling in the signing
service, which was not accurate, not something CAs have to do, cannot be
audited. There's no comments on this section. 9.2.1. Changing this section
were considered, but it was decided not to do anything to this section
because it would be more than a clarification at this point. Considering a
future ballot. Tim H: Highlights that there's a lot of things people do
here, which are reasonable: localized versions of names, email contact
addresses, etc. It would be good to tighten this up, here's what it can
contain, here are the validation requirements, but has to be a ballot. Added
to the to-do list. Bruce M: nothing says what it could be or how it would be
verified. Not a default deny guy, but could be a candidate for a default
deny interpretation. It's not specified. Tim H: That's why I called it out.
This shouldn't be "No stipulation". This is the one spot where default deny
sort of could make sense. Live with it until we fix it. High priority. Bruce
M: Define what can the SAN can be, and point to verification requirements.
Tim H: That's part of the problem. It would be nice to point elsewhere for
the verification requirements, but there are no validation requirements for
emails for example. Should be easier once the S/MIME groups gets a little
bit further. 9.3.1. Introduction of policy identifier for timestamp certs.
9.3.3. Clean-up of how to reference. Made the call-out specific to
Codesigning certificates. Introduced a call-out for Subordinate CA for
Timestamping. Just chose the date, but this was never discussed. Pushed out
so there wouldn't be an impact. Calling out specifically for a subordinate
CA, not a subscriber cert. Doesn't sound that hard to do. Ian M: Question
about the date. Previously discussed that end of year dates can be difficult
with holiday season. Bruce M: this can be done before that date, but can
pick a different date. Generally prefers a further date, so things can be
done earlier. Ian M: Suggests end of March. Get back from holidays, get
things done, end of quarter. 

Date changed to 31st of March 2022. General agreement. 

Tim H: Suggests choosing 4 reasonable compliance dates, one for every
quarter to standardize. Ian M: Agreed. There's no good date in Q4 and Q2
because summer and winter are usually bad for holidays, so we just go with
March 31st or September 30th. Tim H: July 15th - early enough in summer to
not be impacted too much by holidays. Difficult to keep track of multiple
compliance dates. 

11.1.1. Less than 3 years existence, didn't reference how requester should
be validated. Added reference pointing down to section below for individual
applicants. 

11.1.2 Addition to allow qualified certificates as a method to validate
individual's identity. 13.1.5 "This" replaced by "the revocation" - just a
clarification. Discussion a long time ago, but was never actually updated.
13.2.2. That one sentence regarding suspension, it wasn't originally there,
it was added and somehow it stayed there. Suspension would be a different
ballot, more than a clarification. Clear up how we were asking for status of
subordinate CAs vs Codesign certificates. Language taken from the BRs. More
clarification on what a CA has to do for which type of cert. 15. Data
records: bunch of comments made by Ian M, makes life easier for
timestamping, not adding extra, just removing some things that are there. No
objections or questions. Remove use of "PKI Systems" 16. Data security: This
is trying to clarify the statement which is in the Microsoft requirement
that a Codesign CA has to operate a TSA. Just making that statement in this
section. 16.3. We never dealt with 4-3, maybe in the future. Appendix A: Old
language didn't exist (minimum RSA modulus size). We're putting
in/specifying what the key sizes are supposed to be after certain date.
Since roots might be new, they may be cross referenced with 2048 (these
roots should expire by 2030 anyway). That was the condition, 2048 can't go
on forever, but for ubiquity for the next 9 years it's fine. Similar
clean-up for TSA. Timestamp tokens killed as part of discussions. Appendix
B: F. EKU: clarifying which key usages are allowed for subordinate CAs that
issues Codesigning certificates. What it must or can't have. We really don't
want to mix different EKUs together. Appendix C: no longer calling out BRs
for how interoperability verification can be done, we replaced this by a
should statement of what the CA should provide. Not a Must. In discussions
with Microsoft, root testing was the CA's responsibility, but the discussion
with Oracle was that they wanted something so Oracle could test. 

Summary: Changed one item, the date. Two endorses needed. Ian M is an
endorser. Need a second endorses. Dean C: one ballot with changes? Bruce M:
provide this document in PDF version with changes that will be made in this
ballot. Dean C: until we get to github Bruce M: Do I have two endorses? Tim
H: Digicert wants to review, but 98% chance that we can endorse Sebastian S:
Same for GlobalSign. Bruce M: Except for the change that was made, it is the
same document that was sent out two weeks ago, whoever gets back to us first
as second endorses. Send it out today or tomorrow. Other ballots and other
business. 

LOG AND DATA RETENTION: Ian H: has been working on log and data retention,
in last meeting it looked good, everyone happy in general, except Corey
brought up a good point on the TSA: 15.2.3: "after revocation or expiry",
can go 135 months, for 11 and a quarter years +2, so 13 and a quarter years,
that hurts. Made sense to go back in section 9, timestamp private key needs
to be rotated every 15 months, so essentially changed log and data retention
to be on that: 15 months + keep logs associated to old key for the next 2
years. Lines up better, not asking 13 and a quarter years of records.
Thoughts? NO OBJECTIONS OR QUESTIONS. Bruce M: So if we rotate the private
key every year, that meets the 15 month requirement. And I have to keep it
for two years after that. But it's the same TSA that's going out forever, so
I am keeping the logs anyway. I am just allowed to delete them after I have
stopped using that key. So basically after the first three years I can
delete the first year. We'll work it out, might be hard based on when the
private key is being used. Ian H: Other changes we looked at previously.
What are the records that constitute data records for TSA. Detached from BRs
5.4.3. and made it so we can move to just a 2 year log retention. Saves a
hard drive. Bruce M: in parallel with clean-up? Iain M and Dean C: After.
Let's get one done, a lot to consider. Immediately right after so quick IPR
review. 

Dean Coclin

Chair-CSCWG

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