Re: [Trans] Goals and generic mis-issuance fgramework

Eran Messeri <eranm@google.com> Tue, 28 October 2014 16:50 UTC

Return-Path: <eranm@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 167221A90D8 for <trans@ietfa.amsl.com>; Tue, 28 Oct 2014 09:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 k5TY3Q0zthsb for <trans@ietfa.amsl.com>; Tue, 28 Oct 2014 09:50:50 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903891A904B for <trans@ietf.org>; Tue, 28 Oct 2014 09:45:57 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id wp4so845623obc.25 for <trans@ietf.org>; Tue, 28 Oct 2014 09:45:57 -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=A476+VqdSPwXxAItgQpqaDJdq1UieJTdQFJLkqE0ueA=; b=Sue0T3hv2lCIH8cB4JPCQBqXh4FicZ3W9aJXdQVPgE7CwAYu1prtqPMPUysSQ6i39f jFOn0yE1CMkwiIS0ZN1zfMEJACfbaseWqpUXdYs8AxxlIIuFFuSlBa016y1RvAuVd4iS qSMBWgzGFg8HQN4vXGaRuOkL6a/SeV6tqPtWH0fJeXCa5LOpmqd1f4xOEaGNuB2MXpEc J/zbu6C0t932rYLHojKb3d3Le1AOQMAEw0lMb+azpA2KyydnIpWgqpa45cbjSLrYHJ6H jLuGT2+aidcK64zUjfVr8ZBxVvls9wPFBqhb0szaBUf4lC6+j8wlS3q3u3K/3nVC76Rb xzEg==
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=A476+VqdSPwXxAItgQpqaDJdq1UieJTdQFJLkqE0ueA=; b=U9wStXvikb6jsOJhlE1HeDTPAV329OYpBBcwbx5gyyHlt8C80J5ZvSEtJz8boLhyUM lvNgUTjDin66KOrnkGe5kNbSV4LxeonLYGMgPA0CBToDEUYYJC3vlK+QLTEN0m8mR3b4 a2gG43qeWqqtOWfywEArX1xpge36vzGWXxTfYX7u0AF5RX7ufrCG6i4McSpqyNjryhDV e7JozkuIuKIyv/ckevy/AP/Vxez8IAdM/oBDJcne++gwqzUMplzOajL2rp/va2B6UTLi qAnS1inLztuSE+BkgCJk2WvaUwT8URFyq9WKjJ9q6qMFj3vgu7NamS3vm3/qvCTqFuOu R6pA==
X-Gm-Message-State: ALoCoQmwK9yTt2tnD9Yp4oThNW0ZuUVq/XZFI3ksIjDLkF3Pko6Y5sIN9HbomtCgSrAOfIFYpGSQ
MIME-Version: 1.0
X-Received: by 10.60.98.203 with SMTP id ek11mr3708605oeb.29.1414514756896; Tue, 28 Oct 2014 09:45:56 -0700 (PDT)
Received: by 10.182.46.202 with HTTP; Tue, 28 Oct 2014 09:45:56 -0700 (PDT)
In-Reply-To: <4262AC0DB9856847A2D00EF817E81139243728@scygexch10.cygnacom.com>
References: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> <544B0DD62A64C1448B2DA253C011414607D375BE52@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E81139243728@scygexch10.cygnacom.com>
Date: Tue, 28 Oct 2014 16:45:56 +0000
Message-ID: <CALzYgEeei9wC0mi6sBBpp6wJWugh5PwridooyA7qAL+UcNzRLA@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
To: Santosh Chokhani <schokhani@cygnacom.com>
Content-Type: multipart/alternative; boundary="089e01182b729d70fd05067e613d"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/dj9al2RfRQezbBMCIagzt0ZWglU
Cc: "trans@ietf.org" <trans@ietf.org>, Russ Housley <housley@vigilsec.com>, Steve Kent <kent@bbn.com>, Rick Andrews <Rick_Andrews@symantec.com>
Subject: Re: [Trans] Goals and generic mis-issuance fgramework
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: Tue, 28 Oct 2014 16:50:53 -0000

Overall the mechanism described seems reasonable. Can you help me
understand the benefits from the TLS client's perspective?
IIUC, the log will never refuse to include a certificate, it will merely
indicate it failed syntactic checks.
Are you suggesting that TLS clients will reject an otherwise-valid
certificate chain which has a CCID that matches the TLS client's desired
use of the certificate, because the log indicated it failed syntactic
checks?

It's not a bad thing, it does place additional burden on logs though.
Monitors will have to verify the log's honest behaviour on this aspect as
well.

The other question is - aren't certificate classes different enough to
merit running different logs, where the log's identity (or some other
metadata) indicates which CCID it's good for?
I'm a bit weary of specifying a behaviour for the general case where I
don't have concrete examples for more than one particular case.

On Tue, Oct 28, 2014 at 2:09 AM, Santosh Chokhani <schokhani@cygnacom.com>
wrote:

>  Relying parties relying on the checks made by log server may be
> problematic if both do not have the same trust store if the initialization
> variables are different.
>
>
>
> My primary motivation in log doing checks is nip the problem in the bud
> and reduce the probability of relying parties having to decide on
> exceptions.  The relying parties still should validate the certification
> path.
>
>
>
> *From:* Trans [mailto:trans-bounces@ietf.org] *On Behalf Of *Rick Andrews
> *Sent:* Monday, October 27, 2014 6:33 PM
> *To:* Russ Housley; Steve Kent
>
> *Cc:* trans@ietf.org
> *Subject:* Re: [Trans] Goals and generic mis-issuance fgramework
>
>
>
> Russ, comments inline.
>
>
>
> -Rick
>
>
>
> *From:* Trans [mailto:trans-bounces@ietf.org <trans-bounces@ietf.org>] *On
> Behalf Of *Russ Housley
> *Sent:* Saturday, October 25, 2014 10:01 AM
> *To:* Rick Andrews; Steve Kent
> *Cc:* trans@ietf.org
> *Subject:* Re: [Trans] Goals and generic mis-issuance fgramework
>
>
>
> Steve and Rick:
>
>
>
>
>
> 1. Certificate Transparency Goals and Mechanisms
>
>
>
> The goals of Certificate Transparency (CT) are threefold: detection,
> deterrence, and enabling remediation of mis-issuance of certificates. The
> initial focus of CT is the Web PKI context, (The Web PKI context refers to
> the use of a set of Certification Authorities (CAs) that issue X.509
> certificates to web servers to enable TLS-protected access by clients [cite
> WPKOPS?].) In the future, it is anticipated that addition **additional**operational
> contexts may be supported. As a result, mis-issuance is defined in an
> fashion that accommodates a range of types of certificates used in a range
> of contexts.
>
>
>
> CT supports detection of mis-issuance using logs of certificates,
> populated by the CAs that issue them or by the Subjects of certificates.
> Monitors (described in Section *X*) are the primary elements of the CT
> system that check certificates for syntactic and semantic mis-issuance, on
> behalf of Subjects. A Monitor may be operated by a third party on behalf of
> Subjects, or may be operated by a Subject on its own behalf. (The latter is
> referred to as “self-monitoring”.) Logs may optionally perform syntactic
> checks for some classes of certificates, but a log is not required to offer
> certificate checking.
>
> The first sentence needs to be more broad, since anyone can send a cert to
> a log. But it’s most likely to be the CAs or the Subjects, so I would
> suggest “CT supports detection of mis-issuance using logs of certificates,
> populated by the CAs that issue them, by the Subjects of certificates, or
> by anyone with knowledge of the entire certificate chain.”.
>
>
>
> Can't anyone build the certificate chain?  Since the logs are posting the
> supported trust anchors, anyone can build a chain for the end entity
> certificate.
>
>
>
> [Rick] In most cases, yes. If someone has access to the server configured
> with that certificate, they can do a TLS handshake and get the chain in
> nearly all cases. We see some web servers that are missing the intermediate
> CA cert, and some browsers (IE, for example) will follow the AIA extension
> (if it’s in the cert) and fetch the intermediate. Any client can do that
> too. But if the CA didn’t put an AIA extension in the cert and you can’t
> find a server with that cert, it might not be possible to find the
> intermediate CA cert. And without the intermediate (or intermediates!) the
> log won’t accept it.
>
>
>
> To enable Monitors (and, optionally, logs) to perform an appropriate set
> of checks, the (pre-) a CCID MUST be provided to a log when a certificate
> is submitted by a CA or Subject. This CCID MUST appear in the log entry and
> in the SCT generated by the log. By providing the CCID in logs and SCTs,
> both Monitors and clients are empowered to perform applicable checks based
> on the certificate class asserted by the CA or Subject.
>
> Hmm… Since anyone can send a cert to a log, the first sentence must
> reflect that. But that makes me wonder what should happen if the “Reporter”
> (I don’t want to introduce a new role) sends the wrong CCID? (By “wrong” I
> mean it’s a valid CCID, but it’s not the one that the CA would associate
> with the cert.) Or sends the cert multiple times with different CCIDs? I
> guess Monitors would have to expect multiple entries for a given
> certificate in a given log, with different CCIDs. I’m not sure if 6962-bis
> imposes any uniqueness constraint that this might violate.
>
>
>
> Alternatively, a log could check to see if the reported certificate is
> already present, and if so, return the older entry to the party that
> reports the certificate.  I seem to recall reading this idea at some point,
> buy I admit I did not look into the current I-D to see if that was where i
> read it.
>
> [Rick] RFC 6962 and bis-04 say “If the log has previously seen the
> certificate, it MAY return the same SCT as it returned before.” But this
> would have to be expanded to say “If the log has previously seen the
> certificate *and CCID*, it MAY return the same SCT as it returned
> before.” It’s a bit more complex, since the log server may not support the
> CCID or any checking, in which cases it would always log the entry with
> CCID =1 that indicates “This log does not perform syntax checks”, or CCID=2
> that indicates “This log does not support syntax checks for the asserted
> CCID”.
>
>
>
>
>
> A log MUST generate a Syntax Verification Value (SVV) for the certificate,
> and include the SVV in the log entry and in the SCT.
>
> The LVV **SVV** is **a** value specified by this document (see Section Z)
> that indicates whether or not the log performed applicable syntactic
> checks, and whether the (pre-) certificate passed of **or** failed the
> checks. Although it is anticipated that new certificate classes will arise
> over time, the set of log actions with respect to syntax checking appears
> to be well-defined and thus need not be represented in an IANA registry.
> Each SCT issued by a log MUST include an SVV.
>
>
>
>
>
> Value Interpretation
>
> 0                 The CCID value was 0, so not **no** checks were
> performed
>
> 1                 This log does not perform syntax checks
>
> 2                 This log does not support syntax checks for the
> asserted CCID
>
> 3                 This log performed the syntax checks for the asserted
> CCID, and the certificate passed
>
> 4                 This log performed the syntax checks for the asserted
> CCID, and the certificate failed
>
>
>
> No other SVV values are defined by this RFC.
>
>
>
> If the log performs some validation checks, are you suggesting that a
> relying party can leverage the work already done by the log?  If so, it
> puts the log checking at a different place in the certificate validation
> than I was imagining.
>
> [Rick] Yes, a relying party could leverage the work already done by the
> log server, if the RP trusted it. Google would probably advise against
> this, since they have been pretty consistent in saying that CT doesn’t
> require you to trust anyone including the log server.
>
>
>
>
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>