Bugzilla Bugs re CA issuance of non-compliant certs

[Kathleen Wilson]

All,

I have gone through the July/August posts in m.d.s.policy in order to determine which Bugzilla Bugs I should file.

There are two outliers:
~~
** Undisclosed intermediates, or those missing audits
I have been working diligently on intermediate cert disclosures in the CCADB for many months now. I greatly appreciate the web pages that Rob Stradling created to help me with this effort!!!
This has also included work on adding revoked intermediate certs to OneCRL, and I hope the other major root store operators will catch up on this:
https://crt.sh/revoked-intermediates
Anyways, I have been working on those separately and in contact with those CAs, so I do not plan to file separate bugs, beyond what I have already done or am doing.

** Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ
It is not clear to me if I need to add this item to the Bugzilla Bugs that I will be filing. Please let me know if you think I need to add this item to the bugs.
~~


Here’s a summary of the bugs that I plan to file as a result of the recent activity in m.d.s.policy. (one bug per CA listed below)

My expectation is that the CAs will provide the following information in their bugs:
1) Confirmation that the CA has stopped issuance of certs with these problems.
2) Explanation about how/why the mistakes were made, and not caught/fixed earlier.
3) List of steps the CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when the CA expects to accomplish these things.
4) Updates to confirm when those steps have been completed.

I do *NOT* necessarily expect the CAs to revoke all of these certificates. I expect the CAs to do a careful analysis of the situation and determine/explain whether or not they will revoke the certs or let the expire. If the choice is to let them expire, there needs to be good reasons and a timeline for when the bulks of certs will expire. We (Mozilla community) will evaluate such information and provide constructive feedback, and I or Gerv will add a comment in the bug to confirm if the plan (when not revoking) is acceptable, or to state if we/Mozilla will require revocation.

Thanks,
Kathleen

== Actalis ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Camerfirma ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

URI in dNSName SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/etp2Yz2fmM4/ayBTsfJnBgAJ


== Certinomis ==

Invalidly long serial numbers (Serial Number > 20 Octets)
https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/74sItqcvBgAJ

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== certSIGN ==

Invalid common name and invalid SAN dnsName
https://groups.google.com/d/msg/mozilla.dev.security.policy/ETG72kifv4k/2BD-CVDDAAAJ

== Comodo ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== D-TRUST ==

dNSName containing '/'
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ

Short / sequential-looking serial numbers
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ
RESOLUTION: https://groups.google.com/d/msg/mozilla.dev.security.policy/UnR98QjWQQs/O-Hf5T4WBwAJ


== DigiCert ==
(Bug #1389172 already created by Jeremy - for the first 3 items below)

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Invalidly long serial numbers (Serial Number > 20 Octets)
https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/74sItqcvBgAJ

Serial Numbers less than 64-bit entropy
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/5bpr9yBgaYo/rJLOz0XPBQAJ

Reserved IP addresses
https://groups.google.com/d/msg/mozilla.dev.security.policy/inocepURbNQ/MmkeMvhyCAAJ


== Disig ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== DocuSign ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Entrust ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.


== FNMT ==

"AC FNMT Usuarios” intermediate is not supposed to issue TLS server auth capable certs. [KATHLEEN: Add to OneCRL]
https://groups.google.com/d/msg/mozilla.dev.security.policy/Qo1ZNwlYKnY/UrAodnoQBwAJ

== GlobalSign ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

== Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) ==

Serial Numbers less than 64-bit entropy
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ


== IdenTrust ==

pathLenConstraint with CA:FALSE
https://groups.google.com/d/msg/mozilla.dev.security.policy/1q_aq5e0El4/LmfGUDmHBwAJ

OCSP responder URL that has a HTTPS URI
https://groups.google.com/d/msg/mozilla.dev.security.policy/jSHuE-Oc7rY/660iCGPZBgAJ

== Izenpe ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

Serial Numbers less than 64-bit entropy
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ

== Keynectis ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ


== Let’s Encrypt ==

Improperly normalized IDNs
https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/izYkdc7DBwAJ
RESOLUTION: https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJ


== Microsec ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ


== Netlock ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ


== PROCERT ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

URI in dNSName SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/etp2Yz2fmM4/ayBTsfJnBgAJ

Reserved IP addresses
https://groups.google.com/d/msg/mozilla.dev.security.policy/inocepURbNQ/MmkeMvhyCAAJ


== QuoVadis ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Short / sequential-looking serial numbers
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== SECOM ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

== StartCom ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ


== Staat der Nederlandend / PKIoverheid ==

Short / sequential-looking serial numbers
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ
RESOLUTION: https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ


== SwissSign ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.


== Symantec ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Taiwan-CA Inc. (TWCA) ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== T-Systems ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Visa ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== WISeKey ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

==

[Ryan Sleevi]

On Tue, Aug 15, 2017 at 3:37 PM, Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> I do *NOT* necessarily expect the CAs to revoke all of these certificates.
> I expect the CAs to do a careful analysis of the situation and
> determine/explain whether or not they will revoke the certs or let the
> expire. If the choice is to let them expire, there needs to be good reasons
> and a timeline for when the bulks of certs will expire. We (Mozilla
> community) will evaluate such information and provide constructive
> feedback, and I or Gerv will add a comment in the bug to confirm if the
> plan (when not revoking) is acceptable, or to state if we/Mozilla will
> require revocation.
>

The requirement for revocation comes from the Baseline Requirements.

Could you clarify your expectations regarding CAs' violation of the
Baseline Requirements with respect to these issues and Section 4.9.1.1.

That is:
1) Do you expect a qualified audit report for any CA that has failed to
revoke within 24 hours? (I would suggest Mozilla should expect that, but
that's not explicitly stated, and other programs may already expect/require
this)
2) Are you suggesting you will, in evaluating such a qualified report, take
into consideration the explanations CAs provide, and the determination of
whether or not such a qualified report will be acceptable shall be
communicated in the bug? (I think that's a correct analysis of your
proposal, but want to confirm)
3) Do you have a plan for CAs that (1) fail to respond (2) fail to respond
in a timely fashion (3) fail to respond to a level of detail sufficient to
determine whether or not it's a 'good' reason).

I would note that any CA which does not or has not promptly revoked these
within 24 hours of contact should, at a minimum, contact all root programs
that they participate in to acknowledge this non-compliance and discuss
what expectations other, non-Mozilla Root Programs have with respect to
these certificates. Similarly, if such programs have requirements around
"Security Incident Reporting," that CAs are timely in such reports.

Given that these are a requirement in the Baseline Requirements, it is up
to each CA to work with their auditor (and supervisory body, as
appropriate) and the root store(s) they participate in to ensure their
analysis of the risk and plan of remediation is acceptable.

Is that a correct summary of the situation?

[Jonathan Rudenberg]

> On Aug 15, 2017, at 15:45, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> I would note that any CA which does not or has not promptly revoked these
> within 24 hours of contact should, at a minimum, contact all root programs
> that they participate in to acknowledge this non-compliance and discuss
> what expectations other, non-Mozilla Root Programs have with respect to
> these certificates. Similarly, if such programs have requirements around
> "Security Incident Reporting," that CAs are timely in such reports.

It’s worth noting that with the exception of the metadata-only subject fields issue, Alex and I have attempted to contact every CA listed directly via their public certificate problem reporting channels. In addition to this, the Mozilla Root Store policy requires all CAs to monitor this mailing list. So there are only two categories for a CA that has not taken action yet:

1) They are not monitoring either this list or their problem reporting channels (or in some cases, those channels are inoperative) and as a result are not aware of the issues; or
2) They are aware of the issues and have not taken action.

I believe that both of these categories are extremely concerning.

Jonathan

[Kathleen Wilson]

On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote:
>
> The requirement for revocation comes from the Baseline Requirements.
>
> Could you clarify your expectations regarding CAs' violation of the
> Baseline Requirements with respect to these issues and Section 4.9.1.1.

Are you specifically referring to item #9 of Section 4.9.1.1?
Or other items in that list?

For reference for everyone, here's what Section 4.9.1.1 currently says:
~~
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Sections 6.1.5 and 6.1.6;
4. The CA obtains evidence that the Certificate was misused;
5. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
6. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the
Domain Name);
7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
8. The CA is made aware of a material change in the information contained in the Certificate;
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
11. The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
12. The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
13. The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated
cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).
~~

Kathleen

[Jonathan Rudenberg]

> On Aug 15, 2017, at 15:37, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> ** Common Name not in SAN
> https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ
> It is not clear to me if I need to add this item to the Bugzilla Bugs that I will be filing. Please let me know if you think I need to add this item to the bugs.

This is a legitimate BR violation and should be listed. In addition to the basic issue, this also uncovered a variety of certificates with invalid domains in the CN field.

The only CA that has contested this is Symantec[0], who have issued certificates with U-labels in the CN that do not match the capitalization of the corresponding SAN A-label. It’s not clear that U-labels are allowed at all in the CN, let alone labels that do not match any dnsNames, and none of the ballots that attempt to explicitly allow this have been adopted.

Jonathan

[0] https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/rxEptYe7BwAJ

[Kathleen Wilson]

On Tuesday, August 15, 2017 at 1:00:04 PM UTC-7, Jonathan Rudenberg wrote:
> It’s worth noting that with the exception of the metadata-only
> subject fields issue, Alex and I have attempted to contact every
> CA listed directly via their public certificate problem reporting channels.

Good point, so in each Bugzilla Bug I should also add the item that their certificate problem reporting channel might be broken.

> In addition to this, the Mozilla Root Store policy requires all CAs
> to monitor this mailing list.

Mozilla's Root Store policy says:
"CAs MUST follow and be aware of discussions in the mozilla.dev.security.policy forum, where Mozilla's root program is coordinated."

There is no indication about how frequently a representative of the CA must check the m.d.s.policy discussions. And what about when a CA's representative is on vacation? (e.g. the month of August for many CAs) Do we really expect them to monitor m.d.s.policy while on vacation? (I don't even monitor it myself while I'm on vacation.)

Also, for many of the subjects for the posts in m.d.s.policy I could see that whomever is monitoring the discussion forum might assume certain posts do not apply to their CA.

Cheers,
Kathleen

[Ryan Sleevi]

On Tue, Aug 15, 2017 at 4:01 PM, Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote:
> >

> > The requirement for revocation comes from the Baseline Requirements.
> >
> > Could you clarify your expectations regarding CAs' violation of the
> > Baseline Requirements with respect to these issues and Section 4.9.1.1.
>

> Are you specifically referring to item #9 of Section 4.9.1.1?
>

Yeah, #9 serves as a catch-all, but based on the reporting from Jonathan
and Alex, also #4.

For things like internal IPs / domains, there's #6 and #10

Depending on the CP/CPS, #14 applies

For some of the encoding issues, I would argue that #15 would/should apply
- some of these certificates actively harm interoperability (e.g. they're
problematic practices well beyond an acceptable timeframe for them, and
fail to work in NSS and other applications)


I think, in all of this, it's worth calling out that at least one CA has
(1) Proactively reached out to multiple root programs regarding a proposed
remediation plan
(2) Provided a detailed post-mortem that sufficiently demonstrates an
understanding of the issue
(3) Provided a reasonable and responsible set of next steps that arguably
represent good industry practice that other CAs should consider adopting.

And that's PKIoverheid.

Also worth calling out is Let's Encrypt, which was able to revoke in a
timely fashion, enact a production change, and provide a detailed
post-mortem, all within 24 hours. That's an incredible level of
responsibility and turn-around that shows a systemic understanding of the
risks and challenges.

It would be a shame if the excellent work by these two CAs to address
community concerns was not met-or-exceeded by the other CAs on the list, as
that certainly discourages future post-mortems and encourages incomplete
responses.

[Jonathan Rudenberg]

+mdsp

> On Aug 15, 2017, at 16:45, Adriano Santoni <adriano...@staff.aruba.it> wrote:
>
> Hi, we did receive your message about 1 certificate issued by us and containing some invalid domain names. Those are internal server names and their inclusion in SSL certificates was still permitted at the time when that certificate was issued.
> We should have revoked that certificate however, by now, so we are investigating on why it's still active. In the meantime we have contacted our customer and are explaining the need to revoke that certificate.
> Thank you for letting us know of this issue.
>
> Regards
> Adriano Santoni
> Actalis
>
>
>
>
> Inviato dal mio dispositivo Samsung
>
>
> -------- Messaggio originale --------
> Da: Jonathan Rudenberg via dev-security-policy <dev-secur...@lists.mozilla.org>
> Data: 15/08/2017 21:59 (GMT+01:00)
> A: ry...@sleevi.com
> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>, Kathleen Wilson <kwi...@mozilla.com>
> Oggetto: Re: Bugzilla Bugs re CA issuance of non-compliant certs

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Kathleen Wilson]

Feedback will be appreciated on the following draft for the Bugzilla Bugs that I will be filing for the problems listed below.

Product: NSS
Component: CA Certificate Mis-Issuance
Whiteboard: [ca-compliance]
Blocks: 1029147
Summary: <CA Name>: Non-BR-Compliant Certificate Issuance

Description:
The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
2) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
3) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
4) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …

9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;

10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …

14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation and if there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced.

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your
analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ

** <items listed below for the CA>

~~ END DRAFT ~~



Updated list:

== e-Szigno SSL CA ==

Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

== Let’s Encrypt == RESOLVED (no bug needed)

Improperly normalized IDNs
https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/izYkdc7DBwAJ
RESOLUTION: https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJ


== Microsec ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ


== Netlock ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ


== PROCERT ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

URI in dNSName SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/etp2Yz2fmM4/ayBTsfJnBgAJ

Reserved IP addresses
https://groups.google.com/d/msg/mozilla.dev.security.policy/inocepURbNQ/MmkeMvhyCAAJ

Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

== QuoVadis ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Short / sequential-looking serial numbers
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== SECOM ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

== StartCom ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Staat der Nederlandend / PKIoverheid == RESOLVED (no bug needed)

Short / sequential-looking serial numbers
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ
RESOLUTION: https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ


== SwissSign ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

== Symantec ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

[Jonathan Rudenberg]

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Feedback will be appreciated on the following draft for the Bugzilla Bugs that I will be filing for the problems listed below.

I think we should ask for the CAs to provide a complete list of certificates that they find with each of the listed issues during the remediation process. The best way to handle this is to ensure each certificate is logged to CT and then provide a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.

Jonathan

[Jonathan Rudenberg]

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Feedback will be appreciated on the following draft for the Bugzilla Bugs that I will be filing for the problems listed below.

It would be useful to know when and through what channel the CA learned about each of the problems listed. (problem report via email at date/time; known/unresolved issue since date; mailing list post at date/time; when I saw this bug; etc.)

Jonathan

[Kathleen Wilson]

On Tuesday, August 15, 2017 at 3:53:06 PM UTC-7, Jonathan Rudenberg wrote:
> It would be useful to know when and through what channel the CA learned about each of the problems listed. (problem report via email at date/time; known/unresolved issue since date; mailing list post at date/time; when I saw this bug; etc.)

I agree that will be useful, but my goal with this is to educate the CA about what we expect going forward. I want to foster open communication with CAs, so I will ask for this information, but I will not use this information against the CA.

Kathleen

[Kathleen Wilson]

Updated draft for the Bugzilla Bugs that I will be filing for the problems listed below.

Product: NSS
Component: CA Certificate Mis-Issuance
Whiteboard: [ca-compliance]
Blocks: 1029147
Summary: <CA Name>: Non-BR-Compliant Certificate Issuance

Description:
The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:

1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced.

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ

The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

== Consorci AOC ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== D-TRUST ==

dNSName containing '/'
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ

Short / sequential-looking serial numbers
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ
RESOLUTION: https://groups.google.com/d/msg/mozilla.dev.security.policy/UnR98QjWQQs/O-Hf5T4WBwAJ


== DigiCert ==

https://bugzilla.mozilla.org/show_bug.cgi?id=1389172

== Disig ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== DocuSign/Keynectis ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Entrust ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

== FNMT ==

"AC FNMT Usuarios” intermediate is not supposed to issue TLS server auth capable certs. [KATHLEEN: Add to OneCRL]
https://groups.google.com/d/msg/mozilla.dev.security.policy/Qo1ZNwlYKnY/UrAodnoQBwAJ

== GlobalSign ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

== Kamu SM ==

Serial Numbers less than 64-bit entropy
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ


== IdenTrust ==

pathLenConstraint with CA:FALSE
https://groups.google.com/d/msg/mozilla.dev.security.policy/1q_aq5e0El4/LmfGUDmHBwAJ

OCSP responder URL that has a HTTPS URI
https://groups.google.com/d/msg/mozilla.dev.security.policy/jSHuE-Oc7rY/660iCGPZBgAJ

== Izenpe ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

Serial Numbers less than 64-bit entropy
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ

== Let’s Encrypt ==
RESOLVED (no bug needed)

== Microsec e-Szigo ==

Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== NetLock ==

https://bugzilla.mozilla.org/show_bug.cgi?id=1386894

== Staat der Nederlandend / PKIoverheid ==
RESOLVED (no bug needed)

== SwissSign ==

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ


== Symantec ==

** This bug applies to all Symantec brands, including VeriSign, Thawte, and GeoTrust.

Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

== Taiwan-CA ==

[Kathleen Wilson]

I will proceed with filing these bugs now.

Kathleen

[Kathleen Wilson]

Bugs filed...

== Actalis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390974

== Camerfirma ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977

== Certinomis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390978

== certSIGN ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390979

== Comodo ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390981

== Consorci AOC ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390988

== D-TRUST ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390990

== DigiCert ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1389172

== Disig ==

https://bugzilla.mozilla.org/show_bug.cgi?id=1390991

== DocuSign/Keynectis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390994

== Entrust ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390996

== FNMT ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391095
(This bug is to add the AC FNMT Usuarios certificate to OneCRL)

== GlobalSign ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390997

== Kamu SM ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390998

== IdenTrust ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391000

== Izenpe ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391054

== Let’s Encrypt ==
RESOLVED (no bug needed)

== Microsec e-Szigno ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391055

== NetLock ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391056

== PROCERT ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391058

== QuoVadis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391063

== SECOM ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391064

== StartCom ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1386894

== Staat der Nederlandend / PKIoverheid ==
RESOLVED (no bug needed)

== SwissSign ==

https://bugzilla.mozilla.org/show_bug.cgi?id=1391066

== Symantec ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391067

== Taiwan-CA ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391068

== T-Systems ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391074

== Visa ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391087

== WISeKey ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391089

==

[Weitsong Lin]

TWCA had revoked the miss-issued certificate.


Kathleen Wilson於 2017年8月16日星期三 UTC+8上午3時38分11秒寫道：

[Peter Miskovic]

CA Disig revoked listed non-conforming certificate.

[Gervase Markham]

On 15/08/17 21:24, Kathleen Wilson wrote:
> Mozilla's Root Store policy says: "CAs MUST follow and be aware of
> discussions in the mozilla.dev.security.policy forum, where Mozilla's
> root program is coordinated."
>
> There is no indication about how frequently a representative of the
> CA must check the m.d.s.policy discussions. And what about when a
> CA's representative is on vacation? (e.g. the month of August for
> many CAs) Do we really expect them to monitor m.d.s.policy while on
> vacation? (I don't even monitor it myself while I'm on vacation.)

Yes, indeed. That stipulation was more to prevent CAs claiming lack of
awareness of issues which had been discussed at length, rather than
making it so people can report issues here and count them as properly
reported to the CA. There are no SLAs for CAs reviewing m.d.s.policy,
although ignoring it entirely for a month would suggest to me that the
absent employee should have delegated.

Gerv

[Jonathan Rudenberg]

> On Aug 16, 2017, at 19:18, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Bugs filed...

Hi Kathleen,

It looks like a bug was not created for GoDaddy about these certificates with invalid dnsNames, containing a space at the beginning of the eTLD+1:

https://crt.sh/?id=93578583&opt=cablint
https://crt.sh/?id=110219638&opt=cablint
https://crt.sh/?id=20950698&opt=cablint
https://crt.sh/?id=25047430&opt=cablint
https://crt.sh/?id=108417123&opt=cablint

Additionally, I don’t believe that any communication was received from the following CAs about “double-dot” certificates[0][1] which they revoked after Rob found them and posted here (they are technically a subset of “invalid dnsNames” but the certificates were not listed in any of the threads linked in the bugs).

- GoDaddy
- GlobalSign
- T-Systems
- Symantec

I will post comments on the bugs that are already open for the last three.

Jonathan

[0] https://misissued.com/batch/13/
[1] https://groups.google.com/d/topic/mozilla.dev.security.policy/5bpr9yBgaYo/discussion

[Kathleen Wilson]

Filed bug for GoDaddy:
https://bugzilla.mozilla.org/show_bug.cgi?id=1391429

Thanks,
Kathleen

[Gervase Markham]

On 17/08/17 00:18, Kathleen Wilson wrote:
> == Let’s Encrypt ==
> RESOLVED (no bug needed)

> == Staat der Nederlandend / PKIoverheid ==
> RESOLVED (no bug needed)

While the timely responses and performance of these CAs is commendable,
it may be worth opening a bug and recording the events and the outcome,
so that our bug database remains the canonical source of information
regarding misissuances that Mozilla knows about.

Kathleen: If your bug-filing fingers are not yet entirely worn out,
could they stretch to two more? :-)

Gerv

[Kathleen Wilson]

Let's Encrypt
https://bugzilla.mozilla.org/show_bug.cgi?id=1391867

Staat der Nederlandend
https://bugzilla.mozilla.org/show_bug.cgi?id=1391864

Cheers,
Kathleen