Re: [Trans] defining "mis-issuance"

[Rick Andrews <[e-mail]>]

Stephen,

Great work here. It's clear you've taken a lot of time and care to go through the documents with a fine-toothed comb. I have some answers/comments below:

> The CABF Guidelines establish a lot of requirements that are purely syntactic and thus
> could be checked by a log operator, before agreeing to issue an SCT. I want to suggest
> we consider that as a possible change to the current design.

I think this idea has merit. In a separate thread, I asked Google to remove some of Symantec's roots from their log servers' trust store, because we have never and don't ever expect to issue EV certs from those roots (the current implementation of CT is required for EV only). I pointed out that by removing those roots, the log server could _prevent_ an unintended mis-isuance rather than just record it. Google didn't agree with me.
https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/DHf74DdO2rs

Also, although I like the idea of log servers rejecting syntactically-invalid certificates, that may create problems for CAs because the CABF requirements have changed over time and will likely change in the future. Any changes would have to be rolled out to log servers and browsers in time to prevent rejection of a valid certificate.
A.1 Syntactic Verification of a Domain Validation Certificate
(Is there a better reference for EV certificate policy OIDs?)
I might suggest Chrome's source code itself: https://code.google.com/p/chromium/codesearch#chromium/src/net/cert/ev_root_ca_metadata.cc&sq=package:chromium
2. serialNumber: No requirements beyond those imposed by [RFC5280] are mandated by [CABF-Baseline]. ([CABF-Baseline] requires that a serial number contan at least 20 bits of entropy (see Section 9.6, but it not clear how this can be verified through syntactic examination of a certificate.)
[CABF-Baseline] says it's a SHOULD, not a must, although I agree that it can't clearly be verified, except at the extreme where the serial number is less than 20 bits long.
 6. subject: A certificate MAY contain a NULL Subject name If it contains a non-null Subject name:
There's a period missing before "If".
2. A certificate issued to a CA  MUST include the certificatePolcies extension. It may r MAY NOT be
Typo: "r" -> "or"

C. localityName, stateOrProvinceName (if applicable), and countryName attributes. This requirement is derived from section 9.3.1 of [CABF-Baseline]. (How does one know whether the stateOrProvinceName is applicable?)

I think bullet point C is a copy and paste error, and should be removed. Your question, though, is relevant. This is an open question. At the last CA/Browser Forum face-to-face meeting, some CA attendees indicated that they had difficulty as there are many countries with no states/provinces, like "Bouvet Island", "British Virgin Islands", "Christmas Island", "Falkland Islands", "Faroe Islands", "French Guiana", "Gibraltar", "Guadeloupe", "Guam", "Guernsey", "Isle of Man", "Jersey", "Lebanon", "Macedonia", "Martinique", "Mayotte", "Montenegro", "Netherlands Antilles", "Niue", "Norfolk Island", "Palestinian Territory", "Pitcairn", "Reunion", "Serbia", "Singapore", "Slovenia", "South Georgia and the South Sandwich Islands", "Svalbard and Jan Mayen", "Western Sahara", "Vatican", Taiwan, etc. I expect we'll debate this further in the Forum and perhaps change [CABF-Baseline].
4. The cRLDistributinPoints extension MUST be present in a CA certificate. It MUST NOT be marked
Typo: "cRLDistributinPoints" -> "cRLDistributionPoints"
6. The authorityInformatinAccess extension MAY be present and, if present, MUST NOT be marked
Typo: "authorityInformatinAccess" -> "authorityInformationAccess"

A.2 Semantic Verification of a Certificate
Nonetheless, a Monitor can "protect" specific Subjects, based on reference data provided by these Subjects. A Monitor trying to determine that a certificate has been issued to the "right" Subject can do so using the certificate(s) issued to the Subject, as a reference. For example, if a Monitor is providing "protection" for a Subject, it requires the name of the Subject (as it appears in the Subject field or subjectAltName extension) and the public key associated with that Subject. Armed with this information, a Monitor can examine every log entry to determine if it contains the same Subject or SubjectAltName. If a log entry matches either of these names, and if it contain a different public key, this is evidence of mis-issuance.
There's no requirement that a Subject be associated with a single public key. In some cases, web site owners generate a different key pair on each machine behind a load balancer, and apply for certificates with the same Subject name but different key.
I'm not sure if you've captured the type of mis-issuance that CT was originally intended to detect: when a hacked, faulty or rogue CA issues a certificate to a Subject without the Subject's knowledge. The Monitor alone cannot detect that. It can report to the Subject that a certificate was logged for the Subject, but only the Subject can tell if that was a valid issuance or mis-issuance.
-Rick