[Cscwg-public] Final minutes for CSCWG 2021-04-22

Dean Coclin dean.coclin at digicert.com
Thu May 6 16:12:17 UTC 2021


 

Final Minutes for April 22nd CSCWG meeting

 

Attendees:

- Adriano Santoni

- Andrea Holland

- Atsushi Inaba

- Bruce Morton

- Corey Bonnell

- Dimitris Zacharopoulos

- Ian McMillan

- Inigo Barreira

- Janet Hines

- Mike Reilly

- Roberto

- Tim Crawford

- Tim Hollebeek

- Tomas Gustavsson

 

Minute-taker: Corey

 

Antitrust statement was read by Bruce.

 

Corrected minutes for April 15th meeting were approved.

 

Bruce: D-Trust notified us is retiring from CSCWG. No longer issuing code
signing certificates under our group's scope. Bruce asked if there's
anything to do to remove them.

Tim: I believe there's nothing we need to do.

Dimitris: If this is the only group they're participating in, then we remove
from the website.

Tim: Recommend forwarding notification to the group so there's an official
record.

Bruce: I'll ask them to send an email to the group.

 

Bruce: Next up on the agenda is Timestamping OID. What action do we need to
take?

Dimitris: Ben sent a reply to the list on next steps two days ago. No
discussion on that yet.

Bruce: My thinking is that our charter calls out the old EVCSBRs.
Timestamping is addressed there. From a higher up level, we have browsers
that want us to specify the end-entity certificate profile for Timestamping
in our document. We're not creating anything new; the document already
addresses Timestamping.

Dimitris: I recommend that approach and going forward with the update.

Bruce: Someone needs to go to the arc and add the OID.

Dimitris: Let's add to the document first in the CSBRs and not wait for a
website update to add the OID.

Tim: That's what we did the last time an OID was allocated. There's no
formal process for adding OIDs; right now, they get created by virtue of
adding them to documents and voting on the ballot.

Bruce: Let's reply to Ben's email with our plan to add the OID so it's on
public record and we can address any pushback.

Tim: I've always viewed Timestamping for the purposes of Code Signing as
under the CSCWG scope. If someone wants to disagree, they need to point to
specific language in the charter.

 

Bruce: Next item is Common Criteria. Adriano sent out an email about this.
Do we want to discuss now?

Adriano: I tried to explain how one can make the argument about the security
objectives. I received feedback from Dimitris that it's complex. I provided
an example of a product that is not acceptable, but others may make a
different determination.

Dimitris: I agree that we should specify the Common Criteria report further,
but we need to provide guidance to CAs and auditors to know where to look by
either providing examples or pointers to the lists produced by the European
Commission.

Adriano: I don't like the idea of a specific list of products.

Dimitris: We're not going to create that list; we're just going to point to
a list that others have created. It's no different than pointing to NIST
certifications.

Adriano: The CC Portal lists hundreds of devices and it is likely difficult
for the average person to determine whether the listed certificates provide
the assurance of the security functions that we need.

Dimitris: The European Commission website with the list of QCSDs and QSDs
are suitable for EV Code Signing. Inigo agreed as well. My concern is that
without any guidance, CAs will be in a difficult situation to find these
functions.

Bruce: It sounds like one method will take care of 90% of the use cases. If
the device is not on the QCSD and QSD lists, then it's difficult to find the
right information.

Dimitris: The difficult part will be to define the required security
functions in the CSBRs so that CAs can use the other lists.

Bruce: What's our next steps?

Dimitris: I can work with Adriano on language. I don't think this is a
cleanup ballot item.

Bruce: Would be best to include in Ian's key protection ballot.

Tim: Having a list of known good things would really help out auditors and
CAs. If your device isn't on the list, then it's up to you to prove it's
compliant.

Bruce: It would be best to have the vendor show how they're compliant.
Otherwise it sounds like "any other method" validation.

Tim: Part of the problem is that we don't even have language on what you
should be evaluating. Almost everyone punts on this because it's very hard
to do.

Dimitris: I'll take an action item to work with Adriano to develop language.
We agree that a list of approved devices would be very helpful and vendors
will need to prove how they meet the requirements.

 

Bruce: Next item is key protection ballot.

Ian: I will wait until after the cleanup ballot to bring this one and I
think we need to incorporate what Adriano and Dimitris just discussed about
lists of approved devices.

Bruce: I think we need more discussion on this. First part is the
requirements, and the second part is how you meet the requirements. I think
that's the longer part of the discussion.

Tim: What is comes down to is that the device needed to be audited for
hardware key protection. If it wasn't audited for hardware key protection,
then it's unsuitable for our needs.

Ian: For cloud key protection, they have logs for key generation; these logs
will show the protection level of the key. This can be provided to the CA. I
reached out to AWS and GCP to see if we can develop a standard key
attestation. But for now, there are logs.

Tim: Did these cloud providers say whether these logs can be provided to
others directly?

Ian: Just to the Applicant.

Tim: Are we worried about the Applicant tampering with the log?

Ian: I agree that's a concern but unfortunately there's nothing better now.

Tim: If it's a stop-gap until better solutions are available, then this
would be good.

Ian: Various cloud providers are starting to provide attestation services.
The problem is what scenarios they're supporting.

Dimitris: I think it depends on level of assurance. Today we have the
Subscriber Agreement, which is a pinky-swear. But some CAs don't accept just
that; some CAs require witnessing a "mini" key ceremony.

Tim: We discussed internally that we'd be willing to witness the generation
on Zoom, for example.

Dimitris: That makes sense, because it's better than nothing. It's more
painful because your engineers need to witness, but some CAs do require
this.

Tim: Coordinating these types of meetings is something that CAs do every
day.

Ian: We'd be happy if MUST provide log and SHOULD witness the "ceremony".

Bruce: We need to come up with a list of way of verifying the various
storage methods. May not need to add the list directly in the CSBRs, but
make it available to CAs and auditors.

 

Bruce: Next agenda item is the cleanup ballot. We'll take another week or
two to refine and then circulate to the group for discussion.

 

Bruce: Any other business?

Ian: One thing that came up with the cleanup ballot is the BR version. Right
now we reference BR v1.6.9. We discussed bumping that up to a newer version.
Especially, v1.7.3, which has SC28, which deals with log retention
requirements. If we can incorporate that, that will save CAs a lot of
storage space.

Bruce: We should synchronize, because it's hard to do different things for
different certificates (TLS vs. CS).

Ian: Worried someone might have an incident because they changed their log
retention period to 2 years but now they're out of compliance with the CSBRs
(7 years).

Dimitris: There is a significant risk here; someone will need to investigate
all the redlines from v1.6.9 to v1.7.3. There are changes besides logging
that may affect Code Signing.

Bruce: We need to do the hard work to bring it up to date and then continue
to look at the deltas moving forward. One solution is to get our CSBR
document in the new document system and incorporate all referenced sections
so we can manage the CSBRs separately. That's what S/MIME working group is
doing.

Tim: Just because we make our own document doesn't mean we can't incorporate
changes from time to time.

Dimitris: We had the strategy from last year that the interim step that we
convert to RFC 3647.

Tim: There are things that we can't wait for, such as logging and perhaps
other things.

Bruce: Can someone provide a delta for all changes in the BRs?

Tim: We'll get a link out for everyone.

Bruce: We can review and see the changes. I think we want to do that review
and make a ballot within the next month or two.

 

Next meeting is May 6th. Meeting adjourned.

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


More information about the Cscwg-public mailing list