[Cscwg-public] Final minutes of CSCWG August 26, 2021

Thu Sep 9 20:33:29 UTC 2021

Here are the final minutes of the subject meeting

Attendees:

*	Atsushi Inaba - GlobalSign
*	Andrea Holland - SecureTrust
*	Bruce Morton - Entrust
*	Corey Bonnell - DigiCert
*	Dean Coclin - DigiCert
*	Ian McMillan - Microsoft
*	Janet Hines - SecureTrust
*	Joanna Fox - TrustCor
*	Tim Crawford - BDO
*	Tim Hollebeek - DigiCert
*	Roberto Quinones - Intel

Bruce read the anti-trust statement.

Minute-taker: Andrea

Minutes from July 29th were approved.

Bruce - Parking Lot Items Update

*
https://docs.google.com/spreadsheets/d/1UID98GQnBNE9dzIkugMlLFF6po8FC5vbcSq0
cwMEVqk/edit#gid=0
<https://scanmail.trustwave.com/?c=4062&d=kfeW4XVnVBY1I_d5X9VVgwdf-VXnfQzLmT
DhJkATMQ&s=5&u=https%3a%2f%2fdocs%2egoogle%2ecom%2fspreadsheets%2fd%2f1UID98
GQnBNE9dzIkugMlLFF6po8FC5vbcSq0cwMEVqk%2fedit%23gid%3d0%26fvid%3d1822680629>
&fvid=1822680629
*	Parking lot is tracking the open items from email discussions and
meetings
*	A bunch of items have been closed out during the cleanup and
clarifications ballot
*	Review of open items 

*	Section 11.5 - In discussion
*	Section 16.3 - Ian is working on a ballot
*	Section 4 - Setup method to discuss new ballots coming from BRs and
EV Guidelines
*	Section 13 - Dimitris is working on a ballot
*	Section 9.2.1 - Tim H is working on 
*	Section 11.1.11 - Open
*	Section 9.2 - Open
*	Section 13.2.1 - In discussion
*	Section 7.2 - will probably drop since we are working on as a whole
*	Section 11.1.2 - in discussion
*	Section 15 - Open
*	Section All - In process
*	Section 9.2.4 - Open

Ballots

*	CSC-9 in IPR until Sept 8th
*	CSC-10 in IPR until Sept 12th
*	Bruce: Do we want 2 publications 4 days apart? Or put into 1
publication
*	Dean: Practically speaking 1 publication make, but we will have to
check the bylaws
*	Bruce: The work has been done
*	Dean: Will have to do some research
*	Bruce: We will discuss it on the 9th

*	Ian - Logging Ballot - Data Log Retention

*	Taking from BRs v2.5 the outcome of CSC-10 and put CSC-11 on top of
it
*	Redlined Ready and drafted for ballot discussion
*	Looking for 2 endorsers
*
https://wiki.cabforum.org/cscwg/csc_11_-_update_to_log_data_retention
_requirements
*	Ian to send out redline for potential endorsers to review

*	Ian - Subscriber Private Keys

*	Has some proposed language, but waiting for cleanup and log
retention ballot
*	Still need to discuss: How does a subscriber provide proof of key
generation in a protected system? 
*	Ian Will present ideas at the next meeting

Bruce - SCWG Ballots to Review

*
https://docs.google.com/spreadsheets/d/1UID98GQnBNE9dzIkugMlLFF6po8FC5vbcSq0
cwMEVqk/edit#gid=0
<https://scanmail.trustwave.com/?c=4062&d=kfeW4XVnVBY1I_d5X9VVgwdf-VXnfQzLmT
DhJkATMQ&s=5&u=https%3a%2f%2fdocs%2egoogle%2ecom%2fspreadsheets%2fd%2f1UID98
GQnBNE9dzIkugMlLFF6po8FC5vbcSq0cwMEVqk%2fedit%23gid%3d0%26fvid%3d1822680629>
&fvid=1822680629
*	Purpose - CSBRs refer to both TLS BRs and EV Guidelines. We didn't
want the docs to impact us so froze the versions. However, we end up losing
out on positive improvements
*	Review ballots for any impact

*	SC26 - Formatting change - No impact
*	SC28 - Log changes - Improvement - Ballot created
*	SC30 - EV registration transparency - Improvement - should be
discussed
*	SC31 - Browser Alignment - No Impact - should rereview after
reformatting

*	Corey: More impactful ballots, so a comprehensive review is needed
*	Tim H: In agreement
*	Bruce: Maybe have a CSBR alignment ballot
*	Tim H: Benefits to alignment to reduce issues of selecting the wrong
requirements to follow

*	SC33 - APLN method - Review 

*	Bruce: Domains have no impact since we don't have domains
*	Tim H: Tiny ways domain can get in, the OU language references
domains in an OU
*	Bruce: we have that in the CS document?
*	Tim H: It is there more as bug then a feature

*	SC35 - Cleanups/Clarifications - Needs Review

*	Bruce:
*	Tim: SC31 + SC35 good to review together

*	SC39 - NetSec Critical Vulnerability - No Change - Already have to
abide by since we don't have a version set
*	SC41 - Reformatting - No impact
*	SC42 - 398 day reuse - No impact
*	SC44 - Status codes - No impact
*	SC45 - Wildcard domain validation - No impact
*	SC46 - CAA - No impact
*	SC47 - Remove OU - review

*	Bruce: Is that something we want to consider

*	SC48 - Domain Encoding - No Impact

*	Bruce: Circle back and review the items for domains. Overall two
items Log changes and alignment (we can include EV registration in the
alignment as well). The one that will help us we are taking care of and the
others will be addressed with an alignment ballot.
*	The one that will help us are taken care of and the others have no
impact.

Corey - New Formatting for CSBRs

*	Completed moving content of CSBRs version 2.5 to pandoc includes
CSC-10 Audit Criteria update.
*	Working out of fork in github -
https://github.com/CBonnell/code-signing/tree/rc3647-migration
*	Running through another sweep and will be opening a PR to get the
process started.
*	Appendices A+B are now in Section 7
*	Pdf:
https://github.com/CBonnell/code-signing/actions/runs/1171082629
*	Content has some word smithing. Some things that needed to be split
up, adjust for formatting, and organization shifts. 

*	Ex. Timestamping was under key protection so it got moved to Section
6.8 

*	A lot of blank places which already existed. Which leaves it
unclear. Do you go to look at the TLS BRs for information? What if the TLS
BRs is also blank? Is what is on the TLS BRs relevant for CS BRs?

*	Corey: Next Step- Does this blank make sense?
*	Dean: Good point, this is where we will need to do some work and
research; fill in what might need to be here or adding new content.
*	Bruce: Is there language that states we follow TLS BRs unless noted
in CSBRs?
*	Corey: I didn't not find any explicit language. It is agreed upon,
and called out in some areas, but not for the overall document. Ex. CRL
Profile Requirements.
*	Bruce: But we do say, except were specifically stated during the
event of any conflict in which case these requirements will prevail, this
document incorporates by reference the Baseline Requirements, NetSec
Requirements, EV guidelines. 
*	Dean: What does that mean for audits?
*	Tim Crawford: It is easier to have the relevant information brought
over. If not, we pull those from the baseline SSL where applicable.
*	Bruce: This problem already exists we are just reformatting.
WebTrust wrote audit criteria for CS and based on our CSBRs. I don't know if
a problem exists. A problem would exist if we take the reference to the TSL
BRs out of our document. Section 1.1 of our document we state we are using
those documents unless they conflict with what we wrote in our CS BRs
*	Tim Hollebeek: I agree with you and I think in most cases like key
pairs certificate usage, is something that is well understood and the fact
that it doesn't diverge. There is not going to be any real disagreements on
that. There are sections that are blank where the underlining TLS BRs
section doesn't make any sense in the CS context, but nobody's noticed.
*	Bruce: I agree
*	Tim H: I agree there is no problem, but it would be worth while to
review. Do we really mean No Stipulation and if we do put that there. Do we
really mean defer to the TLS BRs and if we do put that there. 
*	Dean: Does the audit criteria change if we clarify.
*	Tim H: I am moving beyond the audit criteria, that can remain
unchanged. The point I was making is that 90% of the topics you can up with
what was actually intended. The problem is there are areas where it is
unclear and if you are trying to figure out what the requirements are it is
unclear what the intent is. We did this for TLS BRs in DC 5 years ago and
actually put in No Stipulation where it is made. Now that we are in 3647
format it is much easier to solve this problem. Probably only take a hour or
two to produce a rough draft. 
*	Dean: This is a task for another time and put on the agenda. Great
start Corey, looks great, is readable, and manageable. We can dedicate time
at another meeting, a separate summit, or the face to face. We have a lot of
options.
*	Tim H: Instead of trying to have a bunch of us spending time looking
at. Maybe just a two of us review and provide recommendations without having
everyone sit and look through side by side
*	Dean: Calls for volunteers

*	Tim H. and Corey volunteer

*	Corey: Aid review word version of current CS BRs and marking it up
with comments.
*	Bruce: That will be useful to make sure we didn't miss anything.

Any Other

Bruce - Invalidity Date Email

*	CS BRs state revocation date but should use invalidity date. 
*	Corey responded to email that he thinks that is correct, but
Authenticode doesn't work that way

*	Corey: Rob Stradling responded said that his recollection matches
mine. Bruce you are right that is the right way to encode that information
following 5280. Microsoft Windows Authenticode implementation looks for
revocation date.
*	Bruce: To make the documentation correct though if someone puts the
revocation date in the validity date that is fine, or the validity date in
there is fine. It might not work for windows, but it would make it the
correct term in our document. The term in our document makes it sound like I
can put in the revocation date which implies past date. It cannot be a past
date it has to be the date I do the revocation. If I want to put in a past
date that is the validity date.
*	Corey: That is a should not 5280. I don't see a hard prohibition. CS
BRs are written as guidance to CAs that the revocation date field has to be
used even if you are backdating.
*	Bruce: I thought the verification date has to be used if you are
revoking.
*	Corey: The revocation date has to be set in the past for windows to
recognize. To serve the function of the invalidity date you have to
essentially use the revocation date.
*	Bruce: You cannot push back the revocation date if you already have
a CRL issued where the thing has not be revoked.
*	Corey: That is not a must not that is a should not. It is not a hard
prohibition on 5280.
*	Bruce: Sounds like a bad idea.
*	Corey: I agree it is an abuse of the CRL profile. If we force
everyone to switch the invalidity date without windows update would be a
security concern. If someone's build server was popped two months ago and
everything that was compiled and signed from that compromised server now
contains malware. We need some way of encoding that. Everything up to when
that server was compromised as trusted to everything that is after is not.
There has to be a provision to add a past date to a revocation date.
*	Ian: Asking windows code integrity team to appropriately use the
invalidity correct date. Priority of updating/improving our revocation and
remediation. Will bring up change to team, not making any promises.
*	Bruce: Will table the request until we hear back from Ian. The
benefit is that I could push back the revocation date.
*	Corey: Right. If a subscriber finds out their server was popped 3
months ago. You want a way of invalidating software that was built or signed
from that machine retroactively.
*	Bruce: It still seems odd. I revoked 100 certs and this 1 I want to
push back so I put out a revocation date which is backwards does that impact
those other certs as well.
*	Tim H: It can be a challenge picking the revocation date that
correctly balances getting rid of the malware and whichever printer driver
needs to be preserved. Art in how this is done in practice
*	Bruce: Ian, It would be great to have that looked at so it doesn't
have the CAs try to do some art to provide the right information.

Ian - Data Privacy

*	Data privacy is evolving quickly.
*	Was asked does the CS BRs look at the audit requirements and how are
we in conflict with Data privacy laws as they evolve and should we?

*	Tim H: Do you believe we are in conflict with the data protection
laws anywhere?
*	Ian: Yes, if you are required to log anything that is part of
identity verification or like IP addresses.  We just removed that from the
timestamping authority data retention that is considered EUPI synonymous
PII. Those kind of things.
*	Tim H: Thank you for clarifying what you mean. I believe the EU
regulations have carves out for that sort of activity, because CAs are
providing security services and are allowed to process PII for their
customers. I can get a better answer from legal if you would like some
advice about the data privacy.
*	Ian: I am more interested in should we as a group be considering how
our requirements are impacting a CA or anybody else's timestamping authority
or signing services ability to meet data privacy requirements as they
evolve. And should we keep an eye on that anyway.
*	Tim H: Based on what I have heard from our legal there aren't any
challenges in that area. But it is something we should keep an eye on.
*	Ian: I heard the same thing from our legal two years ago. Yesterday
in a data privacy review, I heard some other things around new data changes
in the GDPR and changes in individual states inside of the US. At any one
moment these things can blow up
*	Tim H: Absolutely, following 50 separate state laws and 200
countries is a challenge. If you do have any information on that, that you
can share. I would love to see it.
*	Ian: I can see if I can get more detail from the privacy review
expert.

Next meeting September 9th in 2 weeks.

Meeting Adjourned

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