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 > >
- [Trans] Goals and generic mis-issuance fgramework Stephen Kent
- Re: [Trans] Goals and generic mis-issuance fgrame… Rick Andrews
- Re: [Trans] Goals and generic mis-issuance fgrame… Stephen Kent
- Re: [Trans] Goals and generic mis-issuance fgrame… Russ Housley
- Re: [Trans] Goals and generic mis-issuance fgrame… Rick Andrews
- Re: [Trans] Goals and generic mis-issuance fgrame… Santosh Chokhani
- Re: [Trans] Goals and generic mis-issuance fgrame… Eran Messeri
- Re: [Trans] Goals and generic mis-issuance fgrame… Rick Andrews
- Re: [Trans] Goals and generic mis-issuance fgrame… Santosh Chokhani
- Re: [Trans] Goals and generic mis-issuance fgrame… Eran Messeri
- Re: [Trans] Goals and generic mis-issuance fgrame… Santosh Chokhani
- Re: [Trans] Goals and generic mis-issuance fgrame… Stephen Kent
- Re: [Trans] Goals and generic mis-issuance fgrame… Phillip Hallam-Baker
- Re: [Trans] Goals and generic mis-issuance fgrame… Stephen Kent
- Re: [Trans] Goals and generic mis-issuance fgrame… Stephen Kent