Re: [Trans] defining "mis-issuance"

Ben Laurie <> Fri, 03 October 2014 15:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8D781A0258 for <>; Fri, 3 Oct 2014 08:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rvE1LrKHlIDw for <>; Fri, 3 Oct 2014 08:10:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89A281A0295 for <>; Fri, 3 Oct 2014 08:10:33 -0700 (PDT)
Received: by with SMTP id c9so1119030qcz.23 for <>; Fri, 03 Oct 2014 08:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+TJrQm8Y8FTX5YEgJzn+6vvMNrFKH4KRBBLGP7ibE0Y=; b=KVbt+ojEGyfqkIZCgVRXrCuz2uULCjlegz2SfeQANaltFUdDQABRbVztHTDqttNg5e tZeIfMlpzlIxc/aEk4qZr90Ig7J2GW5pLbFImpeKFzOEaMUjcQ/F84V8DMk/Riy6JCz5 MxY/ZPRcnv1dd/g4hSkQ4ilk5pYfQatMYWl/NsulYczt3+9Y144pU80sPaHK8/LqRASD ypDGx3Fhpz5Wl20kzEU2ByFiAXNn9Jjn9TfDk3dwppgnJ3iiOo+1X/NDAUAk7KJfrxkM klYGW5wPSUSJqfnx70NfaN8QAW4tJcFwKHGQpvyGtmQ66VJsZZFYvsxVGjIHL5Ta+1Ha hnZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+TJrQm8Y8FTX5YEgJzn+6vvMNrFKH4KRBBLGP7ibE0Y=; b=LjJK4FtEwDHKTe6bxi/RMs3TvoVbpTI7jsrMFtsBlu5VSilxgAehNf+7MfIw0fp0tr A4AB7DdmIiKEMGhuK6ldYIzqbWQ2jORPzyzcY5mwEoGUfYaOL84z4oBDWph+xnwzBSmG NE7kmbuIM1EEjMomESDWZ0vkrC1rokxsbCL7QF6VCSa6e/SpoGVLY4lBeEaWq6zGn+Ub sf5IXu02iGNBkpGola4gQlHxImEnPLIb/a2dloBwBzYYlZvmSwViYjbBEH3FFJuWmUGL +15E3fxfsJLRw3/4ekUDIVTQf/BRi21bMlrTZ6gPiy+9QVG5mWgykb2WDmny5eZc0WQR KGww==
X-Gm-Message-State: ALoCoQl22EeFr4Ku1AtgAHcInJd66vXS2EcQQdw7kZA1d63mZm9vPRqKvY8+W0SWGgkw4p5zKVJC
MIME-Version: 1.0
X-Received: by with SMTP id j95mr6416109qge.106.1412349032221; Fri, 03 Oct 2014 08:10:32 -0700 (PDT)
Received: by with HTTP; Fri, 3 Oct 2014 08:10:32 -0700 (PDT)
In-Reply-To: <>
References: <> <544B0DD62A64C1448B2DA253C011414607D1628D70@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <> <544B0DD62A64C1448B2DA253C011414607D174DEB1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <> <> <>
Date: Fri, 3 Oct 2014 16:10:32 +0100
Message-ID: <>
From: Ben Laurie <>
To: Stephen Kent <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
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, 03 Oct 2014 15:10:38 -0000

On 2 October 2014 17:13, Stephen Kent <> wrote:
> Rob,
>> On 01/10/14 16:05, Stephen Kent wrote:
>> <snip>
>>> Rick,
>> <snip>
>>> Still, your point is a good one.  We could push the syntax checking back
>>> to Monitors, but then we loose the ability to provide immediate feedback
>>> to CAs that are issuing syntactically malformed certs. I'll have to think
>>> more about this issue.
>> Stephen,
>> The "ability to provide immediate feedback to CAs that are issuing
>> syntactically malformed certs" sounds like a nice idea, but surely this
>> could be implemented as a stand-alone application or web service?
>> Why would you want it to be an intrinsic part of CT?
> The motivation for making it part of CT arose when Ben explained that his
> definition of mis-issuance included syntactic constraints from the CABF
> context.  The notion that immediate feedback is
> desirable is consistent with the overall CT goal of forcing CAs to do
> something by threatening
> that there certs will be rejected by browsers, only translated to logs :-).
> Still, your argument that logs ought not reject certs that fail to meet
> syntactic criteria,
> so that all TLS clients can benefit from detection of mis-issued certs
> detection via
> examination of logs, is compelling.
> I have a suggested solution:
>     - require a CA submitting a pre-cert to assert one of the following:
>         1. no assertion is made wrt syntactic conformance to CABF guudelines
>         2. the cert conforms to DV Guidelines <insert guideline version>
>         3. the cert conforms to EV guidelines <insert guideline version>
>     - require a log to include the CA assertion in its SCT, along with one
> of the following:
>         1. this log does not check cert syntax
>         2. this log cannot check the specified CABF Guidelne version
> asserted by the CA
>         3. this log checked the cert against the CA's assertion and it
> passed
>         4. this log checked the cert against the CA's assertion and it
> failed

Presumably this would apply to certs as well as precerts, which is the
other reason rejecting isn't particularly helpful (certs are already
issued by the time they're logged!).

> This would seem to address the concern that rejecting (not logging) a
> submitted cert is
> worse than logging a bad cert. It also addresses the concern that Rick
> mentioned, i.e.,
> a mismatch between what Guideline version a CA is using vs. what a log can
> verify. It
> does not require that every log perform ANY syntax checking, and it lets
> Monitors and
> clients know whether a log has elected to no perform such checks. It also
> tells a Monitor
> which set of cert syntax rules the CA says it is enforcing, so that the
> Monitor can perform
> the checks. If the log doesn't perform checks, or is unable to check a
> specific version of
> the syntax checks, the Monitor can step in do so. The Monitor also can
> double check the
> log, to detect logs that are not doing the checks properly, e.g., because of
> errors, compromise,
> or conspiracy. This provides Monitors and clients with additional info when
> choosing which logs
> to use.
> Would this mechanism address your concerns?
> Steve
> _______________________________________________
> Trans mailing list