Re: [Trans] defining "mis-issuance"

Ben Laurie <benl@google.com> Fri, 03 October 2014 15:10 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D781A0258 for <trans@ietfa.amsl.com>; Fri, 3 Oct 2014 08:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvE1LrKHlIDw for <trans@ietfa.amsl.com>; Fri, 3 Oct 2014 08:10:33 -0700 (PDT)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A281A0295 for <trans@ietf.org>; Fri, 3 Oct 2014 08:10:33 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id c9so1119030qcz.23 for <trans@ietf.org>; Fri, 03 Oct 2014 08:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.140.96.104 with SMTP id j95mr6416109qge.106.1412349032221; Fri, 03 Oct 2014 08:10:32 -0700 (PDT)
Received: by 10.229.247.198 with HTTP; Fri, 3 Oct 2014 08:10:32 -0700 (PDT)
In-Reply-To: <542D79B5.7080508@bbn.com>
References: <542477E3.8070304@bbn.com> <544B0DD62A64C1448B2DA253C011414607D1628D70@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542971A7.7030700@bbn.com> <544B0DD62A64C1448B2DA253C011414607D174DEB1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C1846.7060303@bbn.com> <542C1EA6.8050106@comodo.com> <542D79B5.7080508@bbn.com>
Date: Fri, 3 Oct 2014 16:10:32 +0100
Message-ID: <CABrd9SR7imHk2cvYswHbvvMvQgwV2PcMdhiWqP-4pY7UBuaQ7A@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-hy_VwD-lGltVtpPwGepwxEUDOA
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] defining "mis-issuance"
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Oct 2014 15:10:38 -0000

On 2 October 2014 17:13, Stephen Kent <kent@bbn.com> 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
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans