[Cscwg-public] Ideas for improvements to CS Requirements

Tim Hollebeek tim.hollebeek at digicert.com
Thu May 2 09:22:14 MST 2019


IIRC Oracle and Java also have substantially different policies about what
happens as end entity, root, and timestamping certificates expire.  This can
make it challenging to choose appropriate certificate lifetimes for root
certificates and timestamping certificates.

 

-Tim

 

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Dean
Coclin
Sent: Wednesday, May 1, 2019 6:27 PM
To: cscwg-public at cabforum.org
Subject: [Cscwg-public] Ideas for improvements to CS Requirements

 

During our calls, we started discussing potential improvements to the
current guidelines and agreed we would start working on them after the
Guidelines become ratified by the Forum. I would like to start a discussion
about potential ideas:

 

1.	Centralized blacklist:  In the previous working group, we discussed
a central source for hosting a black list to ensure CAs aren't issuing certs
to those that one CA had to revoke because of bad practices. Microsoft was
considering doing this but ended up deciding not to. We should look at this
again.

 

2.	Information sharing:  It seems like we should have some avenue for
AV companies to send malware cases to the respected CAs involved so that
revocation can happen in a timely manner.

 

3.	New Signing approaches:  Signing can happen via cloud services,
through APIs, Docker containers, etc., Insure that requirements don't
prohibit newer use cases.

 

4.	Timestamping treatment - Oracle (Java) and MSFT (Authenticode) treat
timestamping differently in the case of revocation. Authenticode signed
files will continue to be trusted if they are signed and timestamped by a
revoked cert as long as they are signed and timestamped before the
revocation date. All Java signed files are no longer trusted if the signing
cert is revoked, even if they are signed and timestamped before the
revocation date. Need to keep aware of this difference.

 

5.	Push for EOL of SHA1. The document today allows for corner cases for
legacy OS's which still require SHA1 certs, and Java may have some too. We
should end support for SHA1 sooner than currently allowed.

 

6.	Kernel Mode: There is a concept of kernel mode signing certs. EV
should be used for all driver signing. 

 

These can be discussed on next week's call but feel free to provide feedback
prior to that on the list.

 

Thanks,

 

Dean Coclin

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/cscwg-public/attachments/20190502/7b7f4ae2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/cscwg-public/attachments/20190502/7b7f4ae2/attachment-0001.p7s>


More information about the Cscwg-public mailing list