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
>
>
>