Re: [Trans] defining "mis-issuance"

Rick Andrews <> Mon, 29 September 2014 22:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8DFE51ACD5E for <>; Mon, 29 Sep 2014 15:26:49 -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_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IMTNNSOENYzO for <>; Mon, 29 Sep 2014 15:26:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CF0F1ACD40 for <>; Mon, 29 Sep 2014 15:26:46 -0700 (PDT)
X-AuditID: a66201d2-f79186d0000034ee-2d-5429dca3aa12
Received: from ( []) by (Symantec Brightmail Gateway out) with SMTP id AC.45.13550.3ACD9245; Mon, 29 Sep 2014 22:26:43 +0000 (GMT)
Received: from [] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by with esmtp (Exim 4.76) (envelope-from <>) id 1XYjP0-000BRC-UB; Mon, 29 Sep 2014 22:26:42 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([]) with mapi; Mon, 29 Sep 2014 15:26:42 -0700
From: Rick Andrews <>
To: Stephen Kent <>, "" <>
Date: Mon, 29 Sep 2014 15:26:41 -0700
Thread-Topic: [Trans] defining "mis-issuance"
Thread-Index: Ac/b9LgDW7Z92AnbSPiCoFCLE8cnvAADGG1g
Message-ID: <544B0DD62A64C1448B2DA253C011414607D174DEB1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <> <544B0DD62A64C1448B2DA253C011414607D1628D70@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607D174DEB1TUS1XCHEVSPIN_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsWyLInRVXfxHc0Qg3/dihYbZzNarH18kcWB yWPq+VCPJUt+MgUwRXHZpKTmZJalFunbJXBlbOy8x1qwI6di15Ru1gbGFbFdjJwcEgImEpMb 1rFD2GISF+6tZwOxhQQ+MkqcvKoFYb9ilNjz1bqLkQvIXsUo8Xx5IxNIgk1AT2LL4ytgzSIC ThL3u9+AxVkEVCWezt3FCGILC+hItG/sZIKo0ZU4dL+DBcI2klj89R5YL69AlMSXjvOsEAum MEpc3bEU7ApOAXWJx0+fsILYjEDXfT+1BmwQs4C4xK0n85kgrhaQWLLnPDOELSrx8vE/qHpR iTvt6xkh6vMl7syaxQKxTFDi5MwnLBD1khIHV9xgmcAoNgvJ2FlIWmYhaYGI60gs2P2JDcLW lli28DUzjH3mwGMmZPEFjOyrGGVSk3MMc0sS80tLClIrDIz0iitzE4HxmKyXnJ+7iRESk5d2 MN4/rHuIUYCDUYmHd/5qzRAh1sQyoMpDjBIczEoivHI7gEK8KYmVValF+fFFpTmpxYcYpTlY lMR5U0I4QoQE0hNLUrNTUwtSi2CyTBycUg2MjjmTpOz7+/1qBfe7RFfOLovMf6IndnrLCkGx G8tOTr55PcPuXqGOz6kyi7tebBMnuTw9zha1c2kSC9vj8HmCcokLJs9ZUpXS67/edr50EMe/ qzfCXyxw5XxW3+rJHRhyxya32enyEp4Oi6zbh5jYXLgnbIlUKPXqXBwUF33Fw/V0wxXFXgUl luKMREMt5qLiRACuEaHYxQIAAA==
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: Mon, 29 Sep 2014 22:26:49 -0000


You said "Your observation about the need to coordinate CABF requirements changes with what log servers
would check gave me an idea. Why not have the add (pre-cert) chain to log request specify
whether the cert being added is to be checked against DV or EV specs, and note the version
of the DV/EV spec to be used? This would make it easy for the log to know which set of
checks to employ. Since each log needs to advertise a set of data about itself anyway
(e.g., what root CAs it supports), it could also advertise the set of specs against which
it is prepared to check submissions. This way a CA or Subject would know whether the log
was prepared to accept a chain for checking under the selected criteria. Note that a Monitor
could not perform checks as easily, because it does not interact directly with the entity
submitting the log request. I think that argues for logs performing these checks."

It's doable, but it still leaves the CA in a bind. What if the CA wants to start issuing certs according to new CABF docs, but finds that none of the existing log servers support that version? This is probably a moot point, isn't it, because Melinda has reminded us not to introduce any normative dependencies on CAB Forum documents or processes.

Your observation is correct; that's what I get for trying to write a quick description of
the algorithm for this.  Accommodating multiple keys per Subject is easy to fix.
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(s) 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 public key other that the one(s) provided by the Subject, this is evidence of mis-issuance.

If the Subject provides a list of all o the keys associated with the Subject, perhaps in the form
of certs issued to the Subject (and currently valid) this would enable a Monitor to detect this form of mis-issuance, agreed?
Agreed, but it puts a burden on the Subject. Before issuing any new legitimate certificate, the Subject would need to notify the Monitor of the new Subject name and/or public key. We've got some customers who issue thousands of certificates across their organization. IMO, the model might work better if the Monitor is simply a conduit, providing information found in log servers to the Subject, and then the Subject can decide if each new certificate was intentionally issued.

A separate topic is issuance of a bogus cert for a Subject who doesn't have a cert issued legitimately.
In this case there is no reference cert to present to a Monitor. It may be hard for a Subject who
doesn't have a cert to convince a 3rd party Monitor to check for certs issued to the Subject name
in question. Should we classify this as mis-issuance as well?
See my comment above. Must the Monitor be able to decide by itself what is legitimate and what is mis-issued, or is that the role of the Subject, with help from the Monitor? In other words, couldn't we say that it's mis-issuance if the Monitor finds a cert in a log, forwards it to the Subject, and the Subject determines that it's mis-issued?