Next CA Communication -- September?

[Kathleen Wilson]

All,

The CA/Browser Forum has updated the Domain Name Validation Rules in
version 1.3.8 of the Baseline Requirements.[1]

Section 3.2.2.4 of the BRs has been updated to reflect this change in
version 1.3.8.[2] The BRs say that CAs need to follow the new validation
rules by March 1, 2017.

So, I think I should send the next CA Communication[3] to make sure all
of the CAs in Mozilla's program are aware of these new requirements, and
update their CP/CPS accordingly by March 1, 2017.

Are there any other topics that I should include in this upcoming CA
Communication?

Thanks,
Kathleen

References:
[1]
https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/
[2]
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8-redlined.pdf
[3] https://wiki.mozilla.org/CA:Communications

[Nick Lamb]

On Tuesday, 23 August 2016 20:03:13 UTC+1, Kathleen Wilson wrote:
> Are there any other topics that I should include in this upcoming CA
> Communication?

It can be worth following-up on date-in-time commitments from those CAs in replies to the previous communication this year. Each CA should be able to confirm either that the committed action has now happened as planned, or is delayed and give a new hoped-for date.


China Internet Network Information Center (CNNIC) wrote "We plan to upgrade device and software and also deploy new SHA 256 intermediate Root (operated by CNNIC ) to issue SHA256 DV and EV cert by the end of May, 2016."

RSA the Security Division of EMC wrote of their SHA-1 signing "There is a plan in place to change this to SHA-2 by June 15, 2016"

SwissSign AG wrote also of a system that still uses SHA-1 "We will Change this to SHA2 until August 2016."

Swisscom (Switzerland) Ltd wrote "SHA-1 S/MIME certificates are still being issued since one our customers did not fully migrate to SHA-256 yet. Deadline for this migration is 06/30/2016, from this date on, no more SHA-1 based S/MIME certificates will be issued"


Telia Company (formerly TeliaSonera) wrote that they need "more time up to 06/30/2016 to find the details" of certificates which lack a matching SAN for the CN.

Trustis wrote "KeyUsage will be added to all Certificates with effect from 05/30/2016"

T-Systems International GmbH (Deutsche Telekom) wrote that dubious OCSP responses "will be fixed by June 02, 2016." and also that "We plan to switch to SHA-2 until Q3/2016" for CRL signing.

Autoridad de Certificacion Firmaprofesional wrote that certificates with no corresponding SAN for their CN "will be revoked by July, the 1st, 2016"

Camerfirma use BMPString in the certificate DN, but "We plan to have a solution in a couple of months"

DocuSign (OpenTrust/Keynectis) likewise use unsupported encodings in the DN. They wrote "Last issuance date will be 06/30/2016"

Entrust again with unsupported DN encodings, wrote "last issuance date could be as late as 30 June 2016"

Government of Hong Kong (SAR), Hongkong Post, Certizen, wrote that they "Will stop issuing SSL certificates without the DNSName entry in the subjectAltName extension on 1 Sep 2016."

Government of The Netherlands, PKIoverheid (Logius) wrote "We are in the process of altering our CP with regard to this issue. Our new CP will be effective coming July."

WISeKey wrote of continued non-SSL SHA-1 issuance "We expect this situation to be solved during the first half of 2016 "

I am sure we all recognise that it is easy to make commitments about the future but not always so easy to keep them. For this reason I think reminders are useful. Because the earlier replies with these dates in were public, updates should be made public too. However it may be more appropriate to handle these as individual messages rather than a mass communication.

[Nick Lamb]

On Tuesday, 23 August 2016 20:03:13 UTC+1, Kathleen Wilson wrote:

> Are there any other topics that I should include in this upcoming CA
> Communication?

Also, I think that the SHA-1 topic should be brought up again. Some CA folks will be tired of reading about this, having managed the issue with their customers and performed an orderly migration years ago. But for others every communication from Mozilla is a renewed impetus to actually get on with the job. An ounce of prevention now is worth a pound of cure in January.

It doesn't need to be as elaborate as the previous communication, for example it could ask CAs to confirm that they've taken reasonable steps to contact any affected subscribers and make sure those subscribers understand what action they should take, what the deadlines are, and what will happen if they do nothing.