Re: [Trans] defining "mis-issuance"

Rick Andrews <> Fri, 26 September 2014 18:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 752BD1A0277 for <>; Fri, 26 Sep 2014 11:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CXE1Mt7QcC97 for <>; Fri, 26 Sep 2014 11:46:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50BA81A01C6 for <>; Fri, 26 Sep 2014 11:46:42 -0700 (PDT)
X-AuditID: d80ac3f1-f791a6d0000069e3-df-5425b4824fb9
Received: from ( []) by (Symantec Brightmail Gateway out) with SMTP id 76.19.27107.284B5245; Fri, 26 Sep 2014 19:46:26 +0100 (BST)
Received: from [] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by with esmtp (Exim 4.76) (envelope-from <>) id 1XXaXC-00018e-AJ; Fri, 26 Sep 2014 18:46:26 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([]) with mapi; Fri, 26 Sep 2014 11:45:35 -0700
From: Rick Andrews <>
To: "" <>, "" <>
Date: Fri, 26 Sep 2014 11:45:34 -0700
Thread-Topic: [Trans] defining "mis-issuance"
Thread-Index: Ac/Y/ZR5dSqWRMndTiy2udBRQmdMrgAtnU9Q
Message-ID: <544B0DD62A64C1448B2DA253C011414607D1628D70@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607D1628D70TUS1XCHEVSPIN_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsVyg+vQH92mLaohBvdO6FtsnM1osfbxRRYH Jo+p50M9liz5yRTAFMVlk5Kak1mWWqRvl8CV8XX2afaCIwsYK1asm8HYwPi7h7GLkZNDQsBE 4tjhI+wQtpjEhXvr2boYuTiEBD4wSjR+7GeCcF4xSlxYfBvKWcUo0bP8NwtIC5uAnsSWx1fA 2kUEXCSuHZwAFmcRUJX4PnMHE4gtLKAj0b6xkwmiRlfi0P0OoBoOINtI4sVXSZAwr0CUxO7m JrASIQE1iTeXJjGD2JwC6hJ7/jWA2YxA130/tQashllAXOLWk/lMEFcLSCzZc54ZwhaVePn4 HytEvajEnfb1jBD1+RIN+9YxQewSlDg58wkLRL2kxMEVN1gmMIrNQjJ2FpKWWUhaIOI6Egt2 f2KDsLUlli18zQxjnznwmAlZfAEj+ypGmZLSYsPi3JL80pKC1AoDQ73iytxEYEwm6yXn525i BMfl4Y87GI/udTzEKMDBqMTD27NSNUSINbEMqPIQowQHs5IIr+IqoBBvSmJlVWpRfnxRaU5q 8SFGaQ4WJXHeTyEcIUIC6YklqdmpqQWpRTBZJg5OqQZGE6/rh7YtuMPO4vn2SJLesVtu9qsm flp9SrqgVO/4jUUX7HaUdoq8NphdVH3X73nASt95PBIX+C5ucIjlOzl/jtB9rSCH8qPnU2uO KcQ4HVz/3P/0tmkZiZrnt7rEn1C+J9fT5v1V7yufVs2rS8oX/FxfTOxOua714CXTg+Tjpe92 a6WoV/Y8UWIpzkg01GIuKk4EAEoGRNLHAgAA
Subject: Re: [Trans] defining "mis-issuance"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Sep 2014 18:46:47 -0000


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.!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:
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.