Re: [Trans] Goals and generic mis-issuance fgramework
Eran Messeri <eranm@google.com> Wed, 29 October 2014 11:32 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 D24C21A001A for <trans@ietfa.amsl.com>; Wed, 29 Oct 2014 04:32:17 -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 jLGYejFhVeSV for <trans@ietfa.amsl.com>; Wed, 29 Oct 2014 04:32:14 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89CC1A0015 for <trans@ietf.org>; Wed, 29 Oct 2014 04:32:13 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id m8so2171840obr.24 for <trans@ietf.org>; Wed, 29 Oct 2014 04:32:13 -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=BvGr+KMpeELQG74+sV1Uvj1iXeELZzM33zR4I/HBkIg=; b=mQzhtim0qgHS29jFi1v+/RSJ5nepwvnPT2i6N13CpcHKEg3/SjacGW1hqjBtB7RiyL fZFM6N5UI4kfuRoNZ7G0OfGH7b2OqF5kCib+T/pu2r9iIE9DMOubA0Ugpw6jSWxCWeno c4aSh9FQeYKnK0JUh2Ntnzd6juVDZmtJC5eVR/LENZw+fg+TLodT23u8HGgByd8c5G3G rOzCyodUG5px+uKcFZEXKP1RXN3qB7R4jyZg6QAOAAc0LtBVmkcbUeUmnT/zZOw6//Fy pBHOT1E953nKfXMQZo3v3vgPeeZoYMWsvkC210W2ieXqBzfKmnOlxnzPjf/52f4veG3A QTVA==
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=BvGr+KMpeELQG74+sV1Uvj1iXeELZzM33zR4I/HBkIg=; b=Gc/JP3bRJKxCj0sHWkC3Ntj/dSzp5QDV2HR/ftXzRe8xUf3CAUfg/DCqMqC2e3hUGD abfeNMH1DUMcBYYKLAJftb9jnLo3hBHgXQH5kjO1op0Z+IsvvMxF7aHWNVmRj8ZRMxSW Fw/lF9dpK2PEegicRyaWJTkxsC0ENcgGIhRdzpxD7iS09s+b57hOsVD6K/xI49GwvD0y Nc5WdV65W51L9Ux/wovEpe1VCL5B2BhTqvuW8XZBadfGKpdm9UF/tomoDc/JWvZiCkwO Xf/3KRkgo9QuPEpmERvahlkNtXWKcbYWKrxLaApOjDx4Qq9dKXhUE3p7g6IhM2Ccg0bM 6eSg==
X-Gm-Message-State: ALoCoQmYpoGEp96oTFmQkQlnl3GzkSgnqjcLW5FCkdXZVnnsajHoqzZzUkYHR/OvBfuYciseNllm
MIME-Version: 1.0
X-Received: by 10.202.88.66 with SMTP id m63mr7728007oib.11.1414582332960; Wed, 29 Oct 2014 04:32:12 -0700 (PDT)
Received: by 10.182.46.202 with HTTP; Wed, 29 Oct 2014 04:32:12 -0700 (PDT)
In-Reply-To: <4262AC0DB9856847A2D00EF817E81139243DF5@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> <CALzYgEeei9wC0mi6sBBpp6wJWugh5PwridooyA7qAL+UcNzRLA@mail.gmail.com> <4262AC0DB9856847A2D00EF817E81139243DF5@scygexch10.cygnacom.com>
Date: Wed, 29 Oct 2014 11:32:12 +0000
Message-ID: <CALzYgEf4k-+AXytSfNJiwJ_qbA_1_HV3hSb6a8Ney6xr8R4-sQ@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
To: Santosh Chokhani <schokhani@cygnacom.com>
Content-Type: multipart/alternative; boundary="001a113d5d127663c505068e1dbb"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/LETqb7ag_hfnHyW5d9HrKmzEtPM
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: Wed, 29 Oct 2014 11:32:18 -0000
In that case, how about including the CCID and the results of the checks the log performed in the get-sth response, but not in the SCT itself? The log could still sign the complete get-sth reply so submitters get a confirmation it is indeed the log which performed the checks, and TLS clients will not be burdened with handling another field in the SCT there's no immediate use for. As I said, I see the value in getting an "independent opinion" on the validity of a chain submitted to the log (both in syntactic and semantic compliance perspectives) and is much more useful than the current error handling approach (where the log returns a vague error). I just like to exclude this information from being embedded in the SCT if it's not useful for TLS clients. On Tue, Oct 28, 2014 at 7:27 PM, Santosh Chokhani <schokhani@cygnacom.com> wrote: > Eran, > > > > See in-line below. > > > > *From:* Eran Messeri [mailto:eranm@google.com] > *Sent:* Tuesday, October 28, 2014 12:46 PM > *To:* Santosh Chokhani > *Cc:* Rick Andrews; Russ Housley; Steve Kent; trans@ietf.org > *Subject:* Re: [Trans] Goals and generic mis-issuance fgramework > > > > Overall the mechanism described seems reasonable. Can you help me > understand the benefits from the TLS client's perspective? > > *[Santosh] The primary benefit would have come if the log had enforced and > not registered a mal-formed certificate. Log acceptance of certificate > seems to what the WG prefers. In that case, benefits to the client are > reduced. * > > > > 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? > > *[Santosh] That could be one thing. What I was saying in the thread is > that even if the Log said that the certificate passed the checks, client > must do its own path validation unless the client and log are using the > same chain and same 5280 path validation initialization variables.* > > > > *One advantage of logs doing checking and rejecting the certificates is > that the human user will not go through the error-prone decision making > about the security ramification of failed path validation.* > > > > 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. > > *[Santosh] To my knowledge, lot of path checks are the same. Different > classes of certificates may warrant checking KU, EKU and extracting and > matching names from different fields (say Subject DN or SAN).* > > > > 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