From nobody Wed Oct 1 06:46:02 2014 Return-Path: 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 508101A8A60 for ; Wed, 1 Oct 2014 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_34=0.6] 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 Uhk7Gzu6nlXp for ; Wed, 1 Oct 2014 06:45:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 292E01A1A06 for ; Wed, 1 Oct 2014 06:45:59 -0700 (PDT) Received: from [10.70.10.54] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 11F42F984 for ; Wed, 1 Oct 2014 09:45:55 -0400 (EDT) Message-ID: <542C0587.3080702@fifthhorseman.net> Date: Wed, 01 Oct 2014 09:45:43 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0 MIME-Version: 1.0 To: "trans@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iWdL78tc0plxvjdCBseBXBrGfSugk6Q1a" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bD-63lXAeoVvhICfgJFNEFjuPbw Subject: Re: [Trans] Proving certificate freshness X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:46:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iWdL78tc0plxvjdCBseBXBrGfSugk6Q1a Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/30/2014 11:56 PM, David Leon Gil wrote: > Something that is rather difficult to prove, at present, is that a > certificate has been used after it has expired or been revoked. To be clear, this is a concern because it's otherwise possible to claim abuse of a revoked/expired cert without being able to substantiate the claim. That makes reports of cert misuse less trustworthy, which makes it harder to act on them. However, CT is designed to detect (and hopefully deter) misissuance, not misuse. Is this scope creep? How would a certificate holder act on a report of misuse of a revoked/expired certificate? clearly, revoking the certificate isn't sufficient :) Maybe such a proof could be used to get browsers to push the key into their internal blocklist instead of relying on our existing flawed network-based revocation mechanisms? Would we want to do anything else besides "revoke harder" upon proof of certificate/secret-key misuse? > If servers were required to include a signature over a recent STH (or > STH+OCSP staple) along with their SCT, this would provide an easy way > of showing that a *server* was behaving incorrectly.=20 I think you're talking specifically about the end-entity doing this, and not any of the CAs in the CA chain. My comments below are based on that assumption. > E.g., as a TLS extension: >=20 > struct { > STH; > sign(SignedCertificateTimestamp || OCSP || STH); > } FreshnessProof; Are your || symbols here "or"s or concatenation operators? > This seems rather better than signing a timestamp; the STH isn't > predictable without a colluding log, so it isn't possible to > "accidentally" sign a future time. I agree that signing a recent STH or OCSP response is better than signing a raw timestamp on its own. Is there a reason that this needs to be an STH, though? Put another way, should this be discussed on the tls@ietf.org instead of trans@ietf.org? If a certificate is required to staple a recent-enough OCSP response (e.g. via one of the proposed "must-staple" x.509v3 extensions), and it is expired/revoked, no OCSP response is available. Presumably, clients would simply not accept connections from a host offering such a certifica= te. So what does this signature add? Performance-wise, at worst it's an additional secret key operation per TLS handshake, but the same signature could be cached and reused until the next scheduled OCSP or STH fetch, which should be minimal. --dkg --iWdL78tc0plxvjdCBseBXBrGfSugk6Q1a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJULAWHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcjvIQAMPMKtOmlHyoke86TldWNTx8 FC9sz1bSDamBzIy1NR2B98ks61P5SdPGIx/+PGqY//3dU1d6ATpjzVNq4+3bjNYO /SEaPhK6aOzTeCaq+XK0UKhIJFtd7vdK1/SVEw/B+IRNodykhX34Eqqa02PdupTl 3IjMRZWsfPQ+y61dLHw/TMPdF+E0M0EgWJE7sjUOYAI/SvrGlly6BSeCD3EejkRS O1ejydSqn4CpyxMW0PHF+ChgKHKon9pfbjJ122c/14laActjBScjSPBZAT2OOb1i 7fclvQBo0iptvTCD7hV18dHSWSPnpvQ+kMYD/77wTDyE1n3Lt4LosNfk08CWwALX xtQNvfspPbYoatAXopDy2LfHFzdLdZNDmXf23aJLnP6omiAdxIVSqfc1brQMj6sI Tdrwc9eyHP6yZEl/ygaFTQ902z+r38YtMQADvGqBIEn1eMK/LDsuWsq3os/VmA+g j0px/T46ruJz9oIP6ntuYpPjURA7u5+bW5HmWF2fFcipJg4azaPVXt/SysokU8e0 vtIntRWoXnmUbvS5lRHieVAzobk0SMHN8HKCl8IfH4qMkH2I6Q7gZbKxHSZy1pca TIHmUOHL28il/PNIsobY773H8GVP+Mphn9cz1bv+syiK/oQnVQFh6hVz7fsAQUo9 AgT4Xg1K0SJ6Fw3d86aR =HQCu -----END PGP SIGNATURE----- --iWdL78tc0plxvjdCBseBXBrGfSugk6Q1a-- From nobody Wed Oct 1 06:59:44 2014 Return-Path: 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 1758C1A19EE for ; Wed, 1 Oct 2014 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 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, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 WvPl4KqK90B0 for ; Wed, 1 Oct 2014 06:59:42 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d: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 1F7431A87E2 for ; Wed, 1 Oct 2014 06:59:42 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so322996qcv.24 for ; Wed, 01 Oct 2014 06:59:41 -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=zn0opS7mGrqSQi87bDQ4qcz3ymBu0qKHfD8TjgPIeRk=; b=Ht4ZtgurIPHpyWfdFLH/LP5yoF3LBvL1ZpTnh2G6hp6gDK1V2DxSFnx3BoFNrgluX6 osc+TFrd1CtweX3K5s38NjXHhi5oGL/LZ0+yRPyDskvWG5f/3Dp4ghn5hsf5+6EoVuOd BE/voZuqxOBYfHoBcBkOVOrwOVnRJwZjuZqiVVOH4OkW7Qg24G6yPIb8ZBGPzZOLFA3U /2/KkeH1MzgCyrHpLN0gUMoL9ag6GzWUCRDMjefa/79KTMfJ7UkKN8QU/d8ADqGL17JZ u1/IFGBfPpAk+PPyqSvd+aBUC41n+Pjk2c98DJxye6MKbmOiobYvyM1b825RchEI6pv5 0s3g== 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=zn0opS7mGrqSQi87bDQ4qcz3ymBu0qKHfD8TjgPIeRk=; b=L/lhQILjOfTstEhnramNp7ZATSkiLe9Z5SPNuUyvq2qL/7VLnYv4/pEqM5BUlMTUrM ysF1cDhK/Dhnog4iIqFmZD7DavLI5HMIb46LmikWemcHxoQpM9rgwHxJQnmeqMbWc8EV uA5VdgFD6W1WPVsBrFRumv8cvbyR1ftWk3GvlOr1cKQ186D1KgPhJO3NabL6/V6PtdVA akC2R9oAXFO75gkJs55jduhKjpEEAPEeisbTQch1jVZcezkUOF7kzf+bYdFVcqa/axeF ErXiEPicDeRukS6ohqt714bwMwd8d61e0w7BUpFHXMTLWYa2n8h+Qq8xrr6BzdJiWcMK OEPw== X-Gm-Message-State: ALoCoQlyJ6IQOEiKYX5Mrp6U5flLIXavOhjOvRfDZ0uoyd28PRjQvjSIsyhz56D1ZuwM6sslIHQd MIME-Version: 1.0 X-Received: by 10.224.69.195 with SMTP id a3mr74800589qaj.59.1412171981271; Wed, 01 Oct 2014 06:59:41 -0700 (PDT) Received: by 10.229.247.198 with HTTP; Wed, 1 Oct 2014 06:59:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 14:59:41 +0100 Message-ID: From: Ben Laurie To: David Leon Gil Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IHD7tWMFNVvVKWgSCcpgip3Ie_Q Cc: "trans@ietf.org" Subject: Re: [Trans] Proving certificate freshness X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:59:43 -0000 On 1 October 2014 04:56, David Leon Gil wrote: > Something that is rather difficult to prove, at present, is that a > certificate has been used after it has expired or been revoked. > > If servers were required to include a signature over a recent STH (or > STH+OCSP staple) along with their SCT, this would provide an easy way > of showing that a *server* was behaving incorrectly. E.g., as a TLS > extension: > > struct { > STH; > sign(SignedCertificateTimestamp || OCSP || STH); > } FreshnessProof; > > This seems rather better than signing a timestamp; the STH isn't > predictable without a colluding log, so it isn't possible to > "accidentally" sign a future time. > > Any thoughts? Interesting idea. Note that even with a colluding log, predicting a future STH is tricky, since the log has to include any certs it's signed SCTs for within the MMD... From nobody Wed Oct 1 07:08:43 2014 Return-Path: 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 A51C81ACDB3 for ; Wed, 1 Oct 2014 07:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 0v3WFpR4-q4s for ; Wed, 1 Oct 2014 07:08:38 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897201A19FF for ; Wed, 1 Oct 2014 07:08:38 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so329558qcw.3 for ; Wed, 01 Oct 2014 07:08:37 -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=WmSGxjqPOeWQ0Mc7B0kWy8KU1PggqxjU3mz5q15wmu8=; b=VZFKOrsc03zMYIqBhT6TEh1wvcLqOqLFvka9prztBonpp3lBQoaaKtIuD+LKlF+EA1 DfZLdfOcWa4XhwzKDG3lUetjyiOSu/vKUFIjl5sr4ZlKcCGbszS2LMsBqd/4qeGMvyUk 1WAJCutjORLIxo60fnXI/JaWuGGuWXOC+GxIR1B2czvidfws5da8LNpt9sT6wQSm7iHZ eIYJk6Hf3FS23bx8LTILUM3wEHlWLBeSL/l7LT19f8vANmPG8JE4jKNMAJpes4EBSxHx 6FZDmIhLCwhGdcRisF1j6pWEzuIBNWkn7oflHL2zn1+PGNGLfPVhJxY0GhqHEUK4pGpF HOAQ== 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=WmSGxjqPOeWQ0Mc7B0kWy8KU1PggqxjU3mz5q15wmu8=; b=TchSFL1BoGVFvR6xbg2sCT/HoHtrUO5fReStv4mORLobHUDInJWeRA3LYseMOG+s5v WSZ2y8caI+J9OaCwN5z8xrPvsJ2JrQNe1BRf4WlADEUNPYmziIymCAv9AsR/RUh0g2Sl pmLPLLI4Zjf165koiUaMFJFb/mKZjEWBMx4Q5D9SWsBgOxK6Gj779xvB4M78dYuSWI6x IiNeVTq/laWH7UO/hyYGtQrwYtUCEbTOiClfYQ+M57V/lwnTfEqeiErNzSUC/TpqxXg2 ZF4AN2rEHkY8naPHWZ0VvJmSQpdzF+iMShDoxT6wBTD22yOCuAGdRCiA5m0iTKbTTfKu /05Q== X-Gm-Message-State: ALoCoQn/xT5hoMhSXytFnZb7Lo6bfLBOGxDx2qoyJcC4jIkoy+BP1HzGtKfqDENn5siCDpzDnszB MIME-Version: 1.0 X-Received: by 10.224.89.67 with SMTP id d3mr25086444qam.95.1412172517638; Wed, 01 Oct 2014 07:08:37 -0700 (PDT) Received: by 10.229.247.198 with HTTP; Wed, 1 Oct 2014 07:08:37 -0700 (PDT) In-Reply-To: <542C0587.3080702@fifthhorseman.net> References: <542C0587.3080702@fifthhorseman.net> Date: Wed, 1 Oct 2014 15:08:37 +0100 Message-ID: From: Ben Laurie To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bvY0kDr_DK_j5vR2dyWDVdqQM00 Cc: "trans@ietf.org" Subject: Re: [Trans] Proving certificate freshness X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:08:40 -0000 On 1 October 2014 14:45, Daniel Kahn Gillmor wrote: > On 09/30/2014 11:56 PM, David Leon Gil wrote: >> Something that is rather difficult to prove, at present, is that a >> certificate has been used after it has expired or been revoked. > > To be clear, this is a concern because it's otherwise possible to claim > abuse of a revoked/expired cert without being able to substantiate the > claim. > > That makes reports of cert misuse less trustworthy, which makes it > harder to act on them. > > However, CT is designed to detect (and hopefully deter) misissuance, not > misuse. Is this scope creep? It doesn't require anything from CT, though, so not really scope creep for CT itself. That said, clearly an append-only log can be used for timestamping directly, so if people think this is a good idea, then it could be implemented using a log that, say, issues a timestamp for certs periodically - and you require from the server a reasonably fresh timestamp. However, if you're prepared to modify servers, then you might as well go the whole hog and implement revocation transparency, which would make it impossible to use a revoked certificate from some short-ish time after revocation. Outline protocol: server periodically goes to an RT server and gets proof of non-inclusion in the list of currently revoked certificates (this proof would use a verifiable map, as documented in http://www.links.org/files/RevocationTransparency.pdf - note that our current thinking on verifying maps is you have a CT-like log of state changes, which the verifiable map is required to be consistent with, rather than maintaining a log of root hashes as suggested in that paper). From nobody Wed Oct 1 07:29:50 2014 Return-Path: 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 6BD5D1ACDD3 for ; Wed, 1 Oct 2014 07:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 qZ7n_0-NzH6m for ; Wed, 1 Oct 2014 07:29:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3A41A8710 for ; Wed, 1 Oct 2014 07:29:35 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43499 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZKua-0005Mm-VI for trans@ietf.org; Wed, 01 Oct 2014 10:29:49 -0400 Message-ID: <542C0FCB.7010906@bbn.com> Date: Wed, 01 Oct 2014 10:29:31 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: "trans@ietf.org" References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060800030601070007070606" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/CmgftQOBU-s2ZcAHxBsMI-kc4c8 Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:29:40 -0000 This is a multi-part message in MIME format. --------------060800030601070007070606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, > On Monday, September 29, 2014, Rick Andrews > wrote: > > Santosh, > > Since it's not an absolute requirement at this point (either from > CABF or from individual browsers' policies) I suggest that log > servers cannot enforce the use of technical constraints in > intermediate CAs. > > > We're talking about (non-normatively-specified) monitor servers here, > right? I am suggesting that the checks be mandatory, and that logs perform them, so that syntactically mis-issued certs don't get SCTs. If getting an SCT based on a pre-cert is supposed to "encourage" CAs to play the CT game, then this helps them get off on the right foot. > Log servers need to continue to accept based solely on signature > validity; otherwise they'll miss misissuance. (So *log* servers will > necessarily be agnostic about this.) I disagree. Once Ben said that he meant mis-issuance to be interpreted in a much broader context, and cited EV cert requirements as an example, I pursued documenting what that would mean. If the WG wants to say that mis-issuance is more than issuing a cert to the wrong Subject, then we need to say just what it is, not hand wave. Also, log servers, per se, do not detect mis-issuance, unless we have them perform the checks I suggested. What I think you meant to say is that if log servers reject syntactically mis-issued certs, then these certs will not be subject to analysis by Monitors. That's true, but there seems to be an inconsistent argument in play. If one argues that TLS client will, eventually, reject c erts that do not contain (or are not accompanied by) SCTs, then having logs reject syntactically mis-issued certs is a good thing. If we agree that the CABF guidelines for Web PKI CAs are the best reference we have for this (which seems reasonable for the Web PKI context), then why not enforce them? Having logs do the checks has the advantage that CAs get immediate feedback when they don't get it right at this basic level. Monitors, I think, should focus on detecting semantic mis-issuance for the Subjects that they serve. Not every Subject may arrange to have a Monitor protect its name and key binding, and not every Subject will perform monitoring for itself. So, if logs perform the basis, syntactic checks, we get that level of coverage for a lot of Subjects, without having to require them to perform or arrange for Monitor functions. Again, this is analogous to the argument that has been made for pre-certs, i.e., forcing a CA to embed an SCT into a cert avoids relying on Subjects to upgrade their web software to pass a post-issuance SCT during the TLS handshake. if that is a valid argument for why we're using the rather complex pre-cert mechanism, it seems that my argument for log checking of cert syntax is equally valid. Steve --------------060800030601070007070606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David,

On Monday, September 29, 2014, Rick Andrews <Rick_Andrews@symantec.com> wrote:
Santosh,
 
Since it's not an absolute requirement at this point (either from CABF or from individual browsers' policies) I suggest that log servers cannot enforce the use of technical constraints in intermediate CAs.

We're talking about (non-normatively-specified) monitor servers here, right?
I am suggesting that the checks be mandatory, and that logs perform them, so
that syntactically mis-issued certs don't get SCTs. If getting an SCT based on a
pre-cert is supposed to "encourage" CAs to play the CT game, then this helps them
get off on the right foot.
Log servers need to continue to accept based solely on signature validity; otherwise they'll miss misissuance. (So *log* servers will necessarily be agnostic about this.)
I disagree. Once Ben said that he meant mis-issuance to be interpreted in a much broader context,
and cited EV cert requirements as an example, I pursued documenting what that would mean. If
the WG wants to say that mis-issuance is more than issuing a cert to the wrong Subject, then
we need to say just what it is, not hand wave.

Also, log servers, per se, do not detect mis-issuance, unless we have them perform the checks
I suggested. What I think you meant to say is that if log servers reject syntactically mis-issued
certs, then these certs will not be subject to analysis by Monitors. That's true, but there seems
to be an inconsistent argument in play. If one argues that TLS client will, eventually, reject c
erts that do not contain (or are not accompanied by) SCTs, then having logs reject syntactically
mis-issued certs is a good thing.

If we agree that the CABF guidelines for Web PKI CAs are the best reference we have for this
(which seems reasonable for the Web PKI context), then why not enforce them? Having logs do
the checks has the advantage that CAs get immediate feedback when they don't get it right at
this basic level.

Monitors, I think, should focus on detecting semantic mis-issuance for the Subjects that they serve.
Not every Subject may arrange to have a Monitor protect its name and key binding, and not every
Subject will perform monitoring for itself. So, if logs perform the basis, syntactic checks,
we get that level of coverage for a lot of Subjects, without having to require them to perform
or arrange for Monitor functions.  Again, this is analogous to the argument that has been made
for pre-certs, i.e., forcing a CA to embed an SCT into a cert avoids relying on Subjects to
upgrade their web software to pass a post-issuance SCT during the TLS handshake. if that is a
valid argument for why we're using the rather complex pre-cert mechanism, it seems that my
argument for log checking of cert syntax is equally valid.

Steve
--------------060800030601070007070606-- From nobody Wed Oct 1 07:30:49 2014 Return-Path: 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 D8EC11ACDB9 for ; Wed, 1 Oct 2014 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uhjUaRE801fn for ; Wed, 1 Oct 2014 07:30:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F9B1A8710 for ; Wed, 1 Oct 2014 07:30:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50751 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZKvK-000KOS-6H; Wed, 01 Oct 2014 10:30:34 -0400 Message-ID: <542C1008.4060500@bbn.com> Date: Wed, 01 Oct 2014 10:30:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org, Stephen Farrell References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5429C24B.1050002@gmail.com> In-Reply-To: <5429C24B.1050002@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5agWt-20wRgcIAq_XlPQhzD3HGg Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:30:45 -0000 Stephen, I'm puzzled by your "advice." The IETF cites documents of other SDOs when relevant and when they do not conflict with the scope of IETF WGs. The CABF has created a profile of 5280, and 3647, for the Web PKI context, precisely the context that CT is addressing. Ben asserted that mis-issuance entails more than the simple notion that a cert was issued to the "wrong" subject. He specifically cited key size and EV cert criteria. These are criteria defined by the CABF guidelines. How can we proceed on CT if we don't have a solid definition of the problem it purports to address? Certainly detecting mis-issuance has to be well-defined. Steve > We've received a reminder from our friendly area director not > to introduce any normative dependencies on CAB Forum documents > or processes, as well as a query about how much x.509 processing > should be specified, as well. > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Wed Oct 1 07:32:13 2014 Return-Path: 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 024081ACDD8 for ; Wed, 1 Oct 2014 07:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pgutExzoh-dv for ; Wed, 1 Oct 2014 07:32:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9437A1ACDCF for ; Wed, 1 Oct 2014 07:32:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43503 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZKx2-0005OM-1H; Wed, 01 Oct 2014 10:32:20 -0400 Message-ID: <542C1063.50404@bbn.com> Date: Wed, 01 Oct 2014 10:32:03 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Laurie References: <5411E511.1040605@bbn.com> <54173589.3000404@bbn.com> <54242F8A.2080602@bbn.com> <54258AF0.7090602@bbn.com> <54297249.1090409@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/tyG7lY6VYEfvHA3_hFqroPeNpt0 Cc: "trans@ietf.org" Subject: Re: [Trans] Threat model outline, attack model X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:32:11 -0000 Ben, > ... >> Again, I disagree. We should define what we can and make design decisions >> based on that definition. Anything else that might be considered >> mis-issuanve, >> is out of scope for purposes of this work. This is the sort of delineation >> that >> we often impose on RFCs; we define a scope for a standard and declare that >> other >> stuff is out of scope, relative to the standard. > Then perhaps we should have a broader scope. Focusing on mis-issuance > seems to lead to all sorts of, IMO, unnecessary complications. I'm may get in trouble for saying this, but it seems as though the "complications" to which you allude are just the result of taking the terms that have been used to motivate development of CT and making them concrete, rather than ambiguous. If a "broader scope" means using more ambiguous terms, I can't see why that would be an improvement. > It might be simpler to define CT as a mechanism for allowing the > public examination of the contents of all issued certificates, without > getting into exactly what might be done as a result of that > examination. Detecting mis-issuance is, of course, an obvious example. I'm very bothered by your suggested change of focus. For me, this characterization of CT is way too vague for an IETF security standard (vs. an experimental RFC). It leads a reader to imagine that we don't have a simple, sound, defensible argument for why we're pursuing this technology. It has the flavor of "CT is obviously good, so let's just do it." (pardon me for putting words into anyone's mouth.) Steve From nobody Wed Oct 1 07:34:32 2014 Return-Path: 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 6EE0E1ACDE5 for ; Wed, 1 Oct 2014 07:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 nABQE_Pr5I68 for ; Wed, 1 Oct 2014 07:34:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409E91ACDB9 for ; Wed, 1 Oct 2014 07:34:25 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40949 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZKzG-0005Pi-P5 for trans@ietf.org; Wed, 01 Oct 2014 10:34:39 -0400 Message-ID: <542C10ED.2060902@bbn.com> Date: Wed, 01 Oct 2014 10:34:21 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20140930005524.GP16215@hezmatt.org> In-Reply-To: <20140930005524.GP16215@hezmatt.org> Content-Type: multipart/alternative; boundary="------------060308070005010308000001" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mQvvqnqzdseoQ5PH0WIsfv1fz24 Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:34:27 -0000 This is a multi-part message in MIME format. --------------060308070005010308000001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt, > Logs shouldn't be enforcing *anything*. A log isn't a judge, it's a > record. The only constraints on what should be rejected from being > accepted by a log should be those things which prevent abuse > sufficient to render a log unusable. That's a very simple, strong assertion, but it isn't accompanied by a rationale. I agree that the current description of a log focuses on recording cert info, but it already includes an element of "judgement" since it has a list of the root CAs that must anchor the cert chains that it will accept. If we stick with the detection of mis-issuance rationale that the document asserts as the goal for CT, and if we define mis-issuance as broadly as Ben suggested in response to my first cut at a defintiion, with his specific references to EV certs and key sizes, then we have to check certs against those criteria at some place in the system. The current design appears to call for Monitors to do this, and one could stick with that approach. The description of Monitors says that " They alsowatch for certificates of interest." I interpret this to mean that a Monitor has a list of certs, or of Subject names and keys, that it is "protecting." If a Subject does not run its own Monitor, and it it doesn't arrange for some other entity to act as a Monitor to protect the Subject's certs, then no checking for syntactic mis-issuance will take place. That observation motivates exploring the notion of having logs perform the function. By so doing we have an opportunity to perform detection of syntactic mis-issuance for every logged cert, a service to the broad Web PKI community. It seems as though some are arguing that if a log rejects certs that fail to meet the syntactic criteria this is a bad thing, because it will deter logging of certs. I thought the CT design makes a counter argument, i.e., that CAs are motivated to log certs because, over time, TLS clients will reject connections to servers when there is no evidence of an SCT. if this argument is true, then having logs check for syntactic mis-issuance is a good thing. If the argument is not true, it should not be part of the "why CT will work" description. Steve --------------060308070005010308000001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Matt,
Logs shouldn't be enforcing *anything*. A log isn't a judge, it's a record. The only constraints on what should be rejected from being accepted by a log should be those things which prevent abuse sufficient to render a log unusable.
That's a very simple, strong assertion, but it isn't accompanied by a rationale.

I agree that the current description of a log focuses on recording cert
info, but it already includes an element of "judgement" since it has
a list of the root CAs that must anchor the cert chains that it will accept.

If we stick with the detection of mis-issuance rationale that the document
asserts as the goal for CT, and if we define mis-issuance as broadly as Ben
suggested in response to my first cut at a defintiion, with his specific references
to EV certs and key sizes, then we have to check certs against those criteria at some
place in the system.

The current design appears to call for Monitors to do this, and one could stick
with that approach. The description of Monitors says that " They also watch for
certificates  of interest." I interpret this to mean that a Monitor has a list
of certs, or of Subject names and keys, that it is "protecting." If a Subject
does not run its own Monitor, and it it doesn't arrange for some other entity
to act as a Monitor to protect the Subject's certs, then no checking for
syntactic mis-issuance will take place. That observation motivates exploring the
notion of having logs perform the function. By so doing we have an opportunity to
perform detection of syntactic mis-issuance for every logged cert, a service to
the broad Web PKI community.

It seems as though some are arguing that if a log rejects certs that fail to meet
the syntactic criteria this is a bad thing, because it will deter logging of certs.

I thought the CT design  makes a counter argument, i.e., that CAs are motivated
to log certs because, over time, TLS clients will reject connections to servers
when there is no evidence of an SCT.  if this argument is true, then having logs
check for syntactic mis-issuance is a good thing. If the argument is not true,
it should not be part of the "why CT will work" description.

Steve --------------060308070005010308000001-- From nobody Wed Oct 1 07:41:22 2014 Return-Path: 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 A4DE91ACE0D for ; Wed, 1 Oct 2014 07:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 pihslZ1IAsul for ; Wed, 1 Oct 2014 07:41:18 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ED21ACE01 for ; Wed, 1 Oct 2014 07:41:17 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so463062lbi.23 for ; Wed, 01 Oct 2014 07:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LLLaYoE04G8cbB688t8gaOEVu5P56Cvi0JtSWKRhW0g=; b=NG6Jrt7AX8aHGMLYXgeVZU5yifnM4IX58tKVDnaDN4e5oocXocQvnBTfLsi1OJhGrY AACl95F8MhlO/2Tsks/hDFq6ODDLeIEnXkM5Ra+kE+ticIyRrvfKWeqJc+9Hmb3skXX+ 185d6GHjuSSiDCOUC4yzX1sCdR83IKF/2dnKqr7822mEJX2nIAGjQRUJtmFXSPWKd+qC XMIMJ9N0RiAZ+lBmQ+Tm5xIJ2xDgxn+b9EiQ7chShM4DdxYMu1MWfrZ5wcWh0binnf5L 2ca4nwK2snqyEY7JawFWAAd/xMLsjmtgyPy6AxLgRN7kZ6wGB0cJFandw2++B7EZ2kuS gVpw== X-Received: by 10.112.160.42 with SMTP id xh10mr11988512lbb.97.1412174476391; Wed, 01 Oct 2014 07:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Wed, 1 Oct 2014 07:40:56 -0700 (PDT) In-Reply-To: References: <542C0587.3080702@fifthhorseman.net> From: David Leon Gil Date: Wed, 1 Oct 2014 10:40:56 -0400 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uxLOvIbJ53HxJqewaeEIAFbPVYA Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] Proving certificate freshness X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:41:19 -0000 On Wed, Oct 1, 2014 at 10:08 AM, Ben Laurie wrote: > However, if you're prepared to modify servers, then you might as well > go the whole hog and implement revocation transparency, which would > make it impossible to use a revoked certificate from some short-ish > time after revocation. Generally agreed; the proposal is mainly intended as a stop-gap until then. It doesn't require any new transparency server infrastructure. (It also is essentially free gossip about STHs for clients.) > note that our > current thinking on verifying maps is you have a CT-like log of state > changes, which the verifiable map is required to be consistent with, > rather than maintaining a log of root hashes as suggested in that > paper). This seems an improvement. Could this log be integrated with CT issuance logs? (That is, have a single "certificate event" log?) Also, a question about RT: Why not require all RT logs to be identical? That is, simply require that they reach consensus on a tree-head hash. (This requires using, e.g., an order on (domain, time), of course.) (Perhaps this came up in the early days of CT design, but I wasn't able to find discussion of it.) From nobody Wed Oct 1 07:48:09 2014 Return-Path: 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 1355F1ACE20 for ; Wed, 1 Oct 2014 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 AWOqK6pC-Iw0 for ; Wed, 1 Oct 2014 07:48:04 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910D41ACE24 for ; Wed, 1 Oct 2014 07:48:04 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so464925lbv.26 for ; Wed, 01 Oct 2014 07:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tsZMUOvi0RX83tBJLBCsVQuHTC29fKbQ8vFEwaQKCs4=; b=falTyLc3sPuOfE3DWNHAKlKmyORKkXAM6CgCZo0AOg1arpQxsue/jW/7M7kTBxVkZd BxJrXyn00ZHQlFCkUWMypKqMdMK8CeasCWcAxco6zDPwjWJqVn+3bcSfnPVEfpsIwXmE L6FyhOjJxP/EHrE/caBYDfauS/qXDf5VkidCk0ciPLfxtyIb1BOYgcdwKhaE4HOQTc8u AF3LdNaN1BKteu6Kqdmn3qnNM6mG7VM8q1biV9QelEXiXQo+l018QEfQisV13bSX/YDm SYpf/bCgvbhogIE/16DAzfe1ODckGwhTX71Z5lwH6R5lJK8dDexg382NwGc+c9aHc9K1 MLMw== X-Received: by 10.112.78.38 with SMTP id y6mr18787873lbw.94.1412174882843; Wed, 01 Oct 2014 07:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Wed, 1 Oct 2014 07:47:42 -0700 (PDT) In-Reply-To: <542C0FCB.7010906@bbn.com> References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C0FCB.7010906@bbn.com> From: David Leon Gil Date: Wed, 1 Oct 2014 10:47:42 -0400 Message-ID: To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/g8TmPH6DnTYzdEKjEOzRInf47JA Cc: "trans@ietf.org" Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:48:07 -0000 On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent wrote: > I disagree. Once Ben said that he meant mis-issuance to be interpreted in a > much broader context, > and cited EV cert requirements as an example, I pursued documenting what > that would mean. If > the WG wants to say that mis-issuance is more than issuing a cert to the > wrong Subject, then > we need to say just what it is, not hand wave. You are missing the point of certificate transparency. We have no idea all the forms that misissuance -- particularly malicious misissuance -- might take. If it were trivial to detect "misissuance", browsers would validate certs for "misissuance" and the problem would be solved. The point of having a log that includes everything signed with a CA's key is that analysis of issued certificates can be conducted post-hoc. Proposals to limit the scope of what logs can log kneecap CT. They should not be considered. From nobody Wed Oct 1 07:54:17 2014 Return-Path: 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 221321ACE22 for ; Wed, 1 Oct 2014 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CI32d4CVjGH0 for ; Wed, 1 Oct 2014 07:54:14 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2E71ACE1C for ; Wed, 1 Oct 2014 07:54:08 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so238955qge.8 for ; Wed, 01 Oct 2014 07:54:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ZknRMUYd/3JMfgvBCF/gymMMvr9YV4h2wVjcVRIQ6hM=; b=TA3xFtMTocDoC6s7TutXnUEdYzdvDli5WBjg0WplizwU8fXHaQbcdcs45PKsdalgbd ok2Mpm4p/snlWg+yhj5UDgV7go7RVdJXyYNgFFwnJEp0IgU6i46yvRren1JU2qePgbfA EnLPGQcTY/lO9dalWt0FnzX1NyTqxGzFMYKiZOFacHQbtX6UZyS1DFtJN+QI4ssifCx8 rX7tLSTRcxe2vJ9w9cyEy2P+6etcewtL76oBQDLPKWUBqqO4wBGqGnW5nwtE45eKHOpj oOs+YNkaOSXzFD3hB5+0KmFxnVT3m1BIEQd2tXDs+rN5cSfV81z6xdGLwNoSQYfmIUha zHwA== X-Gm-Message-State: ALoCoQkUp1QX1iYyoZHPY19Qv6VULG9WtN8gZ2I/+jqrn1iM0PXg3G1ojMOcKZm6wS8ezO0so+LA X-Received: by 10.140.38.81 with SMTP id s75mr83630162qgs.4.1412175247456; Wed, 01 Oct 2014 07:54:07 -0700 (PDT) Received: from [192.168.2.2] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id l46sm802696qgd.27.2014.10.01.07.54.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Oct 2014 07:54:07 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Wed, 01 Oct 2014 10:54:03 -0400 From: Carl Wallace To: "trans@ietf.org" Message-ID: Thread-Topic: [Trans] path validation References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C0FCB.7010906@bbn.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IQlctCM2g4Y-TL3LrhpPwqR6QUQ Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:54:16 -0000 On 10/1/14, 10:47 AM, "David Leon Gil" wrote: >On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent wrote: >> I disagree. Once Ben said that he meant mis-issuance to be interpreted >>in a >> much broader context, >> and cited EV cert requirements as an example, I pursued documenting what >> that would mean. If >> the WG wants to say that mis-issuance is more than issuing a cert to the >> wrong Subject, then >> we need to say just what it is, not hand wave. > >You are missing the point of certificate transparency. > >We have no idea all the forms that misissuance -- particularly >malicious misissuance -- might take. If it were trivial to detect >"misissuance", browsers would validate certs for "misissuance" and the >problem would be solved. > >The point of having a log that includes everything signed with a CA's >key is that analysis of issued certificates can be conducted post-hoc. > >Proposals to limit the scope of what logs can log kneecap CT. They >should not be considered. Maybe the term mis-issuance should just be discarded. There seems to be agreement that logs should accept anything signed by one of the CAs covered by a log. Monitors can always detect whatever they want relative to the certificate collection maintained by a log (be it =E2=80=9Cmis-issuance=E2=80=9D= or something else). From nobody Wed Oct 1 07:54:35 2014 Return-Path: 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 4C7531A1A05 for ; Wed, 1 Oct 2014 07:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4F3uGQfkwDmT for ; Wed, 1 Oct 2014 07:54:32 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325B91ACE1E for ; Wed, 1 Oct 2014 07:54:31 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id gb8so526802lab.17 for ; Wed, 01 Oct 2014 07:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FzG8FtPRalVDgnhtY+mSusaHfXhCkirFtvnZULih9Z4=; b=S37SWJZBjNLcUOCu3TerpuL15EqYd6mBu7/OHpiRczJgCwlfoYZcfp8a5F6ESmj1FH 5DWedz40VdxjklY/PXIYgw0Nj+4D/PJWGSP0xPS93mxtW+VJuW/TEYWqEW4YEFuev5+o XnnzcyxJtJdg7/5JFZvCdD9N1kUP3AbUOkYuNCxTj3EVwQGY84OUsbLG9LGW8yA52duT 3J0OG/mZDMGMW1YVIGSkRQDf8PYug/6JM1PE0MOCncyvQqBjmnlWG60te9pgQZXhk47x reJZZiBc0Vybt+g0xJUG0lCaB2GTWdkGIyBVRaQNHqtHmz1tIduw8XWkpkf+E/nW82Qv OiqA== X-Received: by 10.112.78.38 with SMTP id y6mr18831185lbw.94.1412175269425; Wed, 01 Oct 2014 07:54:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Wed, 1 Oct 2014 07:54:09 -0700 (PDT) In-Reply-To: <542C1063.50404@bbn.com> References: <5411E511.1040605@bbn.com> <54173589.3000404@bbn.com> <54242F8A.2080602@bbn.com> <54258AF0.7090602@bbn.com> <54297249.1090409@bbn.com> <542C1063.50404@bbn.com> From: David Leon Gil Date: Wed, 1 Oct 2014 10:54:09 -0400 Message-ID: To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/a9h3jwvRbXEvMJFqWDWnJUVDHwc Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] Threat model outline, attack model X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:54:34 -0000 On Wed, Oct 1, 2014 at 10:32 AM, Stephen Kent wrote: > If a "broader scope" means using more ambiguous terms, I can't see why that would be an improvement. > It has the flavor of "CT is obviously good, so let's just do it." Okay. You've convinced me. So: I've disabled syslog on all my servers. I can't define a-priori what security issues logging might detect. Thus there's no point in logging anything. From nobody Wed Oct 1 08:05:41 2014 Return-Path: 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 864DF1ACE79 for ; Wed, 1 Oct 2014 08:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 LHNGj_F1wRk2 for ; Wed, 1 Oct 2014 08:05:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 896EC1ACE6F for ; Wed, 1 Oct 2014 08:05:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7587ABE4D; Wed, 1 Oct 2014 16:05:00 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBGwHBsgEwWg; Wed, 1 Oct 2014 16:05:00 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4D5E6BE20; Wed, 1 Oct 2014 16:05:00 +0100 (IST) Message-ID: <542C181C.8040109@cs.tcd.ie> Date: Wed, 01 Oct 2014 16:05:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5429C24B.1050002@gmail.com> <542C1008.4060500@bbn.com> In-Reply-To: <542C1008.4060500@bbn.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/9YWXN1xjOFkyYLiJzAXGa7Vp00A Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:05:38 -0000 Hiya, On 01/10/14 15:30, Stephen Kent wrote: > > > How can we proceed on CT if we don't have a solid definition of the > problem it purports to address? Certainly detecting mis-issuance > has to be well-defined. I think this is the crux of the matter. Mis-issuance is not a feature but a bug. Attempting to describe all possible bugs of any sort is futile. If you argue that a CT RFC has to describe all possible bugs, then that amounts to arguing to not do CT. But the IETF has reached consensus to do CT so it seems that others do not agree with you that "detecting mis-issuance has to be well-defined" at least if that is meant to call for a complete enumeration of all the ways in which mis-issuance might occur. (And I don't get what else you might have meant, but please correct me if I'm misreading what you've written.) Having some examples of mis-issuance described is quite reasonable. Asking that all forms of mis-issuance be documented is not reasonable. Now as to CABF, while its very reasonable to think about their requirements, I don't think it'd be a good plan to hard-code a dependency on a version of those into a CT RFC. Their baseline reqs doc has changed 3 times this year already for example and 5 times in 2013 and I suspect will continue to evolve significantly. But if you see a stable useful and quotable definition of mis-issuance in one of their documents, then sending a pointer to that text would be good. I don't know if there is such a piece of text though. Cheers, S. PS: I'm not sure CABF would describe themselves as an SDO either, but that's a mere matter of terminology. From nobody Wed Oct 1 08:06:41 2014 Return-Path: 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 DC7831ACE59 for ; Wed, 1 Oct 2014 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 HQEJADwZSE3Z for ; Wed, 1 Oct 2014 08:06:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237CF1ACE62 for ; Wed, 1 Oct 2014 08:05:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57177 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZLTc-0005lR-97 for trans@ietf.org; Wed, 01 Oct 2014 11:06:00 -0400 Message-ID: <542C1846.7060303@bbn.com> Date: Wed, 01 Oct 2014 11:05:42 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <542477E3.8070304@bbn.com> <544B0DD62A64C1448B2DA253C011414607D1628D70@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542971A7.7030700@bbn.com> <544B0DD62A64C1448B2DA253C011414607D174DEB1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D174DEB1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Content-Type: multipart/alternative; boundary="------------050602050004080901060204" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wno5ubzMZK1eY24PbpRC1ut2HtQ 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:06:38 -0000 This is a multi-part message in MIME format. --------------050602050004080901060204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rick, > ... > > It's doable, but it still leaves the CA in a bind. What if the CA > wants to start issuing certs according to new CABF docs, but finds > that none of the existing log servers support that version? This is > probably a moot point, isn't it, because Melinda has reminded us not > to introduce any normative dependencies on CAB Forum documents or > processes. > I'm ignoring that "advice" for now, as it was not accompanied by any description of a procedural basis for ignoring the CABF guidelines in this context :-). More to the point in the IETF if we want to avoid a normative reference to another SDO's doc, we can do what I have already done, i.e., create our own version (usually a subset) of the doc and make it part of an RFC (or make it a standalone RFC). We started doing this long ago when we created CMS as a standards track RFC that updated PKCS docs. So, we can literally avoid a normative dependency on CAF guidelines, merely cite them as the source/motivation for our CT mis-issuance definitions. 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. > > .... > > > If the Subject provides a list of all o the keys associated with the > Subject, perhaps in the form > of certs issued to the Subject (and currently valid) this would enable > a Monitor to detect this form of mis-issuance, agreed? > > Agreed, but it puts a burden on the Subject. Before issuing any new > legitimate certificate, the Subject would need to notify the Monitor > of the new Subject name and/or public key. We've got some customers > who issue thousands of certificates across their organization. IMO, > the model might work better if the Monitor is simply a conduit, > providing information found in log servers to the Subject, and then > the Subject can decide if each new certificate was intentionally issued. > I don't think we are fundamentally disagreeing here. I have assumed that a Monitor notifies a Subject when the Monitor detects that a cert with the Subject's name has a different key from the set supplied by the Subject to the Monitor, as reference data. The Subject makes the final determination and acts on that. So, a Montitor is alerting a Subject to what appear to be a mis-issuance. So, if the info that a Monitor passes to a Subject is the set of certs that the Monitor finds in logs, the only difference in my proposal is that the Monitor would not pass on certs that match a set of keys supplied by the Subject. One could transform my model into what you said by having a Subject provide no keys, but noting that the Subject does have one or more certs issued to it. > > > > A separate topic is issuance of a bogus cert for a Subject who doesn't > have a cert issued legitimately. > In this case there is no reference cert to present to a Monitor. It > may be hard for a Subject who > doesn't have a cert to convince a 3rd party Monitor to check for certs > issued to the Subject name > in question. Should we classify this as mis-issuance as well? > > See my comment above. Must the Monitor be able to decide by itself > what is legitimate and what is mis-issued, or is that the role of the > Subject, with help from the Monitor? In other words, couldn't we say > that it's mis-issuance if the Monitor finds a cert in a log, forwards > it to the Subject, and the Subject determines that it's mis-issued? > > -Rick > The issue here, I think, is that a web site that has no Web PKI cert, e.g., because it has a self-signed cert or is relying on DANE, might not enlist the help of a Monitor, especially if there is a cost to do so. I'm not sure we need to address this case, but we do need to identify it and say that we are not addressing it if we choose to do so. Steve --------------050602050004080901060204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rick,
...

 

It’s doable, but it still leaves the CA in a bind. What if the CA wants to start issuing certs according to new CABF docs, but finds that none of the existing log servers support that version? This is probably a moot point, isn’t it, because Melinda has reminded us not to introduce any normative dependencies on CAB Forum documents or processes.

I'm ignoring that "advice" for now, as it was not accompanied by any description of
a procedural basis for ignoring the CABF guidelines in this context :-). 

More to the point in the IETF if we want to avoid a normative reference to another SDO's doc,
we can do what I have already done, i.e., create our own version (usually a subset) of the doc
and make it part of an RFC (or make it a standalone RFC). We started doing this long ago when
we created CMS as a standards track RFC that updated PKCS docs. So, we can literally avoid
a normative dependency on CAF guidelines, merely cite them as the source/motivation for
our CT mis-issuance definitions.

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.

 

....


If the Subject provides a list of all o the keys associated with the Subject, perhaps in the form
of certs issued to the Subject (and currently valid) this would enable a Monitor to detect this form of mis-issuance, agreed?

Agreed, but it puts a burden on the Subject. Before issuing any new legitimate certificate, the Subject would need to notify the Monitor of the new Subject name and/or public key. We’ve got some customers who issue thousands of certificates across their organization. IMO, the model might work better if the Monitor is simply a conduit, providing information found in log servers to the Subject, and then the Subject can decide if each new certificate was intentionally issued.

I don't think we are fundamentally disagreeing here. I have assumed that a Monitor notifies a
Subject when the Monitor detects that a cert with the Subject's name has a different key from
the set supplied by the Subject to the Monitor, as reference data. The Subject makes the final
determination and acts on that. So, a Montitor is alerting a Subject to what appear to be a
mis-issuance. So, if the info that a Monitor passes to a Subject is the set of certs that the
Monitor finds in logs, the only difference in my proposal is that the Monitor would not pass on
certs that match a set of keys supplied by the Subject.  One could transform my model into what
you said by having a Subject provide no keys, but noting that the Subject does have one or more
certs issued to it.



A separate topic is issuance of a bogus cert for a Subject who doesn't have a cert issued legitimately.
In this case there is no reference cert to present to a Monitor. It may be hard for a Subject who
doesn't have a cert to convince a 3rd party Monitor to check for certs issued to the Subject name
in question. Should we classify this as mis-issuance as well?

See my comment above. Must the Monitor be able to decide by itself what is legitimate and what is mis-issued, or is that the role of the Subject, with help from the Monitor? In other words, couldn’t we say that it’s mis-issuance if the Monitor finds a cert in a log, forwards it to the Subject, and the Subject determines that it’s mis-issued?

 

-Rick

The issue here, I think, is that a web site that has no Web PKI cert, e.g., because it has a self-signed
cert or is relying on DANE, might not enlist the help of a Monitor, especially if there is a cost to do
so.  I'm not sure we need to address this case, but we do need to identify it and say that we are
not addressing it if we choose to do so.

Steve
--------------050602050004080901060204-- From nobody Wed Oct 1 08:07:20 2014 Return-Path: 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 2481A1A1A30 for ; Wed, 1 Oct 2014 08:07:18 -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 4u9itRS6j3sR for ; Wed, 1 Oct 2014 08:07:17 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26CD1ACE4E for ; Wed, 1 Oct 2014 08:07:16 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id x13so472229qcv.32 for ; Wed, 01 Oct 2014 08:07:16 -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=kavpA1NLomk1JbYEvsh4YAtRfpkC98IhmagSPl2WiIE=; b=LBAT0fOwBsY9hqPIZpjhzECxNQ1LRdMEhU8j4XmkHloEncUhVJhgxAItQtdDuzQgwG zwMqT435PLnU0qQXjz37PcAVpqj/oE6kLDS5K2EtpV9ZRy+uU6avpWb4TmAZCm0wxT+J MddxnWDQwl2hH/zedLPMxGp9JmNfX/ZUfpBo2c51UnOFrS2dMm8L9VKapaFEP2kAfGfY S1Tlq/EHJlRolIHX13r/BKUR/sURZqSE98vlWU3w9RADQYtcur6xbCwu8A15gUT51QjJ M68f3P3qV9WAFdAzhdKFtbxu/QlID2qJdZKcp/m1tuAXOKqBMBAFXKrUMnPatBAMnX1P 27uw== 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=kavpA1NLomk1JbYEvsh4YAtRfpkC98IhmagSPl2WiIE=; b=BzhlTFTltzcr+3o+lG05YbNocEpOWL6891ljL52AICqUp4G/WyBVRS+vjAkxAGVKIw cndXnSvV5sVpSTqc51SdGAt29umUkk8vPw9V5m6X+wH6lmo+lzrE/wUcEe7wOzXLwaYl XFKNxQvh0ncdYbrx1uwT59FYHzPDXbVNq+y6/NrxJX9xVtejUEkffHFKZVBXVqgdCpFZ /iEe9yFfRfY0cxi74XvEUDcQiD/8tvTSMPsaPm0WvmYkitghYB0HTbRKtyFmdF3BNvsf etvCmgIGPB7jZvNf2EfXcQgZ5KR//mzxKB/iKfmsYopX4HS2jUl/1NNfgiDFd/tyWod3 0kqg== X-Gm-Message-State: ALoCoQmCr2DXhP4pgi47yaVwD3JmBr2+2/KqbPzYHcce/KBLkqnp5IkgOwixARsQcXZlEED3fZmi MIME-Version: 1.0 X-Received: by 10.224.137.3 with SMTP id u3mr32634121qat.82.1412176035921; Wed, 01 Oct 2014 08:07:15 -0700 (PDT) Received: by 10.229.247.198 with HTTP; Wed, 1 Oct 2014 08:07:15 -0700 (PDT) In-Reply-To: References: <542C0587.3080702@fifthhorseman.net> Date: Wed, 1 Oct 2014 16:07:15 +0100 Message-ID: From: Ben Laurie To: David Leon Gil Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5-GHJV2uwKyUZAtD8ZPIUkYmaHc Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] Proving certificate freshness X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:07:18 -0000 On 1 October 2014 15:40, David Leon Gil wrote: > On Wed, Oct 1, 2014 at 10:08 AM, Ben Laurie wrote: >> However, if you're prepared to modify servers, then you might as well >> go the whole hog and implement revocation transparency, which would >> make it impossible to use a revoked certificate from some short-ish >> time after revocation. > > Generally agreed; the proposal is mainly intended as a stop-gap until > then. It doesn't require any new transparency server infrastructure. > (It also is essentially free gossip about STHs for clients.) > >> note that our >> current thinking on verifying maps is you have a CT-like log of state >> changes, which the verifiable map is required to be consistent with, >> rather than maintaining a log of root hashes as suggested in that >> paper). > > This seems an improvement. Could this log be integrated with CT > issuance logs? (That is, have a single "certificate event" log?) Probably. > Also, a question about RT: Why not require all RT logs to be > identical? That is, simply require that they reach consensus on a > tree-head hash. (This requires using, e.g., an order on (domain, > time), of course.) It doesn't seem like a particularly useful thing to do, and it obviously adds a lot of complexity. In fact, Akamai had an interesting suggestion around pools of logs which may not have quite identical contents... > > (Perhaps this came up in the early days of CT design, but I wasn't > able to find discussion of it.) From nobody Wed Oct 1 08:10:30 2014 Return-Path: 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 E51821ACE4E for ; Wed, 1 Oct 2014 08:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.41 X-Spam-Level: * X-Spam-Status: No, score=1.41 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] 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 6wv8yPi6bo9Q for ; Wed, 1 Oct 2014 08:10:17 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509F31A1A26 for ; Wed, 1 Oct 2014 08:10:16 -0700 (PDT) Received: (qmail 26776 invoked by uid 1000); 1 Oct 2014 15:10:13 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 01 Oct 2014 16:10:13 +0100 Message-ID: <542C1955.7080304@comodo.com> Date: Wed, 01 Oct 2014 16:10:13 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <54296FB2.1060109@bbn.com><4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com><544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com><544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><20140930005524.GP16215@hezmatt.org> <542C10ED.2060902@bbn.com> In-Reply-To: <542C10ED.2060902@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/NGHOAjDsFw2Boa5pEJXzfCPj9lo Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:10:22 -0000 On 01/10/14 15:34, Stephen Kent wrote: > I thought the CT design makes a counter argument, i.e., that CAs are > motivated to log certs because, over time, TLS clients will reject > connections to servers when there is no evidence of an SCT. Over time, yes, we hope that this will happen. But we obviously can't guarantee that, in N months/years from now, 100% of TLS clients will support CT. > if this argument is true, then having logs check for syntactic > mis-issuance is a good thing. I disagree. There is a gap between what is syntactically properly issued (according to CABF guidelines, etc) and what a typical TLS client actually accepts. If logs checked for syntactic mis-issuance, a rogue CA could exploit this gap by maliciously mis-issuing certs containing "syntax errors". CT would not reveal the attack (because the logs would refuse to issue SCTs), but TLS clients that don't reject connections when no SCT is provided would be vulnerable. We want to provide as much "herd immunity" as possible to TLS clients that don't support CT. This means that we need all certs to be publicly logged, to maximize the chances that any (maliciously) mis-issued cert will be discovered quickly. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Oct 1 08:33:04 2014 Return-Path: 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 24C031A1A12 for ; Wed, 1 Oct 2014 08:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] 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 Q5cwxefn5zPK for ; Wed, 1 Oct 2014 08:32:59 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E287A1ACE57 for ; Wed, 1 Oct 2014 08:32:56 -0700 (PDT) Received: (qmail 6351 invoked by uid 1000); 1 Oct 2014 15:32:55 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 01 Oct 2014 16:32:55 +0100 Message-ID: <542C1EA6.8050106@comodo.com> Date: Wed, 01 Oct 2014 16:32:54 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Stephen Kent , "trans@ietf.org" References: <542477E3.8070304@bbn.com><544B0DD62A64C1448B2DA253C011414607D1628D70@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><542971A7.7030700@bbn.com><544B0DD62A64C1448B2DA253C011414607D174DEB1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C1846.7060303@bbn.com> In-Reply-To: <542C1846.7060303@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/39tRPlR0avJ0Mx82X1lNymuX9W8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:33:01 -0000 On 01/10/14 16:05, Stephen Kent wrote: > Rick, > 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? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Oct 1 08:45:52 2014 Return-Path: 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 E1F471A1A40 for ; Wed, 1 Oct 2014 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 b6jhc5zdeWNw for ; Wed, 1 Oct 2014 08:45:48 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8671D1A1A48 for ; Wed, 1 Oct 2014 08:45:48 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k14so911378wgh.29 for ; Wed, 01 Oct 2014 08:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1eoU5OWVo9s414lz8r46s/YVtjc/gWODDqrCHNIUEIU=; b=KyETW2pk7HYIFEpHmIMFWlJjOI8ogfh5NPwUB+6SW4WCp8swTVv6LLUyXV22dKWBc0 KIU+cy+eGqLXZ5bXt+pjSgYmbsUMgKHX0Eq7o9i+IcURwu3VzPMMyNeYTHIlMrfl7dVH OPVojlOCtSi4CZ7vularJ+g/upa6d12B+17DYEQGE8sDhx13IZCvymMVXB5yem72QdHV FZ0OV61qYoEck0CeE5Q+I+gUPSdB8/KOzZkrm/hn5nP7c1PDYPGi8s//DimB3Ynu4Ncy PpkQy7JpRgo1bbYJGd2wj/nHdQJWIAmWgeVnYRHnckKtHgywuIdzSbD0PaGgAKoE6nXY Bfvw== MIME-Version: 1.0 X-Received: by 10.194.134.201 with SMTP id pm9mr5372195wjb.130.1412178346964; Wed, 01 Oct 2014 08:45:46 -0700 (PDT) Received: by 10.27.79.193 with HTTP; Wed, 1 Oct 2014 08:45:46 -0700 (PDT) In-Reply-To: <542C1EA6.8050106@comodo.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> Date: Wed, 1 Oct 2014 08:45:46 -0700 Message-ID: From: Peter Bowen To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/G-RW77b0LEp13SfKsGA0PkjYeK4 Cc: "trans@ietf.org" , Stephen Kent 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:45:51 -0000 On Wed, Oct 1, 2014 at 8:32 AM, Rob Stradling wrote: > 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? This feels like an interesting feature for CT log hosts. An additional API that allows subscribing to the "firehose" of all log entries as they happen. I wonder how many certificates per second Comodo is issuing these days with the CloudFlare annoucement... From nobody Wed Oct 1 09:16:03 2014 Return-Path: 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 EDAB31ACE4D for ; Wed, 1 Oct 2014 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 uOs11pKf4-_j for ; Wed, 1 Oct 2014 09:15:59 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id E90691A0687 for ; Wed, 1 Oct 2014 09:15:58 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id A1ACC51C070; Wed, 1 Oct 2014 09:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=Y7Qc41OyIEb4ceyow /227znSYF0=; b=munTnT8BMy4Md84XoKLEwNsy6HhjvxNEASgCjvZKmDGm0ciLI Gp4K57atqtfHozE+t485kMyXBtLOLiV1hNEyDfPl0lJillHlrjuggTCPpqomLgeL AvX2/neKTimJgYR0i7aP7EHPPGWZXeVp9eTHRtomHiCnpkoH5epzsdNl0c= Received: from [192.168.42.78] (50-1-116-54.dsl.dynamic.sonic.net [50.1.116.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 1B5D851C073; Wed, 1 Oct 2014 09:15:57 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DE45AF54-5181-493A-AB0C-A9DD64E5157F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Pgp-Agent: GPGMail 2.1 (f76fd85) From: Tao Effect In-Reply-To: Date: Wed, 1 Oct 2014 09:15:57 -0700 X-Mao-Original-Outgoing-Id: 433872957.080833-516dafabbd810154a447bba594faef93 Message-Id: <530D1136-916E-41F7-A9EC-819C5564CA33@taoeffect.com> References: <5411E511.1040605@bbn.com> <54173589.3000404@bbn.com> <54242F8A.2080602@bbn.com> <54258AF0.7090602@bbn.com> <54297249.1090409@bbn.com> <542C1063.50404@bbn.com> To: David Leon Gil X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ixTY7iC-amsHbgQ9wsYJ5CIY9tg Cc: Ben Laurie , "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] Threat model outline, attack model X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 16:16:00 -0000 --Apple-Mail=_DE45AF54-5181-493A-AB0C-A9DD64E5157F Content-Type: multipart/alternative; boundary="Apple-Mail=_F0A069FB-95D9-41BF-BC87-D46C4CED922A" --Apple-Mail=_F0A069FB-95D9-41BF-BC87-D46C4CED922A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 1, 2014, at 7:54 AM, David Leon Gil wrote: > On Wed, Oct 1, 2014 at 10:32 AM, Stephen Kent wrote: >> If a "broader scope" means using more ambiguous terms, I can't see = why that would be an improvement. >> It has the flavor of "CT is obviously good, so let's just do it." >=20 > Okay. You've convinced me. >=20 > So: I've disabled syslog on all my servers. I can't define a-priori > what security issues logging might detect. Thus there's no point in > logging anything. 1. If CT were as useful and usable as syslog, I'd have fewer problems = with it. 2. syslog does not claim to "make it impossible to [xyz hacker thing] = without detection", whereas such claims have been made about CT [1]. 3. Nor is syslog presenting it as an IETF security-related protocol. 4. syslog isn't "overtly forcing" [2] architectural changes upon anyone = based on aforementioned false claims. Kind regards, Greg Slepak [1] = http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparenc= y/ [2] https://twitter.com/Cryptoki/status/514866111968706560 -- Please do not email me anything that you are not comfortable also = sharing with the NSA. --Apple-Mail=_F0A069FB-95D9-41BF-BC87-D46C4CED922A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 1, 2014, at 7:54 AM, David Leon Gil = <coruus@gmail.com> = wrote:

On Wed, Oct 1, 2014 at 10:32 AM, Stephen Kent <kent@bbn.com> wrote:
If a "broader scope" means using more ambiguous terms, I = can't see why that would be an improvement.
It has the flavor of "CT = is obviously good, so let's just do it."

Okay. = You've convinced me.

So: I've disabled syslog on all my servers. = I can't define a-priori
what security issues logging might detect. = Thus there's no point in
logging = anything.


1. If CT were as = useful and usable as syslog, I'd have fewer problems with = it.

2. syslog does not claim to "make it impossible = to [xyz hacker thing] without detection", whereas such claims have been = made about CT [1].

3. Nor is syslog presenting = it as an IETF security-related protocol.

4. = syslog isn't "overtly forcing" [2] architectural changes upon anyone = based on aforementioned false claims.

Kind = regards,
Greg Slepak


--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

= --Apple-Mail=_F0A069FB-95D9-41BF-BC87-D46C4CED922A-- --Apple-Mail=_DE45AF54-5181-493A-AB0C-A9DD64E5157F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJULCi9AAoJEOxnICvpCVJHh+EP/24yGIsSk3E51XHWhvjZfMhZ EgnEVkKpPulZRF7bj5CFP5ON96gr+EjQIv27EUfJTZWLpAx5OMIQtFfV/yF7nqDF 2ih43dmxCfBlIBpoB2QCH3yVGWINex684yTSXEd6VEjpPmni8X14lJW3sotbcWsl z+T4OjaZAl26q7Dg18LI78bxwlngDvpbRjK9YL3y2hVggTJQR5WtxzPOEHIjJwGI zEz06VWHd90qGcP2aGoxJ8S9dbIaASCiJNMSPSTiyM8VdqoWCyXS3dV2EXWG1tFb +Z/dRI2TO3AXR5vsuX096/Wy3As98cW83MJ3pvPBofxyfCqao4lAJlhQhjWdn/MJ JW81/6I1AsZ9CbL+nnrXJMGazhXHmiqWSj/OXXZDgFPjGV0+6nb7RNhIR1ZUXn+d 28KxAdPymZ2k6h0CZcNZRx1ccEP4EqArxInIArQm0uLde6VVdT4/jCGy5FC7Er/2 Bkzv9d0xXZLvnOlK8YDEKzJwlVRb4f5wwVZYrqeoNViMXzqdp99NfsWM9UMJRaCa xY7LSzJvrjZz7U66LBqrS5MesfxJA85FAGU4/bKypC6lfo9W10exakGTC15CGbrU edGXQJ6nDX7rKOn/n9GqaxJgVd95v/UweuQAVNm9y+cx26bDKQx/R6X+HepGbmrq ZCpF3tXUU4nrIaC898Yo =2W6A -----END PGP SIGNATURE----- --Apple-Mail=_DE45AF54-5181-493A-AB0C-A9DD64E5157F-- From nobody Wed Oct 1 10:51:05 2014 Return-Path: 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 EAF891A1AAA for ; Wed, 1 Oct 2014 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 g_xu5usyDCxj for ; Wed, 1 Oct 2014 10:50:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DC61A1AB2 for ; Wed, 1 Oct 2014 10:50:53 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43112 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZO3O-0007RR-6V for trans@ietf.org; Wed, 01 Oct 2014 13:51:06 -0400 Message-ID: <542C3EFA.7010204@bbn.com> Date: Wed, 01 Oct 2014 13:50:50 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------050401090801020605090905" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AnKafjhdvFpOHxX2O4F99DfBvcU Subject: [Trans] updated definition and attack analysis text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:51:03 -0000 This is a multi-part message in MIME format. --------------050401090801020605090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ignoring (for the moment) the suggestion to not consider syntactic mis-issuance, and the topic of whether logs might perform syntax checks on certs submitted to them, I have revised the attack analysis text. It at least provides a sense of the style and structure one wants in such text, and which is missing from 6962-bis. I've expanded the definitions of mis-issuance based on the message exchanges Ben and I had, to more clearly describe the cases of syntactic and semantic mis-issuance that are outside of the scope for CT, or that may be detectable only if a Subject operates its own Monitor. I also added structure to group the attack cases, to make for easier reading. I' ve kept the "notes" style, but these could be folded into the attack case analysis if desired. (It would just introduce some redundancy.) Steve ------ 1. Goals and Definitions The goal of Certificate Transparency (CT) is to detect mis-issuance of certificates, in the Web PKI context. It is anticipated that CT will help deter mis-issuance, e.g., by providing information to an affected Subject to facilitate revocation of a mis-issued certificate. 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?]. A certificate is characterized as mis-issued if the certificate does not conform to the requirements established by CA Browser Forum (CABF) documents for "domain validation" (DV) or "extended validation" (EV) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary forms syntactic mis-issuance and semantic mis-issuance. 1.A certificate may fail to meet the syntactic constraints imposed by the CABF guidelines. a.Most syntactic constraints from [CABF-Baseline] and [CABF-EV], can be checked via examination of a certificate chain, without reference to Subject-specific or CA-specific data. b.A few syntactic constraints require access to data specific to a CA or the Subject in question. 2.A certificate may fail to meet the semantic constraints imposed by the CABF guidelines. a.Most semantic constraints can be verified by comparing a certificate against one or more reference certificates for the Subject. b.Some semantic constraints cannot be verified by examining a certificate, even with reference certificate information. Most instances of the syntactic of mis-issuance can be detected by examining a certificate against a set of criteria extracted from the CABF guidelines. Based on whether a certificate purports to be a DV or an EV certificate, one can examine it against almost all of the syntactic constraints imposed by the guidelines. Appendix A, Section A.1 enumerates the syntactic criteria to be used in this case. These checks can be performed by a log before issuing an SCT, and if a (pre-) certificate fails these checks, it should not be issued. This behavior is RECOMMENDED to provide feedback to CAs, to detect potential syntactic mis-issuance before the certificate is issued. A few of the syntactic constraints cannot be verified in this fashion, e.g., because they require knowledge of the organizational relationships between "root" and subordinate CAs (see Section 9.3.3 of [CABF-Baseline].) Appendix A, Section A.2, notes these exception and notes that, in general, they cannot be checked by a Monitor or log, and thus there is no requirement to perform these checks. (A Monitor operated by a Subject on its own behalf has access to at least some of the data required to verify conformance to this latter set of syntactic constraints and thus SHOULD do so.) Detection of semantic mis-issuance as described in 2a above requires access to "reference" certificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificate issued to a specified Subject, consistent with the CABF guidelines.) The primary concern addressed by detection of semantic mis-issuance is that a certificate has been issued to an entity that is not authorized to represent the host (web server) named in the certificate Subject field (or subjectAltName extension). Other forms of semantic mis-issuance (2 b above) may arise due to procedural or operational violations of the CABF guidelines, but these may not be detectable by a third party, even with access to a reference certificate. For example, a Web PKI CA may fail to adhere to the audit procedures required in Section 15 of [CABF-Baseline]. CT elements (e.g., Monitors) are not able to detect these forms of mis-issuance because they are not externally visible. 1.Criminals 2.Hacktivists 3.Nation states (intelligence organizations) 4.Other? 2. Attack Model and Mitigation Mechanisms Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to redress mis-issuance depends on the context of the mis-issuance, and thus it is appropriate to examine the context as part of an attack model 2.1 A non-malicious Web PKI CA If the certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. Because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again. Thus syntactic mis-issuance of this type will be thwarted. 2.1.1 A CA may issue the certificate to an unauthorized party (Section 1, 2.a), as a result of an error or because it was the victim of a social engineering attack. In this case the CA has a record of the certificate and it is prepared to revoke the bogus certificate once it has been convinced of its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is "protecting" the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate does not contribute to the mitigation. (See Note 1 below.) 2.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar) which results in semantic mis-issuance of one or more certificates. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content. 2.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and alert the targeted Subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will depend on the certificate serial number provided via the log entry, to effect revocation. (See Notes 1 + 2 below.) If TLS clients reject a certificate when no SCT is present, this might motivate the attacker to log the bogus certificates, which helps justify such client behavior. 2.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.) 2.2 A Malicious Web PKI CA 2.2.1 If a certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. However, because the CA is presumed to be malicious, the certificate may be issued anyway. Thus checking for syntactic mis-issuance in this case does not, per se, prevent such mis-issuance. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case. 2.2.2 Because this CA is malicious, it may choose to not submit the certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case. 2.2.3 The CA may submit the bogus certificate to one or more logs that collude with this CA, and thus do not perform syntactic checks. In this case the syntactic mis-issuance will not be detected by logs. Unless Monitors (or Auditors?) also perform syntactic checks, this form of mis-issuance will not be thwarted in this case. 2.2.4 The malicious CA may semantically mis-issue a certificate, that is syntactically valid. We will refer to such a certificate as "bogus". Because it is syntactically valid, logs will not reject the certificate. This situation might result because the CA was bribed or was compelled to issue the bogus certificate. (A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.)This CA might be one or more tiers below a trust anchor (aka root CA). 2.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.) 2.2.4.2 A bogus certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor protecting the targeted Subject will detect a bogus certificate and alert the targeted subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. (It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc.) In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4 below.) 2.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will not detect the bogus certificate, even if it is protecting the target Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semantically mis-issued certificate. Auditors are intended to detect logs that conspire to suppress log entries, based on XXX. [is the unspecified gossip protocol need here? If so, then until we have this protocol, CT does not provide the necessary info to detect this form of mis-issuance.] If Auditors detect conspiring logs, Monitors and clients can be alerted to conspiring logs. This would cause clients to not accept SCTs generated by these logs, in the future. (See Note 5 below.) Notes: 1.If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide "sufficient" coverage. Of course, if a Subject acts as its own Monitor, this problem is solved for that Subject. 2.A CA being presented with evidence of a bogus certificate probably will require more than the serial number of the bogus certificate. It will want to verify the Issuer and Subject (subjectAltname) to ensure that the certificate being revoked is not one that it has knowingly issued legitimately. Thus a Subject should not expect immediate revocation of a contested certificate in all cases. (The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA.) Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on [CABF-Baseline] criteria. The SCT itself, because it contains a timestamp from a third party, is probably valuable for forensic purposes. 3.If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules. 4.A targeted Subject might request the parent or the offending CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If one can configure a browser to reject the specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. Moreover, this calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication is not specified. There are no standard ways to configure a browser to reject individual bogus certificates. Moreover, a malicious CA could easily issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks. 5.The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or mlore SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if clients reject certificates that contains SCTs from conspiring logs will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, the client MUST verify all of them if it is to counter the threat posed by conspiring logs. Absent a "gossip" protocol that enables Auditors to verify that data from logs are reported in a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance. Monitors play the critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. Thus Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden of Monitor operation may be viewed as to great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise. --------------050401090801020605090905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ignoring (for the moment) the suggestion to not consider syntactic mis-issuance,
and the topic of whether logs might perform syntax checks on certs submitted to them,
I have revised the attack analysis text. It at least provides a sense of the style
and structure one wants in such text, and which is missing from 6962-bis.

I've expanded the definitions of mis-issuance based on the message exchanges
Ben and I had, to more clearly describe the cases of syntactic and semantic
mis-issuance that are outside of the scope for CT, or that may be detectable only
if a Subject operates its own Monitor. I also added structure to group the attack cases,
to make for easier reading. I' ve kept the "notes" style, but these could be folded into
the attack case analysis if desired. (It would just introduce some redundancy.)

Steve

------

1. Goals and Definitions

 

The goal of Certificate Transparency (CT) is to detect mis-issuance of certificates, in the Web PKI context. It is anticipated that CT will help deter mis-issuance, e.g., by providing information to an affected Subject to facilitate revocation of a mis-issued certificate. 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?].

 

A certificate is characterized as mis-issued if the certificate does not conform to the requirements established by CA Browser Forum (CABF) documents for “domain validation” (DV) or “extended validation” (EV) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary forms syntactic mis-issuance and semantic mis-issuance.

 

1. A certificate may fail to meet the syntactic constraints imposed by the CABF guidelines.

a. Most syntactic constraints from [CABF-Baseline] and [CABF-EV], can be checked via examination of a certificate chain, without reference to Subject-specific or CA-specific data.

b. A few syntactic constraints require access to data specific to a CA or the Subject in question.

 

2. A certificate may fail to meet the semantic constraints imposed by the CABF guidelines.

a. Most semantic constraints can be verified by comparing a certificate against one or more reference certificates for the Subject.

b. Some semantic constraints cannot be verified by examining a certificate, even with reference certificate information.

 

Most instances of the syntactic of mis-issuance can be detected by examining a certificate against a set of criteria extracted from the CABF guidelines. Based on whether a certificate purports to be a DV or an EV certificate, one can examine it against almost all of the syntactic constraints imposed by the guidelines. Appendix A, Section A.1 enumerates the syntactic criteria to be used in this case. These checks can be performed by a log before issuing an SCT, and if a (pre-) certificate fails these checks, it should not be issued. This behavior is RECOMMENDED to provide feedback to CAs, to detect potential syntactic mis-issuance before the certificate is issued.

 

A few of the syntactic constraints cannot be verified in this fashion, e.g., because they require knowledge of the organizational relationships between “root” and subordinate CAs (see Section 9.3.3 of [CABF-Baseline].)  Appendix A, Section A.2, notes these exception and notes that, in general, they cannot be checked by a Monitor or log, and thus there is no requirement to perform these checks. (A Monitor operated by a Subject on its own behalf has access to at least some of the data required to verify conformance to this latter set of syntactic constraints and thus SHOULD do so.)

 

Detection of semantic mis-issuance as described in 2a above requires access to “reference” certificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificate issued to a specified Subject, consistent with the CABF guidelines.) The primary concern addressed by detection of semantic mis-issuance is that a certificate has been issued to an entity that is not authorized to represent the host (web server) named in the certificate Subject field (or subjectAltName extension).

 

Other forms of semantic mis-issuance (2 b above) may arise due to procedural or operational violations of the CABF guidelines, but these may not be detectable by a third party, even with access to a reference certificate. For example, a Web PKI CA may fail to adhere to the audit procedures required in Section 15 of [CABF-Baseline]. CT elements (e.g., Monitors) are not able to detect these forms of mis-issuance because they are not externally visible.

 

<Discuss classes of adversaries, motivations, and capabilities>

 

1. Criminals

 

2. Hacktivists

 

3. Nation states (intelligence organizations)

 

4. Other?

 

 

 

2. Attack Model and Mitigation Mechanisms

 

Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to redress mis-issuance depends on the context of the mis-issuance, and thus it is appropriate to examine the context as part of an attack model

 

2.1 A non-malicious Web PKI CA

 

If the certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. Because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again. Thus syntactic mis-issuance of this type will be thwarted.

 

2.1.1 A CA may issue the certificate to an unauthorized party (Section 1, 2.a), as a result of an error or because it was the victim of a social engineering attack. In this case the CA has a record of the certificate and it is prepared to revoke the bogus certificate once it has been convinced of its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is “protecting” the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate does not contribute to the mitigation. (See Note 1 below.)

 

2.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar) which results in semantic mis-issuance of one or more certificates. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content.

 

2.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and alert the targeted Subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will depend on the certificate serial number provided via the log entry, to effect revocation. (See Notes 1 + 2 below.) If TLS clients reject a certificate when no SCT is present, this might motivate the attacker to log the bogus certificates, which helps justify such client behavior.

 

2.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.)

 

2.2 A Malicious Web PKI CA

 

2.2.1 If a certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. However, because the CA is presumed to be malicious, the certificate may be issued anyway. Thus checking for syntactic mis-issuance in this case does not, per se, prevent such mis-issuance. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case.

 

2.2.2 Because this CA is malicious, it may choose to not submit the certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case.

 

2.2.3 The CA may submit the bogus certificate to one or more logs that collude with this CA, and thus do not perform syntactic checks. In this case the syntactic mis-issuance will not be detected by logs. Unless Monitors (or Auditors?) also perform syntactic checks, this form of mis-issuance will not be thwarted in this case.

 

2.2.4 The malicious CA may semantically mis-issue a certificate, that is syntactically valid. We will refer to such a certificate as “bogus”. Because it is syntactically valid, logs will not reject the certificate. This situation might result because the CA was bribed or was compelled to issue the bogus certificate. (A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.)  This CA might be one or more tiers below a trust anchor (aka root CA).

 

2.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.)

 

2.2.4.2 A bogus certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor protecting the targeted Subject will detect a bogus certificate and alert the targeted subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. (It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc.) In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4 below.)

 

2.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will not detect the bogus certificate, even if it is protecting the target Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semantically mis-issued certificate. Auditors are intended to detect logs that conspire to suppress log entries, based on XXX. [is the unspecified gossip protocol need here? If so, then until we have this protocol, CT does not provide the necessary info to detect this form of mis-issuance.]  If Auditors detect conspiring logs, Monitors and clients can be alerted to conspiring logs. This would cause clients to not accept SCTs generated by these logs, in the future. (See Note 5 below.)

 

Notes:

 

1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide “sufficient” coverage. Of course, if a Subject acts as its own Monitor, this problem is solved for that Subject.

 

2. A CA being presented with evidence of a bogus certificate probably will require more than the serial number of the bogus certificate. It will want to verify the Issuer and Subject (subjectAltname) to ensure that the certificate being revoked is not one that it has knowingly issued legitimately. Thus a Subject should not expect immediate revocation of a contested certificate in all cases. (The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA.) Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on [CABF-Baseline] criteria. The SCT itself, because it contains a timestamp from a third party, is probably valuable for forensic purposes.

 

3. If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules.

 

4. A targeted Subject might request the parent or the offending CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If one can configure a browser to reject the specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. Moreover, this calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication is not specified. There are no standard ways to configure a browser to reject individual bogus certificates. Moreover, a malicious CA could easily issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks.

 

5. The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or mlore SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if clients reject certificates that contains SCTs from conspiring logs will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, the client MUST verify all of them if it is to counter the threat posed by conspiring logs.

 

 

Absent a “gossip” protocol that enables Auditors to verify that data from logs are reported in a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance.

 

Monitors play the critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. Thus Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden of Monitor operation may be viewed as to great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise.


--------------050401090801020605090905-- From nobody Thu Oct 2 07:51:45 2014 Return-Path: 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 089C21A039B for ; Thu, 2 Oct 2014 07:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] 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 IuRVynIy0Lq3 for ; Thu, 2 Oct 2014 07:51:41 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE23F1A016B for ; Thu, 2 Oct 2014 07:51:40 -0700 (PDT) Received: (qmail 15430 invoked by uid 1000); 2 Oct 2014 14:51:37 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 02 Oct 2014 15:51:37 +0100 Message-ID: <542D6678.9060507@comodo.com> Date: Thu, 02 Oct 2014 15:51:36 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Peter Bowen 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/CfTYmMj1n1izaU27dAyn6cQun1o Cc: "trans@ietf.org" , Stephen Kent 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:51:44 -0000 On 01/10/14 16:45, Peter Bowen wrote: > On Wed, Oct 1, 2014 at 8:32 AM, Rob Stradling wrote: >> 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? > > This feels like an interesting feature for CT log hosts. An > additional API that allows subscribing to the "firehose" of all log > entries as they happen. Hi Peter. Are you suggesting making something like [1] an integral part of log servers, rather than an optional/separate service? [1] https://groups.google.com/forum/#!topic/certificate-transparency/h4quw0htujs > I wonder how many certificates per second Comodo is issuing these days with > the CloudFlare annoucement... Let's just say that our systems have been unusually busy this week. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Oct 2 08:18:12 2014 Return-Path: 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 14E6B1A1A0A for ; Thu, 2 Oct 2014 08:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 bpzcMPQwh5HV for ; Thu, 2 Oct 2014 08:18:08 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140B41A19E9 for ; Thu, 2 Oct 2014 08:18:07 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so4330114wiv.11 for ; Thu, 02 Oct 2014 08:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aKdTnt2ABj1mNBM+AnBeX9mt+vhRV7HeyXMNAOBMT6Q=; b=zulzBYK2US7Q8OGDy5hiidXmq85oIZndyXpFJYbTRRge912D6XA6jYZAg2EolTkQ90 2udmB3fnt514+jAdDaPtim1QnxJiT28BTkpUt55KId3fYPwGT1fpjNIZy8/oV8jrzrUl kTdzmHuYm62n4C1xq6LhY12MaTulIpSFN6+RXyiaqWnd7lvd6/DZVWnkT4U2T2ZoIMq5 gs2nVmY3Mrmc5ny+CyR/0M1/VKh+xexfupX7slM95k0i/6vIk/whlI7jYn/ekxzqDA5k HNl2wTT3TZgeqiEXCn0RYH4/0I5+BKquilkCH+4ZOsLfqYVOCwfWfvn7m3ZARkUOQqYl taxw== MIME-Version: 1.0 X-Received: by 10.194.134.201 with SMTP id pm9mr15239514wjb.130.1412263086649; Thu, 02 Oct 2014 08:18:06 -0700 (PDT) Received: by 10.27.79.193 with HTTP; Thu, 2 Oct 2014 08:18:06 -0700 (PDT) In-Reply-To: <542D6678.9060507@comodo.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> <542D6678.9060507@comodo.com> Date: Thu, 2 Oct 2014 08:18:06 -0700 Message-ID: From: Peter Bowen To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/eAjXPbJDaoFyaC0W9RB9-SWceBI Cc: "trans@ietf.org" , Stephen Kent 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:18:10 -0000 On Thu, Oct 2, 2014 at 7:51 AM, Rob Stradling wrote: > On 01/10/14 16:45, Peter Bowen wrote: >> >> On Wed, Oct 1, 2014 at 8:32 AM, Rob Stradling >> wrote: >>> >>> 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? >> >> >> This feels like an interesting feature for CT log hosts. An >> additional API that allows subscribing to the "firehose" of all log >> entries as they happen. > > Are you suggesting making something like [1] an integral part of log > servers, rather than an optional/separate service? > > > [1] > https://groups.google.com/forum/#!topic/certificate-transparency/h4quw0htujs I was more thinking of a streaming API[2], such that a client could to an receive immediate notification of _every_ add-chain or add-pre-chain call that included both the chain and the return values. Think real-time monitoring instead of fetching the log data using the get-* calls. Thanks, Peter [2] See https://dev.twitter.com/streaming/public for Twitter's explanation of streaming API From nobody Thu Oct 2 09:13:57 2014 Return-Path: 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 ED2CE1A8760 for ; Thu, 2 Oct 2014 09:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uzIyDwJ-P7Gs for ; Thu, 2 Oct 2014 09:13:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EFF1A0158 for ; Thu, 2 Oct 2014 09:13:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38305 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZj0o-000Eqi-1F; Thu, 02 Oct 2014 12:13:50 -0400 Message-ID: <542D79AD.3070702@bbn.com> Date: Thu, 02 Oct 2014 12:13:33 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Leon Gil References: <5411E511.1040605@bbn.com> <54173589.3000404@bbn.com> <54242F8A.2080602@bbn.com> <54258AF0.7090602@bbn.com> <54297249.1090409@bbn.com> <542C1063.50404@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AkX6Tmmxuv-R5yEwWK4Vxeqcrdw Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] Threat model outline, attack model X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:13:48 -0000 David, > On Wed, Oct 1, 2014 at 10:32 AM, Stephen Kent wrote: >> If a "broader scope" means using more ambiguous terms, I can't see why that would be an improvement. >> It has the flavor of "CT is obviously good, so let's just do it." > Okay. You've convinced me. > > So: I've disabled syslog on all my servers. I can't define a-priori > what security issues logging might detect. Thus there's no point in > logging anything. This is a very poor analogy for many reasons, as Greg has already noted. Steve From nobody Thu Oct 2 09:14:03 2014 Return-Path: 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 6D8AE1A0158 for ; Thu, 2 Oct 2014 09:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HqVpossgWi_j for ; Thu, 2 Oct 2014 09:13:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C901A8789 for ; Thu, 2 Oct 2014 09:13:43 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50710 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZj0g-000Jgs-OD for trans@ietf.org; Thu, 02 Oct 2014 12:13:42 -0400 Message-ID: <542D79B5.7080508@bbn.com> Date: Thu, 02 Oct 2014 12:13:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" 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> In-Reply-To: <542C1EA6.8050106@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/kRxGM4NOFNMmkxH8Eb9UDXuoG9o 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:13:49 -0000 Rob, > On 01/10/14 16:05, Stephen Kent wrote: > >> Rick, > >> 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 3. the cert conforms to EV guidelines - 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 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 From nobody Thu Oct 2 09:14:18 2014 Return-Path: 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 12BB31A87CD for ; Thu, 2 Oct 2014 09:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 k3U3uYkF0LmL for ; Thu, 2 Oct 2014 09:13:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1581A8789 for ; Thu, 2 Oct 2014 09:13:50 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38307 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZj11-000Eqs-VS; Thu, 02 Oct 2014 12:14:04 -0400 Message-ID: <542D79BB.1030900@bbn.com> Date: Thu, 02 Oct 2014 12:13:47 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Leon Gil References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C0FCB.7010906@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ul73Iw-XaziRaLtAElkgnRcitTY Cc: "trans@ietf.org" Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:13:58 -0000 David, > On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent wrote: >> I disagree. Once Ben said that he meant mis-issuance to be interpreted in a >> much broader context, >> and cited EV cert requirements as an example, I pursued documenting what >> that would mean. If >> the WG wants to say that mis-issuance is more than issuing a cert to the >> wrong Subject, then >> we need to say just what it is, not hand wave. > You are missing the point of certificate transparency. I may, since the definition of the goals seem to change over time. > We have no idea all the forms that misissuance -- particularly > malicious misissuance -- might take. If it were trivial to detect > "misissuance", browsers would validate certs for "misissuance" and the > problem would be solved. History suggests otherwise. We have seen many examples of browsers not performing cert path validation correctly, e.g., not paying attention to the basicConstrants extension (with serious security consequences), etc. So browsers are not a reliable way to deal with many cert-related security concerns. More to the point, CT is a set of external mechanisms designed to detect mis-issuance that might not be visible to an individual TLS client. So your argument that if it were trivial to detect, browsers would do it, is way off the mark. > The point of having a log that includes everything signed with a CA's > key is that analysis of issued certificates can be conducted post-hoc. Well, to be accurate, CRLs are not logged, as per the current proposal, so it's not "everything signed with a CA's key." But, irrespective of that detail, I am not suggesting that we alter the post-hoc analysis; I was suggesting that there might be benefits to checking at the time of issuance, principally in the case of pre-certs. > Proposals to limit the scope of what logs can log kneecap CT. They > should not be considered. What CT does should or should not be ought to be justified based on an analysis of attacks and what CT does to address them, not on blanket statements that mis-issuance cannot be defined. Steve From nobody Thu Oct 2 09:14:20 2014 Return-Path: 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 CCDA61A87CE for ; Thu, 2 Oct 2014 09:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CCdBtkM2GIfF for ; Thu, 2 Oct 2014 09:14:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14341A8789 for ; Thu, 2 Oct 2014 09:13:59 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50712 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZj0w-000JhG-Da; Thu, 02 Oct 2014 12:13:58 -0400 Message-ID: <542D79C4.9080405@bbn.com> Date: Thu, 02 Oct 2014 12:13:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rob Stradling , trans@ietf.org References: <54296FB2.1060109@bbn.com><4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com><544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com><544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><20140930005524.GP16215@hezmatt.org> <542C10ED.2060902@bbn.com> <542C1955.7080304@comodo.com> In-Reply-To: <542C1955.7080304@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Dcq1aM7t3G_WFMXS-DW4ADCW2KQ Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:14:08 -0000 Rob, > On 01/10/14 15:34, Stephen Kent wrote: > >> I thought the CT design makes a counter argument, i.e., that CAs are >> motivated to log certs because, over time, TLS clients will reject >> connections to servers when there is no evidence of an SCT. > > Over time, yes, we hope that this will happen. But we obviously can't > guarantee that, in N months/years from now, 100% of TLS clients will > support CT. I agree, which is why I suggested that text to the contrary be modified in 6962-bis. > >> if this argument is true, then having logs check for syntactic >> mis-issuance is a good thing. > > I disagree. There is a gap between what is syntactically properly > issued (according to CABF guidelines, etc) and what a typical TLS > client actually accepts. is that a good thing? > If logs checked for syntactic mis-issuance, a rogue CA could exploit > this gap by maliciously mis-issuing certs containing "syntax errors". > CT would not reveal the attack (because the logs would refuse to issue > SCTs), but TLS clients that don't reject connections when no SCT is > provided would be vulnerable. See my attack analysis, which notes this as part of the larger set of what CT can and cannot detect. > We want to provide as much "herd immunity" as possible to TLS clients > that don't support CT. This means that we need all certs to be > publicly logged, to maximize the chances that any (maliciously) > mis-issued cert will be discovered quickly. That's a clear statement about wanting to protect clients who don't implement CT, i.e., don't mandate the presence of an SCT. That's a reasonable argument, better that a mere assertion that "logging is good." It belongs in 6962-bis. See my revised proposal on syntax checking, which addresses this. Steve From nobody Thu Oct 2 09:25:56 2014 Return-Path: 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 8F60E1A882F for ; Thu, 2 Oct 2014 09:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 VsHx_Fxf-cWi for ; Thu, 2 Oct 2014 09:25:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0201A878F for ; Thu, 2 Oct 2014 09:25:44 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36063 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZjCY-000EzY-1j for trans@ietf.org; Thu, 02 Oct 2014 12:25:58 -0400 Message-ID: <542D7C85.2050401@bbn.com> Date: Thu, 02 Oct 2014 12:25:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5429C24B.1050002@gmail.com> <542C1008.4060500@bbn.com> <542C181C.8040109@cs.tcd.ie> In-Reply-To: <542C181C.8040109@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------090800080607060403030401" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hSekzweoJjZHGXyErFxFjpokCsA Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:25:48 -0000 This is a multi-part message in MIME format. --------------090800080607060403030401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen, > Hiya, > > On 01/10/14 15:30, Stephen Kent wrote: >> How can we proceed on CT if we don't have a solid definition of the >> problem it purports to address? Certainly detecting mis-issuance >> has to be well-defined. > I think this is the crux of the matter. > > Mis-issuance is not a feature but a bug. Attempting to > describe all possible bugs of any sort is futile. If you > argue that a CT RFC has to describe all possible bugs, then > that amounts to arguing to not do CT. I didn't say that, don't put words in my mouth. > But the IETF has > reached consensus to do CT I think that's s an overstatement. This WG was formed without a BoF. So the usual IETF consensus process was not followed. You persuaded your fellow IESG members to approve the WG and to use the Experimental RFC as the starting point for a standard track RFC. I doubt that many of them paid close attention to the Experimental RFC. In any case, the charter does not use the term "rubber stamp" so I think we're free to revisit the design, which is under-specified, lacks a security analysis, etc. > so it seems that others do not > agree with you that "detecting mis-issuance has to be > well-defined" at least if that is meant to call for a > complete enumeration of all the ways in which mis-issuance > might occur. (And I don't get what else you might have > meant, but please correct me if I'm misreading what > you've written.) Again, don't mis-characterize what I have said. One need not enumerate _all_ the ways that a cert can be mis-issued. One can, however, should be able to characterize classes of behavior that constitute mis-issuance, unless one is _trying_ to be ambiguous. Within the classes of mis-issuance it ought to be possible to enumerate a fair number of MUSTs, to note when no external examination of certs can detect mis-issuance, and to note when mis-issuance can be detected based on specified, per-Subject (and/or per-Issuer) data. These all seem like reasonable characterizations that ought to be pursued. I have been doing so in the text I've provided. > Having some examples of mis-issuance described is quite > reasonable. Asking that all forms of mis-issuance be > documented is not reasonable. ibid. > Now as to CABF, while its very reasonable to think about > their requirements, I don't think it'd be a good plan > to hard-code a dependency on a version of those into a CT > RFC. Their baseline reqs doc has changed 3 times this year > already for example and 5 times in 2013 and I suspect will > continue to evolve significantly. We can accommodate changes in specs; we do it in other contexts. I looked at the 3 2014 versions of the baseline spec, using the diff's the CABF provides on its website. None of the changes in 2014 affected any of the requirements included in my proposed Appendix. Looking at the 2013 changes, the only one I noted that had real impact on the syntax checks I proposed was version 1.1.6 (July 2013). In that version the discussion of EKU and nameConstraints was added. That change relates to just one set of syntactic checks. In 1.1.4, they added DSA modulus/divisor constraints. This is precisely what Ben cited as a cert mis-issuance criteria, so, presumably, we would want to update our specs accordingly. Given that, over the past 2 years, there have been only two changes that have any impact on the syntax checks I enumerated, and that they impact only two of the detailed chekcs, I think this argument is a red herring. > But if you see a stable useful and quotable definition of > mis-issuance in one of their documents, then sending a > pointer to that text would be good. I don't know if there > is such a piece of text though. First, they would never define mis-issuance, any more than 5280 would define a defective cert, per se, so the suggestion is silly, Stephen. The guidelines define requirements for the format of certs (DV and EV) and procedures for cert issuance by CAs. So, one develops a definition for syntactic mis-issuance, based on their guidelines, by noting violations of the format MUSTs. Semantic mis-issuance is similarly defined. Steve p.s. Yes, I agree that CABF is not an SDO, but neither was the source of PKCS doc when the IETF elected to use them as the basis for CMS. --------------090800080607060403030401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen,
Hiya,

On 01/10/14 15:30, Stephen Kent wrote:

How can we proceed on CT if we don't have a solid definition of the
problem it purports to address? Certainly detecting mis-issuance
has to be well-defined.

I think this is the crux of the matter.

Mis-issuance is not a feature but a bug. Attempting to
describe all possible bugs of any sort is futile. If you
argue that a CT RFC has to describe all possible bugs, then
that amounts to arguing to not do CT.
I didn't say that, don't put words in my mouth.
But the IETF has
reached consensus to do CT
I think that's s an overstatement. This WG was formed without a BoF.
So the usual IETF consensus process was not followed. You persuaded your
fellow IESG members to approve the WG and to use the Experimental RFC as
the starting point for a standard track RFC. I doubt that many of them
paid close attention to the Experimental RFC. In any case, the charter
does not use the term "rubber stamp" so I think we're free to revisit
the design, which is under-specified, lacks a security analysis, etc. 
so it seems that others do not
agree with you that "detecting mis-issuance has to be
well-defined" at least if that is meant to call for a
complete enumeration of all the ways in which mis-issuance
might occur. (And I don't get what else you might have
meant, but please correct me if I'm misreading what
you've written.)
Again, don't mis-characterize what I have said. One need not
enumerate all the ways that a cert can be mis-issued. One can,
however, should be able to characterize classes of behavior that
constitute mis-issuance, unless one is trying to be ambiguous. Within
the classes of mis-issuance it ought to be possible to enumerate a fair
number of MUSTs, to note when no external examination of certs can detect
mis-issuance, and to note when mis-issuance can be detected based on specified,
per-Subject (and/or per-Issuer) data. These all seem like reasonable characterizations
that ought to be pursued. I have been doing so in the text I've provided.
Having some examples of mis-issuance described is quite
reasonable. Asking that all forms of mis-issuance be
documented is not reasonable.
ibid.
Now as to CABF, while its very reasonable to think about
their requirements, I don't think it'd be a good plan
to hard-code a dependency on a version of those into a CT
RFC. Their baseline reqs doc has changed 3 times this year
already for example and 5 times in 2013 and I suspect will
continue to evolve significantly.
We can accommodate changes in specs; we do it in other contexts.
I looked at the 3 2014 versions of the baseline spec, using the
diff's the CABF provides on its website.  None of the changes in 2014
affected any of the requirements included in my proposed Appendix.

Looking at the 2013 changes, the only one I noted that had real impact on the
syntax checks I proposed was version 1.1.6 (July 2013). In that version
the discussion of EKU and nameConstraints was added. That change relates
to just one set of syntactic checks. In 1.1.4, they added DSA modulus/divisor
constraints. This is precisely what Ben cited as a cert mis-issuance criteria,
so, presumably, we would want to update our specs accordingly.

Given that, over the past 2 years, there have been only two changes that
have any impact on the syntax checks I enumerated, and that they impact
only two of the detailed chekcs, I think this argument is a red herring.
But if you see a stable useful and quotable definition of
mis-issuance in one of their documents, then sending a
pointer to that text would be good. I don't know if there
is such a piece of text though.
First, they would never define mis-issuance, any more than 5280
would define a defective cert, per se, so the suggestion is silly,
Stephen. The guidelines define requirements for the format of certs (DV and EV)
and procedures for cert issuance by CAs. So, one develops a definition for syntactic
mis-issuance, based on their guidelines, by noting violations of the format MUSTs.
Semantic mis-issuance is similarly defined.

Steve

p.s. Yes, I agree that CABF is not an SDO, but neither was the source of PKCS
doc when the IETF elected to use them as the basis for CMS.
--------------090800080607060403030401-- From nobody Thu Oct 2 10:37:22 2014 Return-Path: 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 764081A8F43 for ; Thu, 2 Oct 2014 10:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.045 X-Spam-Level: X-Spam-Status: No, score=-99.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] 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 DmJp2-7XxeLD for ; Thu, 2 Oct 2014 10:37:20 -0700 (PDT) Received: from odin.smetech.net (unknown [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E49A71A8F35 for ; Thu, 2 Oct 2014 10:37:19 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 862A49A442D for ; Thu, 2 Oct 2014 13:37:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id P2Sph3rPQqN9 for ; Thu, 2 Oct 2014 13:36:46 -0400 (EDT) Received: from [192.168.2.108] (pool-96-255-133-207.washdc.fios.verizon.net [96.255.133.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CB38C9A4451 for ; Thu, 2 Oct 2014 13:36:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <542C181C.8040109@cs.tcd.ie> Date: Thu, 2 Oct 2014 13:36:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <07D8C2F5-59B1-4750-B65F-A8B0DF30DDD7@vigilsec.com> References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5429C24B.1050002@gmail.com> <542C1008.4060500@bbn.com> <542C181C.8040109@cs.tcd.ie> To: trans@ietf.org X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2VKnFOB3llbKDgV1cKbWW99gung Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:37:21 -0000 Stephen Farrell and Steve Kent: > On 01/10/14 15:30, Stephen Kent wrote: >> How can we proceed on CT if we don't have a solid definition of the >> problem it purports to address? Certainly detecting mis-issuance >> has to be well-defined. >=20 > I think this is the crux of the matter. >=20 > Mis-issuance is not a feature but a bug. Attempting to > describe all possible bugs of any sort is futile. If you > argue that a CT RFC has to describe all possible bugs, then > that amounts to arguing to not do CT. But the IETF has > reached consensus to do CT so it seems that others do not > agree with you that "detecting mis-issuance has to be > well-defined" at least if that is meant to call for a > complete enumeration of all the ways in which mis-issuance > might occur. (And I don't get what else you might have > meant, but please correct me if I'm misreading what > you've written.) >=20 > Having some examples of mis-issuance described is quite > reasonable. Asking that all forms of mis-issuance be > documented is not reasonable. >=20 > Now as to CABF, while its very reasonable to think about > their requirements, I don't think it'd be a good plan > to hard-code a dependency on a version of those into a CT > RFC. Their baseline reqs doc has changed 3 times this year > already for example and 5 times in 2013 and I suspect will > continue to evolve significantly. >=20 > But if you see a stable useful and quotable definition of > mis-issuance in one of their documents, then sending a > pointer to that text would be good. I don't know if there > is such a piece of text though. >=20 > Cheers, > S. >=20 > PS: I'm not sure CABF would describe themselves as an SDO > either, but that's a mere matter of terminology. I think it is fairly easy to define mis-issuance, but I think it is = nearly impossible to detect mis-issuance by an independent third party. To my way of thinking, mis-issuance is a certificate that is issued in = violation to some aspect of the certificate policy identified in the = certificate itself. I can think of very many policy violations that are = not visible in the certificate itself. Russ From nobody Thu Oct 2 13:28:41 2014 Return-Path: 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 3F0801A8714 for ; Thu, 2 Oct 2014 13:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NVPkpLJl6hDG for ; Thu, 2 Oct 2014 13:28:31 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA5B1A870E for ; Thu, 2 Oct 2014 13:28:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,640,1406606400"; d="scan'208,217";a="4305189" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 02 Oct 2014 16:28:30 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 16:28:29 -0400 From: Santosh Chokhani To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] updated definition and attack analysis text Thread-Index: AQHP3aBJzE0wM8osr0i7nW4ODSW41ZwdOxdg Date: Thu, 2 Oct 2014 20:28:28 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E8113923603B@scygexch10.cygnacom.com> References: <542C3EFA.7010204@bbn.com> In-Reply-To: <542C3EFA.7010204@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.7] Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E8113923603Bscygexch10cygnaco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/n54IRJg1nH1vSoLv0vAWFSCPId0 Subject: Re: [Trans] updated definition and attack analysis text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:28:39 -0000 --_000_4262AC0DB9856847A2D00EF817E8113923603Bscygexch10cygnaco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, Thanks. My primary concern with the analysis is that it does not discuss the practi= cality and resources and data required for the monitoring activity. It is= quite possible that monitoring will not be done at all or will miss things= or will be ineffective leaving the benefit of CT to largely as a deterrent= as opposed to detection mechanism. Threat analysis may wish to point that= out with significant emphasis since 6962 does not seem to emphasize this e= nough. I see CAs offering to perform monitoring service, which will not de= tect problems if the authorized CA or RA are compromised or have gone rogue= . In summary, the last paragraph of the analysis may wish to point out the= monitors may require subjects to use secure means to provide a list of val= id certificates from time to time and for monitor to check the logs for mis= -issuance against this list. 6962 does not address the critical aspect of = monitoring from the perspective of checking that the certificates are legit= imate. While just about everyone is against checking the certification path and ce= rtificate, but if the goal is to secure Web PKI, to improve user experience= or at least protect less informed users from making bad choices when a bro= wser barfs, I would think checking certificate, certification path, and eve= n cipher suites including proper range for RSA public exponent are good thi= ngs. On specifics of your analysis, on Note 2, I would think the CA may wish to = get the whole certificate to verify that the certificate was issued by it b= y verifying the signature using its own public keys. From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, October 01, 2014 1:51 PM To: trans@ietf.org Subject: [Trans] updated definition and attack analysis text Ignoring (for the moment) the suggestion to not consider syntactic mis-issu= ance, and the topic of whether logs might perform syntax checks on certs submitte= d to them, I have revised the attack analysis text. It at least provides a sense of th= e style and structure one wants in such text, and which is missing from 6962-bis. I've expanded the definitions of mis-issuance based on the message exchange= s Ben and I had, to more clearly describe the cases of syntactic and semantic mis-issuance that are outside of the scope for CT, or that may be detectabl= e only if a Subject operates its own Monitor. I also added structure to group the = attack cases, to make for easier reading. I' ve kept the "notes" style, but these could b= e folded into the attack case analysis if desired. (It would just introduce some redundan= cy.) Steve ------ 1. Goals and Definitions The goal of Certificate Transparency (CT) is to detect mis-issuance of cert= ificates, in the Web PKI context. It is anticipated that CT will help deter= mis-issuance, e.g., by providing information to an affected Subject to fac= ilitate revocation of a mis-issued certificate. The Web PKI context refers = to the use of a set of Certification Authorities (CAs) that issue X.509 cer= tificates to web servers to enable TLS-protected access by clients [cite WP= KOPS?]. A certificate is characterized as mis-issued if the certificate does not co= nform to the requirements established by CA Browser Forum (CABF) documents = for "domain validation" (DV) or "extended validation" (EV) certificates [CA= BF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary fo= rms syntactic mis-issuance and semantic mis-issuance. 1. A certificate may fail to meet the syntactic constraints imposed by the = CABF guidelines. a. Most syntactic constraints from [CABF-Baseline] and [CABF-EV], can be ch= ecked via examination of a certificate chain, without reference to Subject-= specific or CA-specific data. b. A few syntactic constraints require access to data specific to a CA or t= he Subject in question. 2. A certificate may fail to meet the semantic constraints imposed by the C= ABF guidelines. a. Most semantic constraints can be verified by comparing a certificate aga= inst one or more reference certificates for the Subject. b. Some semantic constraints cannot be verified by examining a certificate,= even with reference certificate information. Most instances of the syntactic of mis-issuance can be detected by examinin= g a certificate against a set of criteria extracted from the CABF guideline= s. Based on whether a certificate purports to be a DV or an EV certificate,= one can examine it against almost all of the syntactic constraints imposed= by the guidelines. Appendix A, Section A.1 enumerates the syntactic criter= ia to be used in this case. These checks can be performed by a log before i= ssuing an SCT, and if a (pre-) certificate fails these checks, it should no= t be issued. This behavior is RECOMMENDED to provide feedback to CAs, to de= tect potential syntactic mis-issuance before the certificate is issued. A few of the syntactic constraints cannot be verified in this fashion, e.g.= , because they require knowledge of the organizational relationships betwee= n "root" and subordinate CAs (see Section 9.3.3 of [CABF-Baseline].) Appen= dix A, Section A.2, notes these exception and notes that, in general, they = cannot be checked by a Monitor or log, and thus there is no requirement to = perform these checks. (A Monitor operated by a Subject on its own behalf ha= s access to at least some of the data required to verify conformance to thi= s latter set of syntactic constraints and thus SHOULD do so.) Detection of semantic mis-issuance as described in 2a above requires access= to "reference" certificates associated with a specified Subject. (For purp= oses of this discussion, a reference certificate is a valid certificate iss= ued to a specified Subject, consistent with the CABF guidelines.) The prima= ry concern addressed by detection of semantic mis-issuance is that a certif= icate has been issued to an entity that is not authorized to represent the = host (web server) named in the certificate Subject field (or subjectAltName= extension). Other forms of semantic mis-issuance (2 b above) may arise due to procedura= l or operational violations of the CABF guidelines, but these may not be de= tectable by a third party, even with access to a reference certificate. For= example, a Web PKI CA may fail to adhere to the audit procedures required = in Section 15 of [CABF-Baseline]. CT elements (e.g., Monitors) are not able= to detect these forms of mis-issuance because they are not externally visi= ble. 1. Criminals 2. Hacktivists 3. Nation states (intelligence organizations) 4. Other? 2. Attack Model and Mitigation Mechanisms Certificate mis-issuance may arise in one of several ways. The ways that CT= enables a Subject (or others) to redress mis-issuance depends on the conte= xt of the mis-issuance, and thus it is appropriate to examine the context a= s part of an attack model 2.1 A non-malicious Web PKI CA If the certificate is submitted to a log prior to issuance (a pre-certifica= te), the (generally) detectable forms of syntactic mis-issuance (Section 1,= 1.a) will be detected, and the certificate will not be logged. Because the= CA is non-malicious, it will remedy the syntactic problem and re-submit th= e (pre-) certificate to a log again. Thus syntactic mis-issuance of this ty= pe will be thwarted. 2.1.1 A CA may issue the certificate to an unauthorized party (Section 1, 2= .a), as a result of an error or because it was the victim of a social engin= eering attack. In this case the CA has a record of the certificate and it i= s prepared to revoke the bogus certificate once it has been convinced of it= s error. If the CA is submitting (pre-) certificates for logging, there wil= l be evidence of the mis-issuance in one or more logs. If a Monitor is "pro= tecting" the targeted Subject, it will detect the mis-issuance, and will al= ert the Subject. Because the CA has a record of the mis-issuance, it should= revoke the bogus certificate, after investigating, based on the informatio= n provided by the legitimate certificate Subject. The presence of an embedd= ed SCT in the bogus certificate, or an SCT accompanying the bogus certifica= te does not contribute to the mitigation. (See Note 1 below.) 2.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack = (c.f., DigiNotar) which results in semantic mis-issuance of one or more cer= tificates. In this case the CA is not aware of the mis-issuance and may hav= e no record of the certificate content. 2.1.2.1 The mis-issued certificate may have been submitted to one or more l= ogs prior to issuance, to acquire an embedded SCT, or post-issuance to acqu= ire a standalone SCT. In either case, a Monitor that is protecting the targ= eted Subject will detect the bogus certificate and alert the targeted Subje= ct. The Subject, in turn, will request the CA to revoke the bogus certifica= te. In this case, the CA will depend on the certificate serial number provi= ded via the log entry, to effect revocation. (See Notes 1 + 2 below.) If TL= S clients reject a certificate when no SCT is present, this might motivate = the attacker to log the bogus certificates, which helps justify such client= behavior. 2.1.2.2 The bogus certificate may not have been submitted to any logs. In t= his case, Monitors will not detect the bogus certificate. If clients reject= a certificate that lacks (or is not accompanied by) an SCT, the attacker w= ill be thwarted in this case. (See Note 3 below.) 2.2 A Malicious Web PKI CA 2.2.1 If a certificate is submitted to a log prior to issuance (a pre-certi= ficate), the (generally) detectable forms of syntactic mis-issuance (Sectio= n 1, 1.a) will be detected, and the certificate will not be logged. However= , because the CA is presumed to be malicious, the certificate may be issued= anyway. Thus checking for syntactic mis-issuance in this case does not, pe= r se, prevent such mis-issuance. However, if clients reject a certificate t= hat lacks (or is not accompanied by) an SCT, this form of mis-issuance will= be thwarted in this case. 2.2.2 Because this CA is malicious, it may choose to not submit the certifi= cate to a log. This avoids detection of syntactic mis-issuance by a log, bu= t it also means there is no SCT for the certificate. However, if clients re= ject a certificate that lacks (or is not accompanied by) an SCT, this form = of mis-issuance will be thwarted in this case. 2.2.3 The CA may submit the bogus certificate to one or more logs that coll= ude with this CA, and thus do not perform syntactic checks. In this case th= e syntactic mis-issuance will not be detected by logs. Unless Monitors (or = Auditors?) also perform syntactic checks, this form of mis-issuance will no= t be thwarted in this case. 2.2.4 The malicious CA may semantically mis-issue a certificate, that is sy= ntactically valid. We will refer to such a certificate as "bogus". Because = it is syntactically valid, logs will not reject the certificate. This situa= tion might result because the CA was bribed or was compelled to issue the b= ogus certificate. (A CA might be compelled to issue a bogus certificate by = a government agency or a criminal organization.) This CA might be one or m= ore tiers below a trust anchor (aka root CA). 2.2.4.1 A bogus certificate may not have been submitted to any logs. In thi= s case, Monitors will not detect the bogus certificate. If clients reject a= certificate that lacks (or is not accompanied by) an SCT, the attacker wil= l be thwarted in this case. (See Note 3 below.) 2.2.4.2 A bogus certificate may have been submitted to one or more logs pri= or to issuance, to acquire an embedded SCT, or post-issuance, to acquire a = standalone SCT. In either case, a Monitor protecting the targeted Subject w= ill detect a bogus certificate and alert the targeted subject. The Subject,= in turn, will request the CA to revoke the bogus certificate. In this case= , the CA may refuse, or substantially delay, to revoke the bogus certificat= e. (It could make excuses about inadequate proof that the certificate is bo= gus, or argue that it cannot quickly revoke the certificate because of loca= l, legal concerns, etc.) In this case, the CT mechanisms have detected mis-= issuance, but the information logged by CT does not help remedy the problem= . (See Note 4 below.) 2.2.5 A bogus certificate may have been submitted to one or more conspiring= logs. These logs will issue SCTs, but will hide the log entries from some = or all Monitors. Any Monitor from which the log is hiding data will not det= ect the bogus certificate, even if it is protecting the target Subject. If = a client accepts an SCT from a conspiring log, then the client will not rej= ect the bogus certificate on the basis of a missing SCT. In this case CT wi= ll not detect the semantically mis-issued certificate. Auditors are intende= d to detect logs that conspire to suppress log entries, based on XXX. [is t= he unspecified gossip protocol need here? If so, then until we have this pr= otocol, CT does not provide the necessary info to detect this form of mis-i= ssuance.] If Auditors detect conspiring logs, Monitors and clients can be = alerted to conspiring logs. This would cause clients to not accept SCTs gen= erated by these logs, in the future. (See Note 5 below.) Notes: 1. If a CA submits a bogus certificate to one or more logs, but these logs = are not watched by a Monitor that is protecting the targeted Subject, CT wi= ll not mitigate this type of mis-issuance attack. It is not clear whether e= very Monitor MUST offer to track every Subject that requests protection. Ab= sent such a guarantee, how do Subjects know which set of Monitors will prov= ide "sufficient" coverage. Of course, if a Subject acts as its own Monitor,= this problem is solved for that Subject. 2. A CA being presented with evidence of a bogus certificate probably will = require more than the serial number of the bogus certificate. It will want = to verify the Issuer and Subject (subjectAltname) to ensure that the certif= icate being revoked is not one that it has knowingly issued legitimately. T= hus a Subject should not expect immediate revocation of a contested certifi= cate in all cases. (The time frame in which a CA will respond to a revocati= on request usually is described in the CPS for the CA.) Other certificate f= ields and extensions may be of interest for forensic purposes, but are not = required to effect revocation nor to verify that the certificate to be revo= ked is bogus, based on [CABF-Baseline] criteria. The SCT itself, because it= contains a timestamp from a third party, is probably valuable for forensic= purposes. 3. If a TLS client is to reject a certificate that lacks an embedded SCT, o= r is not accompanied by an SCT transported via the TLS handshake, this beha= vior needs to be defined in a way that is compatible with incremental deplo= yment. Issuing a warning to a (human) user is probably insufficient, based = on experience with warnings displayed for expired certificates, lack of cer= tificate revocation status information, and similar errors that violate RFC= 5280 path validation rules. 4. A targeted Subject might request the parent or the offending CA to revok= e the certificate of the non-cooperative CA. However, a request of this sor= t may be rejected, e.g., because of the potential for significant collatera= l damage. A browser might be configured to reject all certificates issued b= y the malicious CA, e.g., using a CA hot list distributed by a browser vend= or. However, if the malicious CA has a sufficient number of legitimate clie= nts, treating all of them as bogus still represents serious collateral dama= ge. If one can configure a browser to reject the specific, bogus certificat= e identified by a Monitor, then the bogus certificate could be rejected in = that fashion. Moreover, this calls for communication between Monitors and b= rowsers, or between Monitors and browser vendors. Such communication is not= specified. There are no standard ways to configure a browser to reject ind= ividual bogus certificates. Moreover, a malicious CA could easily issue new= bogus certificates for the targeted Subject, which would have to be detect= ed and rejected in this (as yet unspecified) fashion. Thus, for now, CT doe= s not seem to provide a way to mitigate this form of attack, even though it= provides a basis for detecting such attacks. 5. The combination of a malicious CA and one or more conspiring logs motiva= tes the use of Auditors, to detect conspiring logs. If a Monitor protecting= s Subject does not see mis-issued certificates, it cannot alert the Subjec= t. If one or mlore SCTs are present in a certificate, or passed via the TLS= handshake, a client has no way to know that the logged certificate is not = visible to Monitors. Only if clients reject certificates that contains SCTs= from conspiring logs will CT be able to deter use of such logs. Thus the m= eans by which Auditors detect such logs, and inform TLS clients must be spe= cified. Moreover, if a certificate (or TLS handshake) contains more than on= e SCT, the client MUST verify all of them if it is to counter the threat po= sed by conspiring logs. Absent a "gossip" protocol that enables Auditors to verify that data from l= ogs are reported in a consistent fashion to many (all?) Monitors, CT does n= ot provide protection against logs that may conspire with, or be victims of= , attackers effecting certificate mis-issuance. When a gossip protocol is d= efined and deployed, it will be necessary to describe how the CT system wil= l deal with a mis-behaving or compromised log. For example, will there be a= mechanism to alert all TLS clients to reject SCTs issued by such a log. Ab= sent a description of a mitigation strategy to deal with mis-behaving or co= mpromised logs, CT cannot ensure detection of mis-issuance. Monitors play the critical role in detecting semantic certificate mis-issua= nce, for Subjects that have requested monitoring of their certificates. Thu= s Monitors represent another target for adversaries who wish to effect cert= ificate mis-issuance. If a Monitor is compromised by, or conspires with, an= attacker, it will fail to alert a Subject to a mis-issued certificate targ= eting that Subject. This suggests that a Subject SHOULD request certificate= monitoring from multiple sources to guard against such failures. Operation= of a Monitor by a Subject, on its own behalf, avoids dependence on third p= arty Monitors, but the burden of Monitor operation may be viewed as to grea= t for many web sites, and thus this mode of operation ought not be assumed = to be universal when evaluating protection against Monitor compromise. --_000_4262AC0DB9856847A2D00EF817E8113923603Bscygexch10cygnaco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

 

Thanks.

 

My primary concern with the analysis is that it does = not discuss the practicality  and resources and data required for the = monitoring activity.  It is quite possible that monitoring will not be done at all or will miss things or will be ine= ffective leaving the benefit of CT to largely as a deterrent as opposed to = detection mechanism.  Threat analysis may wish to point that out with = significant emphasis since 6962 does not seem to emphasize this enough.  I see CAs offering to perform mon= itoring service, which will not detect problems if the authorized CA or RA = are compromised or have gone rogue.  In summary, the last paragraph of= the analysis may wish to point out the monitors may require subjects to use secure means to provide a list of valid certif= icates from time to time and for monitor to check the logs for mis-issuance= against this list.  6962 does not address the critical aspect of moni= toring from the perspective of checking that the certificates are legitimate.

 

While just about everyone is against checking the cer= tification path and certificate, but if the goal is to secure Web PKI, to i= mprove user experience or at least protect less informed users from making bad choices when a browser barfs, I would = think checking certificate, certification path, and even cipher suites incl= uding proper range for RSA public exponent are good things.

 

On specifics of your analysis, on Note 2, I would thi= nk the CA may wish to get the whole certificate to verify that the certific= ate was issued by it by verifying the signature using its own public keys.

 

From: Trans [mailto:trans-bounces@= ietf.org] On Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2014 1:51 PM
To: trans@ietf.org
Subject: [Trans] updated definition and attack analysis text

 

Ignoring (for the moment) the suggestion to not cons= ider syntactic mis-issuance,
and the topic of whether logs might perform syntax checks on certs submitte= d to them,
I have revised the attack analysis text. It at least provides a sense of th= e style
and structure one wants in such text, and which is missing from 6962-bis.
I've expanded the definitions of mis-issuance based on the message exchange= s
Ben and I had, to more clearly describe the cases of syntactic and semantic=
mis-issuance that are outside of the scope for CT, or that may be detectabl= e only
if a Subject operates its own Monitor. I also added structure to group the = attack cases,
to make for easier reading. I' ve kept the "notes" style, but the= se could be folded into
the attack case analysis if desired. (It would just introduce some redundan= cy.)

Steve

------


1. Goals and Definitions

 

The goal of Certificate Transp= arency (CT) is to detect mis-issuance of certificates, in the Web PKI conte= xt. It is anticipated that CT will help deter mis-issuance, e.g., by providing information to an affected Subject = to facilitate revocation of a mis-issued certificate. The Web PKI context r= efers to the use of a set of Certification Authorities (CAs) that issue X.5= 09 certificates to web servers to enable TLS-protected access by clients [cite WPKOPS?].

 

A certificate is characterized= as mis-issued if the certificate does not conform to the requirements esta= blished by CA Browser Forum (CABF) documents for “domain validation” (DV) or “extended validationR= 21; (EV) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issu= ance takes two primary forms syntactic mis-issuance and semantic mis-issuan= ce.

 

1. A certificate may fail to meet the synt= actic constraints imposed by the CABF guidelines.

a. Most syntactic constraints from [CABF-B= aseline] and [CABF-EV], can be checked via examination of a certificate cha= in, without reference to Subject-specific or CA-specific data.<= /o:p>

b. A few syntactic constraints require acc= ess to data specific to a CA or the Subject in question.

 

2. A certificate may fail to meet the sema= ntic constraints imposed by the CABF guidelines.

a. Most semantic constraints can be verifi= ed by comparing a certificate against one or more reference certificates fo= r the Subject.

b. Some semantic constraints cannot be ver= ified by examining a certificate, even with reference certificate informati= on.

Most instances of the syntacti= c of mis-issuance can be detected by examining a certificate against a set = of criteria extracted from the CABF guidelines. Based on whether a certificate purports to be a DV or an EV certificate, o= ne can examine it against almost all of the syntactic constraints imposed b= y the guidelines. Appendix A, Section A.1 enumerates the syntactic criteria= to be used in this case. These checks can be performed by a log before issuing an SCT, and if a (pre-) ce= rtificate fails these checks, it should not be issued. This behavior is REC= OMMENDED to provide feedback to CAs, to detect potential syntactic mis-issu= ance before the certificate is issued.

 

A few of the syntactic constra= ints cannot be verified in this fashion, e.g., because they require knowled= ge of the organizational relationships between “root” and subordinate CAs (see Section 9.3.3 of [CABF= -Baseline].)  Appendix A, Section A.2, notes these exception and notes= that, in general, they cannot be checked by a Monitor or log, and thus the= re is no requirement to perform these checks. (A Monitor operated by a Subject on its own behalf has access to at least som= e of the data required to verify conformance to this latter set of syntacti= c constraints and thus SHOULD do so.)

 

Detection of semantic mis-issu= ance as described in 2a above requires access to “reference” ce= rtificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificat= e issued to a specified Subject, consistent with the CABF guidelines.) The = primary concern addressed by detection of semantic mis-issuance is that a c= ertificate has been issued to an entity that is not authorized to represent the host (web server) named in = the certificate Subject field (or subjectAltName extension).

 

Other forms of semantic mis-is= suance (2 b above) may arise due to procedural or operational violations of= the CABF guidelines, but these may not be detectable by a third party, even with access to a reference certificat= e. For example, a Web PKI CA may fail to adhere to the audit procedures req= uired in Section 15 of [CABF-Baseline]. CT elements (e.g., Monitors) are no= t able to detect these forms of mis-issuance because they are not externally visible.

 

<Discuss classes of adversa= ries, motivations, and capabilities>

 

1. Criminals

 

2. Hacktivists

 

3. Nation states (intelligence orga= nizations)

 

4. Other?

 

 

 

2. Attack Model and Mitigation= Mechanisms

 

Certificate mis-issuance may a= rise in one of several ways. The ways that CT enables a Subject (or others)= to redress mis-issuance depends on the context of the mis-issuance, and thus it is appropriate to examine the con= text as part of an attack model

 

2.1 A non-malicious Web PKI CA

 

If the certificate is submitte= d to a log prior to issuance (a pre-certificate), the (generally) detectabl= e forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. Because = the CA is non-malicious, it will remedy the syntactic problem and re-submit= the (pre-) certificate to a log again. Thus syntactic mis-issuance of this= type will be thwarted.

 

2.1.1 A CA may issue the certi= ficate to an unauthorized party (Section 1, 2.a), as a result of an error o= r because it was the victim of a social engineering attack. In this case the CA has a record of the certificate an= d it is prepared to revoke the bogus certificate once it has been convinced= of its error. If the CA is submitting (pre-) certificates for logging, the= re will be evidence of the mis-issuance in one or more logs. If a Monitor is “protecting” the targeted= Subject, it will detect the mis-issuance, and will alert the Subject. Beca= use the CA has a record of the mis-issuance, it should revoke the bogus cer= tificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence o= f an embedded SCT in the bogus certificate, or an SCT accompanying the bogu= s certificate does not contribute to the mitigation. (See Note 1 below.)

 

2.1.2 A non-malicious Web PKI = CA may be the victim of an undetected attack (c.f., DigiNotar) which result= s in semantic mis-issuance of one or more certificates. In this case the CA is not aware of the mis-issuance and may= have no record of the certificate content.

 

2.1.2.1 The mis-issued certifi= cate may have been submitted to one or more logs prior to issuance, to acqu= ire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting = the targeted Subject will detect the bogus certificate and alert the target= ed Subject. The Subject, in turn, will request the CA to revoke the bogus c= ertificate. In this case, the CA will depend on the certificate serial number provided via the log entry, t= o effect revocation. (See Notes 1 + 2 below.) If TLS clients reject a c= ertificate when no SCT is present, this might motivate the attacker to log = the bogus certificates, which helps justify such client behavior.

 

2.1.2.2 The bogus certificate = may not have been submitted to any logs. In this case, Monitors will not de= tect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the att= acker will be thwarted in this case. (See Note 3 below.)<= /p>

 

2.2 A Malicious Web PKI CA

 

2.2.1 If a certificate is subm= itted to a log prior to issuance (a pre-certificate), the (generally) detec= table forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged.= However, because the CA is presumed to be malicious, the certificate may b= e issued anyway. Thus checking for syntactic mis-issuance in this case does= not, per se, prevent such mis-issuance. However, if clients reject a certificate that lacks (or is not accompanied= by) an SCT, this form of mis-issuance will be thwarted in this case.

 

2.2.2 Because this CA is malic= ious, it may choose to not submit the certificate to a log. This avoids det= ection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. However, if cl= ients reject a certificate that lacks (or is not accompanied by) an SCT, th= is form of mis-issuance will be thwarted in this case.

 

2.2.3 The CA may submit the bo= gus certificate to one or more logs that collude with this CA, and thus do = not perform syntactic checks. In this case the syntactic mis-issuance will not be detected by logs. Unless Monit= ors (or Auditors?) also perform syntactic checks, this form of mis-issuance= will not be thwarted in this case.

 

2.2.4 The malicious CA may sem= antically mis-issue a certificate, that is syntactically valid. We will ref= er to such a certificate as “bogus”. Because it is syntactically valid, logs will not reject the certificate. This situ= ation might result because the CA was bribed or was compelled to issue the = bogus certificate. (A CA might be compelled to issue a bogus certificate by= a government agency or a criminal organization.)  This CA might be one or more tiers below a trust anch= or (aka root CA).

 

2.2.4.1 A bogus certificate ma= y not have been submitted to any logs. In this case, Monitors will not dete= ct the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker w= ill be thwarted in this case. (See Note 3 below.)

 

2.2.4.2 A bogus certificate ma= y have been submitted to one or more logs prior to issuance, to acquire an = embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor protecting the targeted Subjec= t will detect a bogus certificate and alert the targeted subject. The Subje= ct, in turn, will request the CA to revoke the bogus certificate. In this c= ase, the CA may refuse, or substantially delay, to revoke the bogus certificate. (It could make excuses about inade= quate proof that the certificate is bogus, or argue that it cannot quickly = revoke the certificate because of local, legal concerns, etc.) In this case= , the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the pr= oblem. (See Note 4 below.)

 

2.2.5 A bogus certificate may = have been submitted to one or more conspiring logs. These logs will issue S= CTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will n= ot detect the bogus certificate, even if it is protecting the target Subjec= t. If a client accepts an SCT from a conspiring log, then the client will n= ot reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semanti= cally mis-issued certificate. Auditors are intended to detect logs that con= spire to suppress log entries, based on XXX. [is the unspecified gossip pro= tocol need here? If so, then until we have this protocol, CT does not provide the necessary info to detect th= is form of mis-issuance.]  If Auditors detect conspiring logs, Monitor= s and clients can be alerted to conspiring logs. This would cause clients t= o not accept SCTs generated by these logs, in the future. (See Note 5 below.)

 

Notes:

 

1. If a CA submits a bogus certific= ate to one or more logs, but these logs are not watched by a Monitor that i= s protecting the targeted Subject, CT will not mitigate this type of mis-is= suance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. = Absent such a guarantee, how do Subjects know which set of Monitors will pr= ovide “sufficient” coverage. Of course, if a Subject acts as it= s own Monitor, this problem is solved for that Subject.

 

2. A CA being presented with eviden= ce of a bogus certificate probably will require more than the serial number= of the bogus certificate. It will want to verify the Issuer and Subject (s= ubjectAltname) to ensure that the certificate being revoked is not one that it has knowingly issued legitima= tely. Thus a Subject should not expect immediate revocation of a contested = certificate in all cases. (The time frame in which a CA will respond to a r= evocation request usually is described in the CPS for the CA.) Other certificate fields and extensions may be of = interest for forensic purposes, but are not required to effect revocation n= or to verify that the certificate to be revoked is bogus, based on [CABF-Ba= seline] criteria. The SCT itself, because it contains a timestamp from a third party, is probably valuable f= or forensic purposes.

 

3. If a TLS client is to reject a c= ertificate that lacks an embedded SCT, or is not accompanied by an SCT tran= sported via the TLS handshake, this behavior needs to be defined in a way t= hat is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, = based on experience with warnings displayed for expired certificates, lack = of certificate revocation status information, and similar errors that viola= te RFC 5280 path validation rules.

 

4. A targeted Subject might request= the parent or the offending CA to revoke the certificate of the non-cooper= ative CA. However, a request of this sort may be rejected, e.g., because of= the potential for significant collateral damage. A browser might be configured to reject all certificates issued by= the malicious CA, e.g., using a CA hot list distributed by a browser vendo= r. However, if the malicious CA has a sufficient number of legitimate clien= ts, treating all of them as bogus still represents serious collateral damage. If one can configure a browser= to reject the specific, bogus certificate identified by a Monitor, then th= e bogus certificate could be rejected in that fashion. Moreover, this calls= for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication = is not specified. There are no standard ways to configure a browser to reje= ct individual bogus certificates. Moreover, a malicious CA could easily iss= ue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as= yet unspecified) fashion. Thus, for now, CT does not seem to provide a way= to mitigate this form of attack, even though it provides a basis for detec= ting such attacks.

 

5. The combination of a malicious C= A and one or more conspiring logs motivates the use of Auditors, to detect = conspiring logs. If a Monitor protecting s Subject does not see mis-issued = certificates, it cannot alert the Subject. If one or mlore SCTs are present in a certificate, or passed via = the TLS handshake, a client has no way to know that the logged certificate = is not visible to Monitors. Only if clients reject certificates that contai= ns SCTs from conspiring logs will CT be able to deter use of such logs. Thus the means by which Auditors det= ect such logs, and inform TLS clients must be specified. Moreover, if a cer= tificate (or TLS handshake) contains more than one SCT, the client MUST ver= ify all of them if it is to counter the threat posed by conspiring logs.

 

 

Absent a “gossip” = protocol that enables Auditors to verify that data from logs are reported i= n a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be vic= tims of, attackers effecting certificate mis-issuance. When a gossip protoc= ol is defined and deployed, it will be necessary to describe how the CT sys= tem will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TL= S clients to reject SCTs issued by such a log. Absent a description of a mi= tigation strategy to deal with mis-behaving or compromised logs, CT cannot = ensure detection of mis-issuance.

 

Monitors play the critical rol= e in detecting semantic certificate mis-issuance, for Subjects that have re= quested monitoring of their certificates. Thus Monitors represent another target for adversaries who wish to effect = certificate mis-issuance. If a Monitor is compromised by, or conspires with= , an attacker, it will fail to alert a Subject to a mis-issued certificate = targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources= to guard against such failures. Operation of a Monitor by a Subject, on it= s own behalf, avoids dependence on third party Monitors, but the burden of = Monitor operation may be viewed as to great for many web sites, and thus this mode of operation ought not = be assumed to be universal when evaluating protection against Monitor compr= omise.

 

--_000_4262AC0DB9856847A2D00EF817E8113923603Bscygexch10cygnaco_-- From nobody Thu Oct 2 14:02:36 2014 Return-Path: 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 6A86A1A87A6 for ; Thu, 2 Oct 2014 14:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ZdnJfQVYZEDZ for ; Thu, 2 Oct 2014 14:02:31 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85CB1ACD5F for ; Thu, 2 Oct 2014 14:02:30 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so3008516lbj.31 for ; Thu, 02 Oct 2014 14:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9XHuXErWod12X82gsViBO0xSelrcLfVqjjpNREVp7M0=; b=gPZhw9B7gjN6Jo/bnBeJXZt/809YGorASUflGIyF9A2bO1ZoTJCt8QnS/rcpz8QeOg OGGYgPBbJAd0ZJ4kt1i98uqyA+f7gKn9ze9r9NP1o5CZUYwDY44YGqZnmGWSfv1P4JRv wDHm3bcWvPC7omtTnZaKEvZD3aL8YLqDt5jmhv4IaTihsWMWEDelnVgyHUodhPCFWM8i rY09UBRFxtOgq69Pou6ZOtBBsktBE55PNfpkNJFC/Hiq291n8kr/DXfzu+jzIxdGcOnb /ov7g7EP3IOrdcnqAXdAJUykNk2T94Theg3m3/25I6q3Zhe8+WrJvXPmwrPRW8RzSzQ7 sz1Q== X-Received: by 10.112.151.99 with SMTP id up3mr1166857lbb.45.1412283749154; Thu, 02 Oct 2014 14:02:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Thu, 2 Oct 2014 14:02:09 -0700 (PDT) In-Reply-To: <542D79BB.1030900@bbn.com> References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C0FCB.7010906@bbn.com> <542D79BB.1030900@bbn.com> From: David Leon Gil Date: Thu, 2 Oct 2014 17:02:09 -0400 Message-ID: To: Stephen Kent , stephen.farrell@cs.tcd.ie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ZPzY2QXA2_Zgj-U_fEpn_FJ2r14 Cc: "trans@ietf.org" Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:02:34 -0000 On Thu, Oct 2, 2014 at 12:13 PM, Stephen Kent wrote: >> On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent wrote: >> You are missing the point of certificate transparency. > > I may, since the definition of the goals seem to change over time. That, in a nutshell, is exactly the point of certificate transparency. CT should provide a log service in a way that is neutral with respect to whatever requirements CABF or browser vendors may in future impose. This is good for good CAs: It means that they will have the flexibility to provide new services / cert types as soon as clients will accept them. They won't have to, in addition, go through this WG.[*] [*] Requiring CAs/browser vendors to get this WG's blessing seems to be the motivation of many of the proposals. > I was suggesting that there might be benefits to checking at the time > of issuance, principally in the case of pre-certs. These proposals amount to this: Let's spare a CA who lets their private key be used to sign something it shouldn't have signed any reputational damage by requiring logs to not report it. This is exactly the wrong incentive. CAs -- both root and intermediate -- need to have security controls that ensure that they don't sign malicious things. > What CT does should or should not be ought to be justified based on an > analysis of attacks and what CT does to address them, not on blanket > statements that mis-issuance cannot be defined. [and other Stephen]: > That's . . . better that a mere assertion that "logging is good." The IETF has previously standardized logging protocols. See, inter alia, RFC 5424. Is consensus lacking for the idea that logging is good? From nobody Fri Oct 3 03:48:33 2014 Return-Path: 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 2B11C1AD035 for ; Fri, 3 Oct 2014 03:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 5_yY22gQyBNt for ; Fri, 3 Oct 2014 03:48:31 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6241A028B for ; Fri, 3 Oct 2014 03:48:30 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id z10so2372236pdj.40 for ; Fri, 03 Oct 2014 03:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mEXn46zlYyxtma+eTHEUjUNXubkZdOMWla47fLpP6Rg=; b=AKQTbbi3y2taWB/AKOemKEUWXbWGBz4/bXSDgNKvlUApZrz3CAFQz4yBB4SNJg3MPj SrdOCGsju66n+zv2HiRX20tZcxvLBF8sgtOPmlj05wrSMy2f+zNZhGVKw9jekQBWSq3y DjlJ/RItfVm20WXi22xgnbkN79GmwyiVHppY19xlnQUVqLJOmv9jEpBErPDO5S3BchGZ SYZt3PaHr0/LvoJ1e4Qc5zvtW7lv3ms2dF6jZypXBpFLqHOZBz0ne3OnHYuF+eNLqXwT 9qmJ5c9qzQxtEigaSv1I1nGOg/T2ooh49NANmcKGmKFF1VmlM12/2NiH2NGtwvjKy+l/ xCWQ== X-Received: by 10.70.35.232 with SMTP id l8mr31826pdj.48.1412333310592; Fri, 03 Oct 2014 03:48:30 -0700 (PDT) Received: from spandex.local (216-67-62-156-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.156]) by mx.google.com with ESMTPSA id ee5sm6148914pbc.76.2014.10.03.03.48.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 03:48:29 -0700 (PDT) Message-ID: <542E7EFC.4050202@gmail.com> Date: Fri, 03 Oct 2014 02:48:28 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/tQ_kb0Dch93HRv-NNfsG9YGpefI Subject: [Trans] making progress on precertificate discussion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 10:48:32 -0000 Hi, all: Problems around precertificate contents and formats were among the things we first discussed when the working group was chartered, and here we are, still at it. There are basically two problems that fall under the "precertificate" rubric: 1) whether or not it's possible/reasonable to include a certificate's serial number (as this implies that the issuer will know in advance what the serial number will be), and 2) encoding/representation. There's a general sense that the first *seems* like it ought to be a problem, but we haven't had CAs stepping forward saying that this would prevent them from being able to implement and would be unacceptably onerous for them. Instead, we're hearing reports of at least one major CA solving the problem by simultaneously issuing precertificates and certs. Given the lack of new information and lack of new technical arguments, I think we need to close the serial number aspect of the discussion and go ahead with continuing to include it in precertificates. This is the IETF and nearly any decision can be revisited with the introduction of new information or a new, compelling argument. But in the meantime we need to move forward, so let's close this one and move on to trying to close the encoding discussion. Many thanks for the careful thought that's gone into the deliberations so far, Melinda From nobody Fri Oct 3 07:39:19 2014 Return-Path: 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 23CD31A0346 for ; Fri, 3 Oct 2014 07:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 CLYHeqkuE0Jr for ; Fri, 3 Oct 2014 07:19:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04BA1A0343 for ; Fri, 3 Oct 2014 07:19:58 -0700 (PDT) Received: from localhost ([::1]:47129 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xa3iA-0001Oh-Ju; Fri, 03 Oct 2014 07:19:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: trans Date: Fri, 03 Oct 2014 14:19:58 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/51#comment:2 Message-ID: <075.f3ad8b482ac40a41f1745845c62ebad0@tools.ietf.org> References: <060.96fc54ab9519113521627bd36c015087@tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <060.96fc54ab9519113521627bd36c015087@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/SRzhvVDYA3W6xIE57zCTljxcfvQ X-Mailman-Approved-At: Fri, 03 Oct 2014 07:39:17 -0700 Cc: trans@ietf.org Subject: Re: [Trans] [trans] #51 (rfc6962-bis): Test, please disregard X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 14:20:00 -0000 #51: Test, please disregard Comment (by henrik@levkowetz.com): Test after SIGHUP'ing postconfirmd -- ----------------------------------+--------------------- Reporter: henrik@levkowetz.com | Owner: henrik Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------- Ticket URL: trans From nobody Fri Oct 3 07:39:21 2014 Return-Path: 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 261BC1A0024 for ; Fri, 3 Oct 2014 07:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 rLoh4ZPBkajZ for ; Fri, 3 Oct 2014 07:29:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8E51A0016 for ; Fri, 3 Oct 2014 07:29:15 -0700 (PDT) Received: from localhost ([::1]:47671 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xa3r9-0006vW-Ck; Fri, 03 Oct 2014 07:29:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: trans Date: Fri, 03 Oct 2014 14:29:15 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/51#comment:3 Message-ID: <075.fa95a6a26ede4aa672f33c288430b98a@tools.ietf.org> References: <060.96fc54ab9519113521627bd36c015087@tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <060.96fc54ab9519113521627bd36c015087@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-USJQCGDp8lcNX6oRf1HAyVRV_4 X-Mailman-Approved-At: Fri, 03 Oct 2014 07:39:18 -0700 Cc: trans@ietf.org Subject: Re: [Trans] [trans] #51 (rfc6962-bis): Test, please disregard X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 14:29:18 -0000 #51: Test, please disregard Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => fixed -- ----------------------------------+--------------------- Reporter: henrik@levkowetz.com | Owner: henrik Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------- Ticket URL: trans From nobody Fri Oct 3 08:10:41 2014 Return-Path: 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 ; 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 ; 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 ; Fri, 3 Oct 2014 08:10:33 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so1119030qcz.23 for ; 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: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-hy_VwD-lGltVtpPwGepwxEUDOA Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:10:38 -0000 On 2 October 2014 17:13, Stephen Kent wrote: > Rob, >> >> On 01/10/14 16:05, Stephen Kent wrote: >> >>> >>> Rick, >> >> >>> >>> 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 > 3. the cert conforms to EV guidelines > > - 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 From nobody Fri Oct 3 12:25:17 2014 Return-Path: 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 41F461A88D3 for ; Fri, 3 Oct 2014 12:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FEfjV50OEhyj for ; Fri, 3 Oct 2014 12:25:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95001A88A4 for ; Fri, 3 Oct 2014 12:25:05 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51274 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xa8Tf-0000qg-7g for trans@ietf.org; Fri, 03 Oct 2014 15:25:19 -0400 Message-ID: <542EF80D.8040802@bbn.com> Date: Fri, 03 Oct 2014 15:25:01 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/yD_uvqZ4rJ7EZ0vcNOgYyo9lULo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:25:16 -0000 Ben, > ... > 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 > 3. the cert conforms to EV guidelines > > - 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!). I'm confused by your comment. There is no "rejection" of a cert in the text above. That was the change I made to address the valid concerns that Rob and Rick raised. If the cert failed checking it would still be logged, and an SCT issued, but the fact that the syntax failed the checks would be noted in the SCT and the log entry. Steve p.s. I realize that one more log-assigned value is needed, i.e., the CA asserted #1, so the log didn't perform any check in this case From nobody Fri Oct 3 12:26:58 2014 Return-Path: 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 4E1D51A6FB3 for ; Fri, 3 Oct 2014 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hAS0GKlV2BEq for ; Fri, 3 Oct 2014 12:26:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8081A0034 for ; Fri, 3 Oct 2014 12:26:54 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51275 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xa8VQ-0000ra-NO for trans@ietf.org; Fri, 03 Oct 2014 15:27:08 -0400 Message-ID: <542EF87B.5010105@bbn.com> Date: Fri, 03 Oct 2014 15:26:51 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <542E7EFC.4050202@gmail.com> In-Reply-To: <542E7EFC.4050202@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YezdkidnYh1DbrVau-ioYDUG5WI Subject: Re: [Trans] making progress on precertificate discussion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:26:56 -0000 Melinda, > Hi, all: > > Problems around precertificate contents and formats were among > the things we first discussed when the working group was chartered, > and here we are, still at it. There are basically two problems > that fall under the "precertificate" rubric: 1) whether or not > it's possible/reasonable to include a certificate's serial number > (as this implies that the issuer will know in advance what the > serial number will be), and 2) encoding/representation. There's > a general sense that the first *seems* like it ought to be a > problem, but we haven't had CAs stepping forward saying that > this would prevent them from being able to implement and > would be unacceptably onerous for them. Instead, we're hearing > reports of at least one major CA solving the problem by > simultaneously issuing precertificates and certs. I'm confused by the last sentence above. One can issue a cert at the same time a pre-cert is issued, but the cert does not contain the SCT that will be generated by the log, so the parallel issuance seems redundant, and I'm not sure how it helps. > Given the lack of new information and lack of new technical > arguments, I think we need to close the serial number aspect of > the discussion and go ahead with continuing to include it in > precertificates. This is the IETF and nearly any decision can > be revisited with the introduction of new information or a new, > compelling argument. But in the meantime we need to move forward, > so let's close this one and move on to trying to close the encoding > discussion. I'd feel more comfortable on this topic if we had the results of the CABF member poll I suggested. Is there any progress on that front? Steve From nobody Fri Oct 3 12:29:20 2014 Return-Path: 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 4A69D1A1AD5 for ; Fri, 3 Oct 2014 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 Sz0b_czgHZHR for ; Fri, 3 Oct 2014 12:29:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66ED01A1A15 for ; Fri, 3 Oct 2014 12:29:17 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:54097 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xa8XU-000L7r-EX for trans@ietf.org; Fri, 03 Oct 2014 15:29:16 -0400 Message-ID: <542EF909.1030605@bbn.com> Date: Fri, 03 Oct 2014 15:29:13 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: "trans@ietf.org" References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C0FCB.7010906@bbn.com> <542D79BB.1030900@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ajjioJnsHmUohwMMVRxJ4a8JZz8 Subject: Re: [Trans] path validation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:29:19 -0000 David, > On Thu, Oct 2, 2014 at 12:13 PM, Stephen Kent wrote: >>> On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent wrote: >>> You are missing the point of certificate transparency. >> I may, since the definition of the goals seem to change over time. > That, in a nutshell, is exactly the point of certificate transparency. An inability to clearly characterize goals is a bug, not a feature :-) when developing a standard. I cannot recall any major security area WGs that have ignored this issue in the past few years. > CT should provide a log service in a way that is neutral with respect > to whatever requirements CABF or browser vendors may in future impose. > > This is good for good CAs: It means that they will have the > flexibility to provide new services / cert types as soon as clients > will accept them. They won't have to, in addition, go through this > WG.[*] My revised proposal from yesterday allows a CA to assert that the cert being submitted does not purport to conform to the CABF DV/EV guidelines, so it seems to address this concern. > [*] Requiring CAs/browser vendors to get this WG's blessing seems to > be the motivation of many of the proposals. Can you be more specific? >> I was suggesting that there might be benefits to checking at the time >> of issuance, principally in the case of pre-certs. > These proposals amount to this: > > Let's spare a CA who lets their private key be used to sign something > it shouldn't have signed any reputational damage by requiring logs to > not report it. This is exactly the wrong incentive. CAs -- both root > and intermediate -- need to have security controls that ensure that > they don't sign malicious things. I agree with the sentiment that CAs should be held responsible. I have no idea why you believe that I suggested otherwise. Please cite any messages I have generated that support the first sentence above. >> What CT does should or should not be ought to be justified based on an >> analysis of attacks and what CT does to address them, not on blanket >> statements that mis-issuance cannot be defined. > [and other Stephen]: > That's . . . better that a mere assertion that > "logging is good." > > The IETF has previously standardized logging protocols. See, inter > alia, RFC 5424. Is consensus lacking for the idea that logging is > good? 5424 didn't invent syslog. It provided a common format for communicating syslog entries and a standard means for transport. It did not require any system to make use of the protocol, to export syslog entries to arbitrary third parties, etc. Thus, syslog is not a reasonable analogy to CT. Steve From nobody Fri Oct 3 12:30:57 2014 Return-Path: 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 94F371A1A75 for ; Fri, 3 Oct 2014 12:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 DNXVdBPS8iJM for ; Fri, 3 Oct 2014 12:30:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4591A1A15 for ; Fri, 3 Oct 2014 12:30:53 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60677 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xa8ZH-0000tU-B8 for trans@ietf.org; Fri, 03 Oct 2014 15:31:07 -0400 Message-ID: <542EF969.1020507@bbn.com> Date: Fri, 03 Oct 2014 15:30:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <542C3EFA.7010204@bbn.com> <4262AC0DB9856847A2D00EF817E8113923603B@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E8113923603B@scygexch10.cygnacom.com> Content-Type: multipart/alternative; boundary="------------070607030509030206080702" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Dk6yZCSVnWOgSV5Qjkg8JwKcyVk Subject: Re: [Trans] updated definition and attack analysis text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:30:55 -0000 This is a multi-part message in MIME format. --------------070607030509030206080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh, > > Steve, > > Thanks. > > My primary concern with the analysis is that it does not discuss the > practicality and resources and data required for the monitoring > activity. It is quite possible that monitoring will not be done at > all or will miss things or will be ineffective leaving the benefit of > CT to largely as a deterrent as opposed to detection mechanism. > Threat analysis may wish to point that out with significant emphasis > since 6962 does not seem to emphasize this enough. I see CAs offering > to perform monitoring service, which will not detect problems if the > authorized CA or RA are compromised or have gone rogue. In summary, > the last paragraph of the analysis may wish to point out the monitors > may require subjects to use secure means to provide a list of valid > certificates from time to time and for monitor to check the logs for > mis-issuance against this list. 6962 does not address the critical > aspect of monitoring from the perspective of checking that the > certificates are legitimate. > I'm happy to specific receive text to add to the analysis. I'll be updating it next week to reflect the revised syntax checking anyway. Also, I have completed an initial cut at the EV cert syntax rules and pkan to issue a complete Appendix A version next week as well. I agree that a CA that operates a log for itself, or a Monitor for its clients seems questionable. When I think about Monitor services I look at what is available today for address space monitoring. Companies monitor BGP advertisements, from open and proprietary sources, looking for advertisements of prefixes that belong to client. If an advertised prefix does not have the origin AS of the client, it's suspicious. The client is informed and can take action, e.g., contacting the AS that is advertising itself as the origin of the client's prefix. This works reasonable well, but it is a for profit activity, i.e., people pay to have their prefixes monitored. If the designers of CT envision this as a likely deployment scenario for CT, it ought to be mentioned. > > While just about everyone is against checking the certification path > and certificate, but if the goal is to secure Web PKI, to improve user > experience or at least protect less informed users from making bad > choices when a browser barfs, I would think checking certificate, > certification path, and even cipher suites including proper range for > RSA public exponent are good things. > I agree. Since I revised my proposal, so that even certs that fail syntactic validation are logged, maybe we can revisit the path validation issue. One could imagine adding an error code to an SCT that noted when the syntax is OK, but path validation fails, and why. > > On specifics of your analysis, on Note 2, I would think the CA may > wish to get the whole certificate to verify that the certificate was > issued by it by verifying the signature using its own public keys. > Good point. The log entry contains the cert, so it makes sense to provide that to the CA what requesting that the cert be revoked. I'll make that change. Steve --------------070607030509030206080702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Santosh,

Steve,

 

Thanks.

 

My primary concern with the analysis is that it does not discuss the practicality  and resources and data required for the monitoring activity.  It is quite possible that monitoring will not be done at all or will miss things or will be ineffective leaving the benefit of CT to largely as a deterrent as opposed to detection mechanism.  Threat analysis may wish to point that out with significant emphasis since 6962 does not seem to emphasize this enough.  I see CAs offering to perform monitoring service, which will not detect problems if the authorized CA or RA are compromised or have gone rogue.  In summary, the last paragraph of the analysis may wish to point out the monitors may require subjects to use secure means to provide a list of valid certificates from time to time and for monitor to check the logs for mis-issuance against this list.  6962 does not address the critical aspect of monitoring from the perspective of checking that the certificates are legitimate.

I'm happy to specific receive text to add to the analysis. I'll be updating it next week
to reflect the revised syntax checking anyway.  Also, I have completed an initial cut at
the EV cert syntax rules and pkan to issue a complete Appendix A version next week as well.

I agree that a CA that operates a log for itself, or a Monitor for its clients seems
questionable. When I think about Monitor services I look at what is available today for
address space monitoring. Companies monitor BGP advertisements, from open and proprietary
sources, looking for advertisements of prefixes that belong to client. If an advertised prefix
does not have the origin AS of the client, it's suspicious. The client is informed and can take
action, e.g., contacting the AS that is advertising itself as the origin of the client's prefix.
This works reasonable well, but it is a for profit activity, i.e., people pay to have their
prefixes monitored. If the designers of CT envision this as a likely deployment scenario for
CT, it ought to be mentioned.

 While just about everyone is against checking the certification path and certificate, but if the goal is to secure Web PKI, to improve user experience or at least protect less informed users from making bad choices when a browser barfs, I would think checking certificate, certification path, and even cipher suites including proper range for RSA public exponent are good things.

I agree. Since I revised my proposal, so that even certs that fail syntactic validation are
logged, maybe we can revisit the path validation issue. One could imagine adding an error
code to an SCT that noted when the syntax is OK, but path validation fails, and why.

 On specifics of your analysis, on Note 2, I would think the CA may wish to get the whole certificate to verify that the certificate was issued by it by verifying the signature using its own public keys.

Good point. The log entry contains the cert, so it makes sense to provide that to the CA
what requesting that the cert be revoked.  I'll make that change.

Steve
--------------070607030509030206080702-- From nobody Fri Oct 3 12:58:33 2014 Return-Path: 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 769741A88EA for ; Fri, 3 Oct 2014 12:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Arnlbw_w9znR for ; Fri, 3 Oct 2014 12:58:31 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2BB1A88E9 for ; Fri, 3 Oct 2014 12:58:31 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y10so114456pdj.41 for ; Fri, 03 Oct 2014 12:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=I+GqQIf2CCArN5rXBRIGamVWsv8+awLvAJh9yi1ZSeM=; b=xrHQImS7rpwxCjlHVu60MqeOOV+iiAa+SVPkTWWNCWCePYO/3t46eaA/TZHhhU3368 kwpyGdza0p40VzX1AD0GHYkX1iU3oZNxT0lwqR2wxHj23C43wQgXIVpQMX5ryqX0S/vN DAGm0aM6hizjvLrUcc5pajudPmd//w5VbB5TgFh7BmhvarKlYI1laccCngItS4NEnA0b TrfFr1HS+cD+uM/MRrMJSKxE+hRaoz8zU+t69MDKMLBczrWpOPCdj90GSEw0Rljjezxz NwfRn5XHc4XMtF5G6FB2b4BlePYzJ5tUYCmo36g0jUEKuo9aL9x1jTM2jFhsgFaSFqv0 RGKA== X-Received: by 10.68.57.232 with SMTP id l8mr8959972pbq.107.1412366310838; Fri, 03 Oct 2014 12:58:30 -0700 (PDT) Received: from spandex.local (216-67-62-156-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.156]) by mx.google.com with ESMTPSA id b2sm5140886pbu.42.2014.10.03.12.58.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 12:58:30 -0700 (PDT) Message-ID: <542EFFE4.90908@gmail.com> Date: Fri, 03 Oct 2014 11:58:28 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: trans@ietf.org References: <542E7EFC.4050202@gmail.com> <542EF87B.5010105@bbn.com> In-Reply-To: <542EF87B.5010105@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FZPGeKblZxgX1Dq3t9SJElW6CV0 Subject: Re: [Trans] making progress on precertificate discussion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:58:32 -0000 On 10/3/14 11:26 AM, Stephen Kent wrote: > I'm confused by the last sentence above. One can issue a cert at the > same time a pre-cert is issued, but the cert does not contain the > SCT that will be generated by the log, so the parallel issuance seems > redundant, > and I'm not sure how it helps. This goes to the question of whether or not the serial number is knowable at the time at the precertificate is constructed. I don't know much beyond that; this is based on implementation reports from an American CA. > I'd feel more comfortable on this topic if we had the results > of the CABF member poll I suggested. Is there any progress on > that front? It's underway, and so far nobody is saying that the serial number issue is a block to implementation. I'm very concerned that we have not been able to close this issue for over six months, and that while several people have raised concerns on principle nobody who's actually implementing this on the CA side has said that this is a show-stopper, or even enough of a difficulty to raise it with us. We're very open to revisiting this if there's new information. Melinda From nobody Fri Oct 3 13:14:22 2014 Return-Path: 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 1EA501A1B1F for ; Fri, 3 Oct 2014 13:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, 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 Znr6p8pvTMqy for ; Fri, 3 Oct 2014 13:14:18 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1DF1A0365 for ; Fri, 3 Oct 2014 13:14:18 -0700 (PDT) Message-ID: <542F038E.9020305@digicert.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1412367257; bh=8MHFlSKMG9V+KDsmvXVc8t3LlyXEzD8XE/uPpTEl9B0=; h=Date:From:To:Subject:References:In-Reply-To; b=lwM6MzK0wAW0n2J2d4CbLVO6JEB7BVHJ+fhjtbrLx8zQvPCOABrv1yiqsFSpHI6CS 8TA+EG1J4ZK4f/Jog3uDyaMYv2AKnrsSFgth7DezisEFpDlt4xpRiF4DWrsaUceCrj ah3TlXbdlW3gCZebLCaR6Il10e5PK1uabWBplXW0= Date: Fri, 3 Oct 2014 14:14:06 -0600 From: Jeremy.Rowley User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: References: <542E7EFC.4050202@gmail.com> <542EF87B.5010105@bbn.com> <542EFFE4.90908@gmail.com> In-Reply-To: <542EFFE4.90908@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [67.137.52.8] X-ClientProxiedBy: EX2.corp.digicert.com (10.12.0.6) To EX2.corp.digicert.com (10.12.0.6) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rfnnVGX7CsF2pFIFvmf1F_X3wao Subject: Re: [Trans] making progress on precertificate discussion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:14:20 -0000 For us, it's actually more difficult to generate per-certificates without a serial number or with a different serial number. I'd prefer to keep it as-is. Jeremy On 10/3/2014 1:58 PM, Melinda Shore wrote: > On 10/3/14 11:26 AM, Stephen Kent wrote: >> I'm confused by the last sentence above. One can issue a cert at the >> same time a pre-cert is issued, but the cert does not contain the >> SCT that will be generated by the log, so the parallel issuance seems >> redundant, >> and I'm not sure how it helps. > This goes to the question of whether or not the serial number > is knowable at the time at the precertificate is constructed. > I don't know much beyond that; this is based on implementation > reports from an American CA. > >> I'd feel more comfortable on this topic if we had the results >> of the CABF member poll I suggested. Is there any progress on >> that front? > It's underway, and so far nobody is saying that the serial number > issue is a block to implementation. I'm very concerned that > we have not been able to close this issue for over six months, > and that while several people have raised concerns on > principle nobody who's actually implementing this on the CA side > has said that this is a show-stopper, or even enough of a difficulty > to raise it with us. We're very open to revisiting this if there's > new information. > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > . > From nobody Fri Oct 3 17:29:13 2014 Return-Path: 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 44ED81A89E5 for ; Fri, 3 Oct 2014 17:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 4EMSMiGdIOKV for ; Fri, 3 Oct 2014 17:29:05 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3141A87B1 for ; Fri, 3 Oct 2014 17:29:05 -0700 (PDT) X-AuditID: a66201d1-f796f6d000005865-e2-542f3f4f1c80 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 46.54.22629.F4F3F245; Sat, 4 Oct 2014 00:29:03 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1XaDDb-00035l-1P; Sat, 04 Oct 2014 00:29:03 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Fri, 3 Oct 2014 17:29:03 -0700 From: Rick Andrews To: Stephen Kent , "trans@ietf.org" Date: Fri, 3 Oct 2014 17:29:01 -0700 Thread-Topic: [Trans] updated definition and attack analysis text Thread-Index: Ac/doEsOqyzPI5yCSii8/3szo/HEmgBxcqDg Message-ID: <544B0DD62A64C1448B2DA253C011414607D19412E0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <542C3EFA.7010204@bbn.com> In-Reply-To: <542C3EFA.7010204@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607D19412E0TUS1XCHEVSPIN_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsWyLInRVdffXj/EYNdFA4uNsxkt1j6+yOLA 5DH1fKjHkiU/mQKYorhsUlJzMstSi/TtErgyNu7cxVwwYzdjxeQ9K9kaGH8uZuxi5OSQEDCR 6O88xw5hi0lcuLeerYuRi0NI4AOjxJG/rxkhnFeMEjNWvGaFcFYySny5NZkNpIVNQE9iy+Mr YO0iAk4S97vfMIHYLAIqEg0zZ4LVCAs4SBzd/oMJosZR4v7UB6wQtpHEmUVnwOK8AlESF1b/ A5sjJKAmsfHdJWYQm1NAXeLgkh6wGkag876fWgNmMwuIS9x6Mp8J4mwBiSV7zjND2KISLx// Y4WoF5W4076eEaI+X+LV4heMELsEJU7OfMICUS8pcXDFDZYJjGKzkIydhaRlFpIWiLiOxILd n9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRJjU5xzC3JDG/tKQgtcLAUK+4MjcRGJXJesn5uZsY IZF5cQfjhcO6hxgFOBiVeHjnmeiHCLEmlgFVHmKU4GBWEuHNswYK8aYkVlalFuXHF5XmpBYf YpTmYFES500J4QgREkhPLEnNTk0tSC2CyTJxcEo1MB48qVLC9vuQ1oW7L4rm+x2LUGvYsOCd aMnqs5nx/99p/lree0afQdojTfDl3e1LupI5zu7gMPaatfvE9b0fpHc47pCVc6tLa/xx5F3P 9MXBN741Zmq5MN5Yt37WS71vMkwq02ffWLFr5dLLRw7xb9Tv3mYuVPJ4+szHMx77Tv2ZtUvi zlKlzWt/KrEUZyQaajEXFScCAGsqlDPIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/trans/njLZrgyqxJUjUsm1SptNPMQKsk0 Subject: Re: [Trans] updated definition and attack analysis text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 00:29:09 -0000 --_000_544B0DD62A64C1448B2DA253C011414607D19412E0TUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, RFC 6962 says "In order to avoid logs being spammed into uselessness, it is= required that each chain is rooted in a known CA certificate", and that's = a syntactic check, isn't it? So it's not a question of whether logs will pe= rform syntax checks or not, it's a question of how much syntactic checking = will be required. Comments on your text are inline. -Rick From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, October 01, 2014 10:51 AM To: trans@ietf.org Subject: [Trans] updated definition and attack analysis text Ignoring (for the moment) the suggestion to not consider syntactic mis-issu= ance, and the topic of whether logs might perform syntax checks on certs submitte= d to them, I have revised the attack analysis text. It at least provides a sense of th= e style and structure one wants in such text, and which is missing from 6962-bis. I've expanded the definitions of mis-issuance based on the message exchange= s Ben and I had, to more clearly describe the cases of syntactic and semantic mis-issuance that are outside of the scope for CT, or that may be detectabl= e only if a Subject operates its own Monitor. I also added structure to group the = attack cases, to make for easier reading. I' ve kept the "notes" style, but these could b= e folded into the attack case analysis if desired. (It would just introduce some redundan= cy.) Steve ------ A certificate is characterized as mis-issued if the certificate does not co= nform to the requirements established by CA Browser Forum (CABF) documents = for "domain validation" (DV) or "extended validation" (EV) certificates [CA= BF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary fo= rms syntactic mis-issuance and semantic mis-issuance. Missing a colon after "forms". Most instances of the syntactic *form* of mis-issuance can be detected by e= xamining a certificate against a set of criteria extracted from the CABF gu= idelines. Based on whether a certificate purports to be a DV or an EV certi= ficate, one can examine it against almost all of the syntactic constraints = imposed by the guidelines. Appendix A, Section A.1 enumerates the syntactic= criteria to be used in this case. These checks can be performed by a log b= efore issuing an SCT, and if a (pre-) certificate fails these checks, it *t= he SCT* should not be issued. This behavior is RECOMMENDED to provide feedb= ack to CAs, to detect potential syntactic mis-issuance before the certifica= te is issued. 1. Criminals 2. Hacktivists 3. Nation states (intelligence organizations) 4. Other? Malicious or non-malicious Web PKI CAs operating improperly? If the certificate is submitted to a log prior to issuance (a pre-certifica= te), the (generally) detectable forms of syntactic mis-issuance (Section 1,= 1.a) will be detected, and the certificate will not be logged. Because the= CA is non-malicious, it will remedy the syntactic problem and re-submit th= e (pre-) certificate to a log again. Thus syntactic mis-issuance of this ty= pe will be thwarted. But only if the log behaves as RECOMMENDED above. 2.2 A Malicious Web PKI CA 2.2.1 If a certificate is submitted to a log prior to issuance (a pre-cert= ificate), the (generally) detectable forms of syntactic mis-issuance (Secti= on 1, 1.a) will be detected, and the certificate will not be logged. Howeve= r, because the CA is presumed to be malicious, the certificate may be issue= d anyway. Thus checking for syntactic mis-issuance in this case does not, p= er se, prevent such mis-issuance. However, if clients reject a certificate = that lacks (or is not accompanied by) an SCT, this form of mis-issuance wil= l be thwarted in this case. Again, only if the log behaves as RECOMMENDED above. Notes: 1. If a CA submits a bogus certificate to one or more logs, but these logs = are not watched by a Monitor that is protecting the targeted Subject, CT wi= ll not mitigate this type of mis-issuance attack. It is not clear whether e= very Monitor MUST offer to track every Subject that requests protection. Ab= sent such a guarantee, how do Subjects know which set of Monitors will prov= ide "sufficient" coverage. Of course, if a Subject acts as its own Monitor,= this problem is solved for that Subject. This raises the question of how a Monitor is supposed to know about all the= logs, when new ones are added, etc. 5. The combination of a malicious CA and one or more conspiring logs motiva= tes the use of Auditors, to detect conspiring logs. If a Monitor protecting= *a* Subject does not see mis-issued certificates, it cannot alert the Subj= ect. If one or *more* SCTs are present in a certificate, or passed via the = TLS handshake, a client has no way to know that the logged certificate is n= ot visible to Monitors. Only if clients reject certificates that contains S= CTs from conspiring logs will CT be able to deter use of such logs. Thus th= e means by which Auditors detect such logs, and inform TLS clients must be = specified. Moreover, if a certificate (or TLS handshake) contains more than= one SCT, the client MUST verify all of them if it is to counter the threat= posed by conspiring logs. --_000_544B0DD62A64C1448B2DA253C011414607D19412E0TUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Steve,

=

&n= bsp;

RFC 6962 says “In order to avoid logs being spammed int= o uselessness, it is required that each chain is rooted in a known CA certi= ficate”, and that’s a syntactic check, isn’t it? So it= 217;s not a question of whether logs will perform syntax checks or not, it&= #8217;s a question of how much syntactic checking will be required.

 

Comments on your text are inline.

 

-Rick

 

=

From: T= rans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2014 10:51 AM
To: trans@ietf.or= g
Subject: [Trans] updated definition and attack analysis text

 

Ig= noring (for the moment) the suggestion to not consider syntactic mis-issuan= ce,
and the topic of whether logs might perform syntax checks on certs s= ubmitted to them,
I have revised the attack analysis text. It at least p= rovides a sense of the style
and structure one wants in such text, and w= hich is missing from 6962-bis.

I've expanded the definitions of mis-= issuance based on the message exchanges
Ben and I had, to more clearly d= escribe the cases of syntactic and semantic
mis-issuance that are outsid= e of the scope for CT, or that may be detectable only
if a Subject opera= tes its own Monitor. I also added structure to group the attack cases,
= to make for easier reading. I' ve kept the "notes" style, but the= se could be folded into
the attack case analysis if desired. (It would = just introduce some redundancy.)

Steve

------ <= /span>

A cer= tificate is characterized as mis-issued if the certificate does not conform= to the requirements established by CA Browser Forum (CABF) documents for &= #8220;domain validation” (DV) or “extended validation” (E= V) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance t= akes two primary forms syntactic mis-issuance and semantic mis-issuance.

Mi= ssing a colon after “forms”.

 

=

Most instances = of the syntactic *= form* of mis-issuance can= be detected by examining a certificate against a set of criteria extracted= from the CABF guidelines. Based on whether a certificate purports to be a = DV or an EV certificate, one can examine it against almost all of the synta= ctic constraints imposed by the guidelines. Appendix A, Section A.1 enumera= tes the syntactic criteria to be used in this case. These checks can be per= formed by a log before issuing an SCT, and if a (pre-) certificate fails th= ese checks, it *the SCT* should not = be issued. This behavior is RECOMMENDED to provide feedback to CAs, to dete= ct potential syntactic mis-issuance before the certificate is issued.

 

 

<Discuss classes of adversaries, motivations,= and capabilities>

 

1. Criminals

 

2= . Hacktivists

 

= 3. Nation states (intelligence o= rganizations)

 

4. Other?

<= b>Malicious or non-malici= ous Web PKI CAs operating improperly?

  

If the certificate is submitted to a log prior= to issuance (a pre-certificate), the (generally) detectable forms of synta= ctic mis-issuance (Section 1, 1.a) will be detected, and the certificate wi= ll not be logged. Because the CA is non-malicious, it will remedy the synta= ctic problem and re-submit the (pre-) certificate to a log again. Thus synt= actic mis-issuance of this type will be thwarted.

But only if the log behav= es as RECOMMENDED above.

 

2.2 A Malicious Web PKI CA

 2.2.1 If a certificate is submitted to a log prior to issuance (a = pre-certificate), the (generally) detectable forms of syntactic mis-issuanc= e (Section 1, 1.a) will be detected, and the certificate will not be logged= . However, because the CA is presumed to be malicious, the certificate may = be issued anyway. Thus checking for syntactic mis-issuance in this case doe= s not, per se, prevent such mis-issuance. However, if clients reject a cert= ificate that lacks (or is not accompanied by) an SCT, this form of mis-issu= ance will be thwarted in this case.

Again, only if the log behaves as RECOM= MENDED above.

&nbs= p;

Notes:

 

= 1. If = a CA submits a bogus certificate to one or more logs, but these logs are no= t watched by a Monitor that is protecting the targeted Subject, CT will not= mitigate this type of mis-issuance attack. It is not clear whether every M= onitor MUST offer to track every Subject that requests protection. Absent s= uch a guarantee, how do Subjects know which set of Monitors will provide &#= 8220;sufficient” coverage. Of course, if a Subject acts as its own Mo= nitor, this problem is solved for that Subject.

This raises the question of ho= w a Monitor is supposed to know about all the logs, when new ones are added= , etc.

&n= bsp;

5. The combination of a malicious CA and one or more = conspiring logs motivates the use of Auditors, to detect conspiring logs. I= f a Monitor protecting *a* Subject does not= see mis-issued certificates, it cannot alert the Subject. If one or *more* SCTs are present in a certificate, or pass= ed via the TLS handshake, a client has no way to know that the logged certi= ficate is not visible to Monitors. Only if clients reject certificates that= contains SCTs from conspiring logs will CT be able to deter use of such lo= gs. Thus the means by which Auditors detect such logs, and inform TLS clien= ts must be specified. Moreover, if a certificate (or TLS handshake) contain= s more than one SCT, the client MUST verify all of them if it is to counter= the threat posed by conspiring logs.

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

= --_000_544B0DD62A64C1448B2DA253C011414607D19412E0TUS1XCHEVSPIN_-- From nobody Sun Oct 5 11:37:58 2014 Return-Path: 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 150051A1A94 for ; Sun, 5 Oct 2014 11:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 11lqw3tRP9WL for ; Sun, 5 Oct 2014 11:37:52 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2711A1A8E for ; Sun, 5 Oct 2014 11:37:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,660,1406606400"; d="scan'208,217";a="4332227" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 05 Oct 2014 14:37:50 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.03.0195.001; Sun, 5 Oct 2014 14:37:49 -0400 From: Santosh Chokhani To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] updated definition and attack analysis text Thread-Index: AQHP3aBJzE0wM8osr0i7nW4ODSW41ZwdOxdggAHNyICAAtGKAA== Date: Sun, 5 Oct 2014 18:37:48 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E811392396F3@scygexch10.cygnacom.com> References: <542C3EFA.7010204@bbn.com> <4262AC0DB9856847A2D00EF817E8113923603B@scygexch10.cygnacom.com> <542EF969.1020507@bbn.com> In-Reply-To: <542EF969.1020507@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.7] Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E811392396F3scygexch10cygnaco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/f7ZKTChBAziDk8G7m0nV01pl83Q Subject: Re: [Trans] updated definition and attack analysis text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 18:37:56 -0000 --_000_4262AC0DB9856847A2D00EF817E811392396F3scygexch10cygnaco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, How about the following "The entity (monitor, subject, or another entity) that is examining the log= s for certificate of interest for a subject (i.e., domain) has or obtains a= list valid certificates from the subject in a secure manner. The examini= ng party or the subject must not rely on the authorized CA or RA database f= or this information or use certificate discovery protocols; this informatio= n must be developed by the subject based on the certificates it has obtaine= d and installed. If the authorized CA or RA database is used to reconcile = with the certificates in the log, the mechanism does not detect mis-issuanc= e due to malfeasance on the part of the authorized CA or the RA or due to = compromise of the authorized CA or the RA. If the authorized CA or RA data= base is used, it does detect mis-issuance by unauthorized CA. The examinin= g party must not rely on certificate discovery mechanisms to build the list= of valid certificates since such mechanisms may also result in mis-issued = certificates being added to the list." From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Friday, October 03, 2014 3:31 PM To: trans@ietf.org Subject: Re: [Trans] updated definition and attack analysis text Santosh, Steve, Thanks. My primary concern with the analysis is that it does not discuss the practi= cality and resources and data required for the monitoring activity. It is= quite possible that monitoring will not be done at all or will miss things= or will be ineffective leaving the benefit of CT to largely as a deterrent= as opposed to detection mechanism. Threat analysis may wish to point that= out with significant emphasis since 6962 does not seem to emphasize this e= nough. I see CAs offering to perform monitoring service, which will not de= tect problems if the authorized CA or RA are compromised or have gone rogue= . In summary, the last paragraph of the analysis may wish to point out the= monitors may require subjects to use secure means to provide a list of val= id certificates from time to time and for monitor to check the logs for mis= -issuance against this list. 6962 does not address the critical aspect of = monitoring from the perspective of checking that the certificates are legit= imate. I'm happy to specific receive text to add to the analysis. I'll be updating= it next week to reflect the revised syntax checking anyway. Also, I have completed an i= nitial cut at the EV cert syntax rules and pkan to issue a complete Appendix A version ne= xt week as well. I agree that a CA that operates a log for itself, or a Monitor for its clie= nts seems questionable. When I think about Monitor services I look at what is availab= le today for address space monitoring. Companies monitor BGP advertisements, from open a= nd proprietary sources, looking for advertisements of prefixes that belong to client. If a= n advertised prefix does not have the origin AS of the client, it's suspicious. The client is i= nformed and can take action, e.g., contacting the AS that is advertising itself as the origin of= the client's prefix. This works reasonable well, but it is a for profit activity, i.e., people p= ay to have their prefixes monitored. If the designers of CT envision this as a likely deploy= ment scenario for CT, it ought to be mentioned. While just about everyone is against checking the certification path and c= ertificate, but if the goal is to secure Web PKI, to improve user experienc= e or at least protect less informed users from making bad choices when a br= owser barfs, I would think checking certificate, certification path, and ev= en cipher suites including proper range for RSA public exponent are good th= ings. I agree. Since I revised my proposal, so that even certs that fail syntacti= c validation are logged, maybe we can revisit the path validation issue. One could imagine a= dding an error code to an SCT that noted when the syntax is OK, but path validation fails,= and why. On specifics of your analysis, on Note 2, I would think the CA may wish to= get the whole certificate to verify that the certificate was issued by it = by verifying the signature using its own public keys. Good point. The log entry contains the cert, so it makes sense to provide t= hat to the CA what requesting that the cert be revoked. I'll make that change. Steve --_000_4262AC0DB9856847A2D00EF817E811392396F3scygexch10cygnaco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

 

How about the following

 

“The entity (monitor, subject, or another entity) that is examining = the logs for certificate of interest for a subject (i.e., domain) has or obtains a list valid certificates from the subject i= n a secure manner.   The examining party or the subject must not = rely on the authorized CA or RA database for this information or use certif= icate discovery protocols; this information must be developed by the subject based on the certificates it has obtained= and installed.  If the authorized CA or RA database is used to reconc= ile with the certificates in the log, the mechanism does not detect mis-iss= uance due to malfeasance on the part of the authorized CA or the RA  or due to compromise of the authorize= d CA or the RA.  If the authorized CA or RA database is used, it does = detect mis-issuance by unauthorized CA.  The examining party must not = rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms may also result in mi= s-issued certificates being added to the list.”

 

From: Trans [mailto:trans-bounces@= ietf.org] On Behalf Of Stephen Kent
Sent: Friday, October 03, 2014 3:31 PM
To: trans@ietf.org
Subject: Re: [Trans] updated definition and attack analysis text

 

Santosh,

Steve,

 

Thanks.

 

My primary concern with the analysis is that it does = not discuss the practicality  and resources and data required for the = monitoring activity.  It is quite possible that monitoring will not be done at all or will miss things or will be ine= ffective leaving the benefit of CT to largely as a deterrent as opposed to = detection mechanism.  Threat analysis may wish to point that out with = significant emphasis since 6962 does not seem to emphasize this enough.  I see CAs offering to perform mon= itoring service, which will not detect problems if the authorized CA or RA = are compromised or have gone rogue.  In summary, the last paragraph of= the analysis may wish to point out the monitors may require subjects to use secure means to provide a list of valid certif= icates from time to time and for monitor to check the logs for mis-issuance= against this list.  6962 does not address the critical aspect of moni= toring from the perspective of checking that the certificates are legitimate.

I'm happy to specific rece= ive text to add to the analysis. I'll be updating it next week
to reflect the revised syntax checking anyway.  Also, I have completed= an initial cut at
the EV cert syntax rules and pkan to issue a complete Appendix A version ne= xt week as well.

I agree that a CA that operates a log for itself, or a Monitor for its clie= nts seems
questionable. When I think about Monitor services I look at what is availab= le today for
address space monitoring. Companies monitor BGP advertisements, from open a= nd proprietary
sources, looking for advertisements of prefixes that belong to client. If a= n advertised prefix
does not have the origin AS of the client, it's suspicious. The client is i= nformed and can take
action, e.g., contacting the AS that is advertising itself as the origin of= the client's prefix.
This works reasonable well, but it is a for profit activity, i.e., people p= ay to have their
prefixes monitored. If the designers of CT envision this as a likely deploy= ment scenario for
CT, it ought to be mentioned.

 While just about everyone is against checking t= he certification path and certificate, but if the goal is to secure Web PKI= , to improve user experience or at least protect less informed users from making bad choices when a browser barfs, = I would think checking certificate, certification path, and even cipher sui= tes including proper range for RSA public exponent are good things.<= o:p>

I agree. Since I revised m= y proposal, so that even certs that fail syntactic validation are
logged, maybe we can revisit the path validation issue. One could imagine a= dding an error
code to an SCT that noted when the syntax is OK, but path validation fails,= and why.

 On specifics of your analysis, on Note 2, I wou= ld think the CA may wish to get the whole certificate to verify that the ce= rtificate was issued by it by verifying the signature using its own public keys.

Good point. The log entry = contains the cert, so it makes sense to provide that to the CA
what requesting that the cert be revoked.  I'll make that change.

Steve

--_000_4262AC0DB9856847A2D00EF817E811392396F3scygexch10cygnaco_-- From nobody Mon Oct 6 05:13:35 2014 Return-Path: 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 0E4311A6EDA for ; Mon, 6 Oct 2014 05:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 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, URIBL_RHS_DOB=1.514] 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 gkKdWfsp1MIq for ; Mon, 6 Oct 2014 05:13:29 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB4A1A6ED8 for ; Mon, 6 Oct 2014 05:13:27 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so3534380qge.22 for ; Mon, 06 Oct 2014 05:13:27 -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=IHzFh/3DP08rQech4NpZ7NrytT4gbFj94v7CbPJ46fc=; b=P8M/4b5L4Ymh5GvvFSGpJ4foV73XEBIxdcMko5WmpGWecxr/kllZV64fgxFDTRGYsG n2yO389P6FiiRzePrYo1Xyhmm2ZSucWc3M7vOZpxPCECPCyuYN0b/ifHh/EWZj6hKcd2 BMPQBPz5bWNY9EQfGJi6ybE2EV6nZUq4Z63H0ceJtAB5jog9O1RWpLTwH8axOaQl0IzH R/y5Ssa5SHTefkkMMuZFPwU2w8DgchCNwux8Z2TZl06bWb9E4PHzXaRXJwnsmBmb55Yp QyPIPyO7+g4VHoYalpLrYEBAjzGTJIlox8qWE1f2Sg8LLjIOiK5WSoEmm9u/OGNni2X/ xHpg== 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=IHzFh/3DP08rQech4NpZ7NrytT4gbFj94v7CbPJ46fc=; b=MWmZXnp8qKhuGkKUUSREE1akMpxhl/ElX0NM4QMt1gU+9G5fI3D4kfxJjnNoNY+NYJ MocYFpxZ5Q0XirazxWDCO/7qtsUuFcd36y4wreExADRnzRyzF+sYo2O59lqWj0wdGg/w +OVWosoKL8b3CukXtt6w5nFDBUjqvUqqCkrChTBBEGsRsna0r+0tfryWqvTKJbuDLmrk r8Q7fGLcJBC2WT3tJRo3Ug/p7YwCZ+XsbdyU4k3L67RcI0oDw7qxeeLnD8SKIZbpCVjO C4gH3ZE/bJktNaRxTgR7Hxq+pD/palPrf/48MHIN8EJyCjMStezsYCNTP633yuYC9SrO sfDg== X-Gm-Message-State: ALoCoQl7qvZKlywwoWn8fcMDRvnR1QjExsjCUD1U5nwq08kWiblDpPjbLsZJfpfXFtlOzJ01AElZ MIME-Version: 1.0 X-Received: by 10.224.137.3 with SMTP id u3mr9583878qat.82.1412597605904; Mon, 06 Oct 2014 05:13:25 -0700 (PDT) Received: by 10.229.247.198 with HTTP; Mon, 6 Oct 2014 05:13:25 -0700 (PDT) In-Reply-To: <542EF80D.8040802@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> <542EF80D.8040802@bbn.com> Date: Mon, 6 Oct 2014 13:13:25 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/MntVu2NumAuS7n7msGo3tU1g_WM Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 12:13:31 -0000 On 3 October 2014 20:25, Stephen Kent wrote: > Ben, > >> ... >> 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 >> 3. the cert conforms to EV guidelines >> >> - 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!). > > I'm confused by your comment. There is no "rejection" of a cert in the text > above. > That was the change I made to address the valid concerns that Rob and Rick > raised. I was adding another valid concern to Rob and Rick's, it was not meant to be a criticism of the above proposal. > If the cert failed checking it would still be logged, and an SCT issued, > but the fact that the syntax failed the checks would be noted in the SCT and > the log entry. Sure, but the language proposed does not cover certs - they may not be submitted by a CA and obviously they are not pre-certs. > Steve > > p.s. I realize that one more log-assigned value is needed, i.e., the > CA asserted #1, so the log didn't perform any check in this case Right. From nobody Mon Oct 6 06:48:08 2014 Return-Path: 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 627681A6F8C for ; Mon, 6 Oct 2014 06:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 Nf3g7q904-HQ for ; Mon, 6 Oct 2014 06:48:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456F11A6F7D for ; Mon, 6 Oct 2014 06:48:06 -0700 (PDT) Received: from localhost ([::1]:46409 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xb8ds-0006t4-6L; Mon, 06 Oct 2014 06:48:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Oct 2014 13:47:59 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/52 Message-ID: <063.f71bf7fc66bc86b70f571fe95288ae96@tools.ietf.org> X-Trac-Ticket-ID: 52 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/n7DpQjEBCn2VnAEqlXlLmV-_SUs Cc: trans@ietf.org Subject: [Trans] [trans] #52 (rfc6962-bis): verifying that gatewaying is working X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:48:07 -0000 #52: verifying that gatewaying is working Just checking, will be removed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- melinda.shore@gmail.com| rfc6962-bis@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Oct 6 06:49:28 2014 Return-Path: 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 7983D1A6F8A for ; Mon, 6 Oct 2014 06:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 NsGI1qOdpsi4 for ; Mon, 6 Oct 2014 06:49:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0D21A6F49 for ; Mon, 6 Oct 2014 06:49:25 -0700 (PDT) Received: from localhost ([::1]:46427 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xb8fD-0002Tg-Uy; Mon, 06 Oct 2014 06:49:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Oct 2014 13:49:23 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/52#comment:1 Message-ID: <078.99790a10bb5e7989ebbc8d2859782240@tools.ietf.org> References: <063.f71bf7fc66bc86b70f571fe95288ae96@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <063.f71bf7fc66bc86b70f571fe95288ae96@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/0OkjuKNJkppfNb2g13PjxTHL8Z8 Cc: trans@ietf.org Subject: Re: [Trans] [trans] #52 (rfc6962-bis): verifying that gatewaying is working X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:49:26 -0000 #52: verifying that gatewaying is working Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => invalid -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- melinda.shore@gmail.com| rfc6962-bis@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: invalid Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Oct 6 06:51:02 2014 Return-Path: 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 95B781A6F9E for ; Mon, 6 Oct 2014 06:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 PYakNZsE2byM for ; Mon, 6 Oct 2014 06:51:00 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E36F1A6F9D for ; Mon, 6 Oct 2014 06:50:56 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id g10so3334954pdj.32 for ; Mon, 06 Oct 2014 06:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=hdHdAWHgSX0GJxw+NCyBBhiNXrSfoPIxfKEFSMPSY1g=; b=v9cYlWASS5bnFUHMi7K5+7Kb61Ye+ZG9UOaZ1aD8tEY6MMLq3IvcurC5GGBHcE3ZMm nyrWuhUywI83zSzR1peoa8Huk5e1Zly1JYfzTT+BA6Zpch0cULxle62W8zNfQE+Vw8nY XA6uzCotxsr5NBVB1CEUfLvG+F5w2BQnFXjpo/nBrBsrm3QA+HSdfXpRtey5x+g1okYh dYc8EKRCkIx1S22TYIv8onzfsEs2PcCAiwKZeeZVArZvBYsUqQdQQqTmjUiT5O5zcnUj WQNvYIRvQY9ZhyGUCfTGjOH51zeftXn5fPEklh3RE+arNTy9FRXmSTL4Efu32WCECDWr IcOw== X-Received: by 10.70.35.232 with SMTP id l8mr18663805pdj.48.1412603455987; Mon, 06 Oct 2014 06:50:55 -0700 (PDT) Received: from spandex.local (216-67-46-2-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.46.2]) by mx.google.com with ESMTPSA id j5sm8223599pdp.9.2014.10.06.06.50.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 06:50:55 -0700 (PDT) Message-ID: <54329E3C.6040005@gmail.com> Date: Mon, 06 Oct 2014 05:50:52 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/SvcgUANM0Mkf4pqTxHyB05Nuy20 Subject: [Trans] ticket gatewaying now working X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:51:01 -0000 Hi, all: Many thanks to Henrik for fixing the problem with the issue tracker. Changes are now being gatewayed to the mailing list. Melinda From nobody Mon Oct 6 08:20:41 2014 Return-Path: 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 0F19C1A6FCD for ; Mon, 6 Oct 2014 08:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] 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 RPSBY0bUzNlF for ; Mon, 6 Oct 2014 08:20:34 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B3C1A6FC2 for ; Mon, 6 Oct 2014 08:20:33 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 09F8B80055 for ; Mon, 6 Oct 2014 11:20:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1412608831; bh=WgXIj1hus9b3VUXHWBEnmmYin/OG1uklQNp2t5nAqy0=; h=Date:From:To:Subject; b=hsrLZbUFqPgXV2C+bctD7+dwvDATmCNrUS4AXPjgw2leWjvI1qBxEkNe+bgcwwHw8 v2HNx22oJdtFsccN7C3LrfBnUGkCUdkgYCIsNG+aX9/F/dO7tBZ5fdHhi+255HxkDq j0dEwtX6ReG7aTXe+iJSezZJrDWMP/WnLQBlEMAM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s96FKUkq019194 for ; Mon, 6 Oct 2014 11:20:30 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 6 Oct 2014 11:20:30 -0400 (EDT) From: Paul Wouters To: trans@ietf.org Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/trans/q2BqA3MT524OP_uwGds-jrBRfKU Subject: [Trans] Misissuance vs auditing/monitoring X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:20:39 -0000 It seems the discussion about misissuance is going into far too many different policy decisions favoured by different people. That makes it obvious that it does not belong in the base specification document. The goal is to provide a distributed logging infrastructure that people can use with their clients and monitors. Consumers and providers can pick those that match their operational expectations and policies. Logs will have different policies on which kind of certificates they will accept into the log or not. But we should not come up with policies for people running the logs in different commercial or legal systems. Each will develop their own rules. The focus should be on what the minimum requirements are for inclusion into the log in such a way that the log is able to fulfill its function. Being resistant to spam/dos attacks is an important factor. But should we just mention it in the security sections and leave it open for everyone to decide on? Someone might want _only_ self signed certificates in their log server and it would be wrong if the base specification would forbid that. The serial number seems to be a hard requirement, as it is needed to uniquely identify the certificate. CABF policy is not. I'm sure there will be logs that will only allow EV certs. That's fine. Those policies do not belong in our document. For the base document, we need to focus only on the requirements needed for self-preservation of the log. If someone is interested in writing a separate policy document for a specific type of log, that would be great. For instance a log that only takes in CABF members issued certificates. Paul From nobody Wed Oct 8 08:04:12 2014 Return-Path: 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 D45771A1BF0 for ; Wed, 8 Oct 2014 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 frh72Wz_Flzn for ; Wed, 8 Oct 2014 08:04:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC97F1A1BFF for ; Wed, 8 Oct 2014 08:03:54 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40362 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xbsmb-000BQt-6W for trans@ietf.org; Wed, 08 Oct 2014 11:04:05 -0400 Message-ID: <54355255.4070109@bbn.com> Date: Wed, 08 Oct 2014 11:03:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" 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> <542EF80D.8040802@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4AMtU9Q2lxeVGr2uw7PSffZBWJ0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:04:11 -0000 Ben, > On 3 October 2014 20:25, Stephen Kent wrote: >> Ben, >> >>> ... >>> 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 >>> 3. the cert conforms to EV guidelines >>> >>> - 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!). >> I'm confused by your comment. There is no "rejection" of a cert in the text >> above. >> That was the change I made to address the valid concerns that Rob and Rick >> raised. > I was adding another valid concern to Rob and Rick's, it was not meant > to be a criticism of the above proposal. Sorry, I didn't realize the intent of your comment. But, in any case, my revised proposal addresses this concern as well. >> If the cert failed checking it would still be logged, and an SCT issued, >> but the fact that the syntax failed the checks would be noted in the SCT and >> the log entry. > Sure, but the language proposed does not cover certs - they may not be > submitted by a CA and obviously they are not pre-certs. Good point. I will revise the proposal to cover certs, as well as pre-certs. Steve From nobody Wed Oct 8 08:05:46 2014 Return-Path: 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 9D02C1A1B27 for ; Wed, 8 Oct 2014 08:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 iv1YcVz-dTLM for ; Wed, 8 Oct 2014 08:05:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC27C1A212A for ; Wed, 8 Oct 2014 08:05:14 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45080 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xbsnb-000ObI-E9 for trans@ietf.org; Wed, 08 Oct 2014 11:05:07 -0400 Message-ID: <543552A2.4020803@bbn.com> Date: Wed, 08 Oct 2014 11:05:06 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <542E7EFC.4050202@gmail.com> <542EF87B.5010105@bbn.com> <542EFFE4.90908@gmail.com> In-Reply-To: <542EFFE4.90908@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Syd7H4wss-Smhik-u8qQIh6OsJY Subject: Re: [Trans] making progress on precertificate discussion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:05:39 -0000 Melinda, > On 10/3/14 11:26 AM, Stephen Kent wrote: >> I'm confused by the last sentence above. One can issue a cert at the >> same time a pre-cert is issued, but the cert does not contain the >> SCT that will be generated by the log, so the parallel issuance seems >> redundant, >> and I'm not sure how it helps. > This goes to the question of whether or not the serial number > is knowable at the time at the precertificate is constructed. > I don't know much beyond that; this is based on implementation > reports from an American CA. I still don't understand the answer that was provided to you, as it does not address the issue of mechanisms that prevent serial number reuse. Never mind ... >> I'd feel more comfortable on this topic if we had the results >> of the CABF member poll I suggested. Is there any progress on >> that front? > It's underway, and so far nobody is saying that the serial number > issue is a block to implementation. Are you also getting responses to the "are you tracking the TRNAS WG" question I suggested? > I'm very concerned that > we have not been able to close this issue for over six months, > and that while several people have raised concerns on > principle nobody who's actually implementing this on the CA side > has said that this is a show-stopper, or even enough of a difficulty > to raise it with us. We're very open to revisiting this if there's > new information. That's a fair appraisal. If we get an thorough accounting of the poll, and it covers the vast majority of "root" CAs, then I will rescind by objection. Steve From nobody Wed Oct 8 08:06:04 2014 Return-Path: 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 32E1F1A1BC9 for ; Wed, 8 Oct 2014 08:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ErFQJ23_qs6j for ; Wed, 8 Oct 2014 08:05:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3201A1BF3 for ; Wed, 8 Oct 2014 08:05:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40366 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XbsoO-000BS9-NU for trans@ietf.org; Wed, 08 Oct 2014 11:05:56 -0400 Message-ID: <543552C4.7040505@bbn.com> Date: Wed, 08 Oct 2014 11:05:40 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <542C3EFA.7010204@bbn.com> <544B0DD62A64C1448B2DA253C011414607D19412E0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D19412E0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Content-Type: multipart/alternative; boundary="------------060301060002090501050604" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/fzBi6welUJ6a8Bx-PrBD7d2rPvM Subject: Re: [Trans] updated definition and attack analysis text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:06:01 -0000 This is a multi-part message in MIME format. --------------060301060002090501050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rick, > Steve, > > RFC 6962 says "In order to avoid logs being spammed into uselessness, > it is required that each chain is rooted in a known CA certificate", > and that's a syntactic check, isn't it? So it's not a question of > whether logs will perform syntax checks or not, it's a question of how > much syntactic checking will be required. > Good point. Logs do perform some syntax checks, but 6962-bis isn't clear on the extent of them. > > Comments on your text are inline. > Thanks for the detailed comments. I have made edits to address all of them. Steve --------------060301060002090501050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rick,

Steve,

 

RFC 6962 says “In order to avoid logs being spammed into uselessness, it is required that each chain is rooted in a known CA certificate”, and that’s a syntactic check, isn’t it? So it’s not a question of whether logs will perform syntax checks or not, it’s a question of how much syntactic checking will be required.

Good point. Logs do perform some syntax checks, but 6962-bis isn't clear on the extent of them.

 

Comments on your text are inline.

Thanks for the detailed comments. I have made edits to address all of them.

Steve
--------------060301060002090501050604-- From nobody Wed Oct 8 08:37:56 2014 Return-Path: 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 649031A6F96 for ; Wed, 8 Oct 2014 08:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 g5Rn-76XsMmS for ; Wed, 8 Oct 2014 08:37:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AA11A6F90 for ; Wed, 8 Oct 2014 08:37:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45985 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XbtJG-000Pil-1I for trans@ietf.org; Wed, 08 Oct 2014 11:37:50 -0400 Message-ID: <54355A4C.6000100@bbn.com> Date: Wed, 08 Oct 2014 11:37:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <542C3EFA.7010204@bbn.com> <4262AC0DB9856847A2D00EF817E8113923603B@scygexch10.cygnacom.com> <542EF969.1020507@bbn.com> <4262AC0DB9856847A2D00EF817E811392396F3@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E811392396F3@scygexch10.cygnacom.com> Content-Type: multipart/alternative; boundary="------------070909080202060808060707" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rbY-2ph7m7MZLHs7mU-PYe6UUgY Subject: Re: [Trans] updated definition and attack analysis text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:37:54 -0000 This is a multi-part message in MIME format. --------------070909080202060808060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh, > > Steve, > > How about the following > > "The entity (monitor, subject, or another entity) that is examining > the logs for certificate of interest for a subject (i.e., domain) has > or obtains a list valid certificates from the subject in a secure > manner. The examining party or the subject must not rely on the > authorized CA or RA database for this information or use certificate > discovery protocols; this information must be developed by the subject > based on the certificates it has obtained and installed. If the > authorized CA or RA database is used to reconcile with the > certificates in the log, the mechanism does not detect mis-issuance > due to malfeasance on the part of the authorized CA or the RA or due > to compromise of the authorized CA or the RA. If the authorized CA or > RA database is used, it does detect mis-issuance by unauthorized CA. > The examining party must not rely on certificate discovery mechanisms > to build the list of valid certificates since such mechanisms may also > result in mis-issued certificates being added to the list." > I'll add a version of your text to the discussion of Monitor operation. > > > While just about everyone is against checking the certification > path and certificate, but if the goal is to secure Web PKI, to > improve user experience or at least protect less informed users > from making bad choices when a browser barfs, I would think > checking certificate, certification path, and even cipher suites > including proper range for RSA public exponent are good things. > I agree, for the most part. Ben was the one who suggested enforcing key size constraints, and, implicitly algs. Ciphersuites are a TLS internal issue, so the best we can do is to enforce constraints on the algs used for cert signing, and the alg in the subjectPublicKeyInfo field. > I agree. Since I revised my proposal, so that even certs that fail > syntactic validation are > logged, maybe we can revisit the path validation issue. One could > imagine adding an error > code to an SCT that noted when the syntax is OK, but path validation > fails, and why. > > On specifics of your analysis, on Note 2, I would think the CA > may wish to get the whole certificate to verify that the > certificate was issued by it by verifying the signature using its > own public keys. > I have already made that change, based on one of Rick's comments. Steve --------------070909080202060808060707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Santosh,

Steve,

 

How about the following

 

“The entity (monitor, subject, or another entity) that is examining the logs for certificate of interest for a subject (i.e., domain) has or obtains a list valid certificates from the subject in a secure manner.   The examining party or the subject must not rely on the authorized CA or RA database for this information or use certificate discovery protocols; this information must be developed by the subject based on the certificates it has obtained and installed.  If the authorized CA or RA database is used to reconcile with the certificates in the log, the mechanism does not detect mis-issuance due to malfeasance on the part of the authorized CA or the RA  or due to compromise of the authorized CA or the RA.  If the authorized CA or RA database is used, it does detect mis-issuance by unauthorized CA.  The examining party must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms may also result in mis-issued certificates being added to the list.”

I'll add a version of your text to the discussion of Monitor operation.


 While just about everyone is against checking the certification path and certificate, but if the goal is to secure Web PKI, to improve user experience or at least protect less informed users from making bad choices when a browser barfs, I would think checking certificate, certification path, and even cipher suites including proper range for RSA public exponent are good things.

I agree, for the most part. Ben was the one who suggested enforcing key size constraints, and,
implicitly algs. Ciphersuites are a TLS internal issue, so the best we can do is to enforce
constraints on the algs used for cert signing, and the alg in the subjectPublicKeyInfo field.

I agree. Since I revised my proposal, so that even certs that fail syntactic validation are
logged, maybe we can revisit the path validation issue. One could imagine adding an error
code to an SCT that noted when the syntax is OK, but path validation fails, and why.

 On specifics of your analysis, on Note 2, I would think the CA may wish to get the whole certificate to verify that the certificate was issued by it by verifying the signature using its own public keys.

I have already made that change, based on one of Rick's comments.

Steve
--------------070909080202060808060707-- From nobody Wed Oct 8 13:51:20 2014 Return-Path: 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 0EEAB1A036D for ; Wed, 8 Oct 2014 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 BHRdtHB6Seyb for ; Wed, 8 Oct 2014 13:51:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A2D1A030B for ; Wed, 8 Oct 2014 13:51:12 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46960 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XbyCi-000FOE-Vy for trans@ietf.org; Wed, 08 Oct 2014 16:51:25 -0400 Message-ID: <5435A3AD.2080604@bbn.com> Date: Wed, 08 Oct 2014 16:50:53 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000409050908060901010404" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_D3jyjEKKDFMsJTftqTm91LfX9c Subject: Re: [Trans] Misissuance vs auditing/monitoring X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 20:51:17 -0000 This is a multi-part message in MIME format. --------------000409050908060901010404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Paul, > It seems the discussion about misissuance is going into far too > many different policy decisions favoured by different people. That > makes it obvious that it does not belong in the base specification > document. I agree that the specs for syntactic and semantic mis-issuance should be in a separate document, to better accommodate other types of certs beyond the Web PKI, evne though they are out of scope for the current doc, as per the TRANS charter, which specifies the scope of the first RFC: *Publish an update to RFC 6962 as a standards-track mechanism to* *apply verifiable logs to HTTP over TLS. * * * I do not agree that 6962-bis duck the question of what constitutes mis-issuance. I believe its possible to define the term in a way that will accommodate other cert types (even though that is NOT required for 6962-bis), and to include pointers to an RFC that describes how CAs, Subjects, logs, Monitors and clients can know what they're getting wrt mis-issuance checking. One RFC will describe syntactic and semantic requirements, derived from CABF specs, omitting parts that cannot be checked without Subject or CA-specific info. That seems to be the appropriate set of checks for the Web PKI. > The goal is to provide a distributed logging infrastructure that people > can use with their clients and monitors. Consumers and providers can > pick those that match their operational expectations and policies. This characterization omits mention of the context that is used to justify CT, i.e., the Web PKI. The charter later says:** * * *As DANE (RFC6698) provides an alternative keying infrastructure to that used * *in the current web PKI, the working group should consider appropriate client * *behavior in the presence of both DANE-based keying and current web PKI when* *standardising CT.* The charter also says that the WG could be re-chartered to address certs used with other security protocols. The approach I'm describing will accommodate certs used in other contexts, so if we pursue logs for DANE in the future, it will still work. > Logs will have different policies on which kind of certificates they will > accept into the log or not. But we should not come up with policies for > people running the logs in different commercial or legal systems. Each > will develop their own rules. I find these statements a bit confusing. First, under the current charter we're talking about just one type of cert, an X.509 cert issued to a web serer, right? We're not talking about code signing certs, certs for e-mail, certs for IPsec, etc. Those can come later, if the WG is re-chartered and elects to pursue them. My proposal for syntactic checking can accommodate certs issued for other purposes, easily. All we need to do is establish an IANA registry that specifies the type of cert that is being logged, as asserted by a CA or Subject. For each cert type there will be a matching RFC that defines what checks are to be performed. (Each new version of a cert spec receives a new registry entry, so that one knows which version is being asserted. Thus the scheme can accommodate new CABF guideline versions, etc.) The registry also should include a set of responses for a log to assert relative to the cert type asserted by the CA or Subject. For example, "I don't do checks", "I don't check this cert type/version", "I checked it and it passed" and "I checked it and it failed" or "the submitted said no criteria exists, so I didn't check." A log, if it _elects_ to perform checks, will know which checks to perform based on the value asserted in the log request. A Monitor that performs checks can make use of this info, because it will be part of the log entry. A Client that wants to accept SCTs from a log based on its ability (and willingness) to perform checks van learn what is and is not checked by the logs that generated the SCTs that the client encounters. This is a powerful mechanism for CT. One does need separate RFCs to define each set of checks, but the log interface and SCT format have to accommodate expressing the CA/Subject and log assertions if this capability is to be enabled. Thus the base doc needs to include such specifications. For the Web PKI context, the policies that exist are ones defined by the CABF, as profiles of RFC 5280 and RFC 3279. These policies apply to ALL CAs issuing EV certs, by definition, across all jurisdictions, AFAIK. I am not aware of any legal system differences that have arisen at the level of the specification that we are discussing. CABF members include CAs from North American, Europe, and Asia, and several of these CAs offer services in other parts of the world, e.g., Africa, via local RAs. Do you have some examples of the differences that are of concern, at the level of specification that we're discussing? More to the point, recall that my revised proposal does not _require_ a log to perform any syntactic checks; it _allows_ a log to do so, and to advertise the result of what it did, which provides for grater "transparency" wrt log operation. > The focus should be on what the minimum requirements are for inclusion > into the log in such a way that the log is able to fulfill its function. Again, if you have read my _revised_ proposal, the syntactic checks do not preclude inclusion of ANY cert into a log. Syntactic checking by a log is an optional service. I believe that Monitors ought to be required to perform syntactic checks, as well as semantic checks, so that clients know what services they get from Monitors, in a uniform, easy to understand fashion. But, that is a separate debate, right? > Being resistant to spam/dos attacks is an important factor. But should we > just mention it in the security sections and leave it open for > everyone to > decide on? Someone might want _only_ self signed certificates in their > log > server and it would be wrong if the base specification would forbid that. Two comments here: - 6962-bis mandates path checking (not well specified) to address one form of dos attack against logs. - you mention self-signed certs, but they (and DANE "certs") are explicitly excluded by 6962 and 7962-bis, based on the anti-dos mechanism noted above. So, your two observations above seem to be in conflict. Are you suggesting a change of scope in that respect? Is your comment here a direction issued as WG co-chair to the document editors? > The serial number seems to be a hard requirement, as it is needed to > uniquely identify the certificate. CABF policy is not. I'm sure there > will be logs that will only allow EV certs. That's fine. Those policies > do not belong in our document. I presume your comment about serial numbers is saying that a log entry needs to include a cert serial number, but that checking syntax (beyond the path validation requirement), is not essential to the function of a log. I agree. But, enabling a log to perform this function, by requiring the log interface and log entry and SCT formats to accommodate a simple assertion about cert type, and whether a log elected to perform syntax checks, does seem very valuable. This is especially true if one wants to expand logs to accommodate other forms of certs in the future, as you suggested above. Also, to be precise, my proposed does not impose a requirement that a cert be evaluated against DV or EV requirements, by a log. A CA or Subject can submit a (pre-) cert and assert that it does NOT purport to comply with any criteria. Using the IANA registry model I described above, other cert types can be accommodated cleanly, and need I say, _transparently_, while making it easy for Monitors and clients to know what type of cert has been logged. > For the base document, we need to focus only on the requirements needed > for self-preservation of the log. A log is one element of CT. We also need to describe the security functions of Monitors, clients, and Auditors (if this last one survives). I also think we need to include an attack analysis. > If someone is interested in writing a separate policy document for a > specific type of log, that would be great. For instance a log that only > takes in CABF members issued certificates. I don't think you meant exactly what you said; a non-CABF member might assert that they issue DV or EV certs. In summary, what I propose is that 6962-bis be revised to: - include an attack analysis - accommodate an assertion by a CA or Subject about a cert submitted to a log in the log submission, log entry, and SCT formats - accommodate an assertion by a log of what checks it performed, if any, and what was the outcome, in the log entry and SCT formats - refer to a separate RFC that creates the IANA registry for these assertions, and establishes the range of log assertions Yet another RFC will define CA/Subject assertions values for DV and EV certs, and the associated syntactic and semantic checks for these types of Web PKI certs. Since the focus of the initial doc being produced by TRANS is Web PKI certs, I think it is appropriate to cite this last RFC as consistent with that focus. Steve --------------000409050908060901010404 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Paul,

It seems the discussion about misissuance is going into far too
many different policy decisions favoured by different people. That
makes it obvious that it does not belong in the base specification
document.
I agree that the specs for syntactic and semantic mis-issuance should be
in a separate document, to better accommodate other types of certs beyond
the Web PKI, evne though they are out of scope for the current doc, as per the
TRANS charter, which specifies the scope of the first RFC:

Publish an update to RFC 6962 as a standards-track mechanism to
apply verifiable logs to HTTP over TLS.

I do not agree that 6962-bis duck the question of what constitutes mis-issuance.
I believe its possible to define the term in a way that will accommodate other
cert types (even though that is NOT required for 6962-bis), and to include pointers
to an RFC that describes how CAs, Subjects, logs, Monitors and clients can know
what they're getting wrt mis-issuance checking.

One RFC will describe syntactic and semantic requirements, derived from CABF specs,
omitting parts that cannot be checked without Subject or CA-specific info. That seems
to be the appropriate set of checks for the Web PKI.

The goal is to provide a distributed logging infrastructure that people
can use with their clients and monitors. Consumers and providers can
pick those that match their operational expectations and policies.
This characterization omits mention of the context that is used to justify
CT, i.e., the Web PKI. The charter later says:
As DANE (RFC6698) provides an alternative keying infrastructure to that used
in the current web PKI, the working group should consider appropriate client
behavior in the presence of both DANE-based keying and current web PKI when
standardising CT.

The charter also says that the WG could be re-chartered to address certs used with
other security protocols. The approach I'm describing will accommodate certs used
in other contexts, so if we pursue logs for DANE in the future, it will still work.
Logs will have different policies on which kind of certificates they will
accept into the log or not. But we should not come up with policies for
people running the logs in different commercial or legal systems. Each
will develop their own rules.
I find these statements a bit confusing. First, under the current charter we're talking
about just one type of cert, an X.509 cert issued to a web serer, right? We're
not talking about code signing certs, certs for e-mail, certs for IPsec, etc. Those
can come later, if the WG is re-chartered and elects to pursue them.

My proposal for syntactic checking can accommodate certs issued for other purposes, easily.
All we need to do is establish an IANA registry that specifies the type of cert that
is being logged, as asserted by a CA or Subject. For each cert type there will be
a matching RFC that defines what checks are to be performed. (Each new version of
a cert spec receives a new registry entry, so that one knows which version is being
asserted. Thus the scheme can accommodate new CABF guideline versions, etc.)

The registry also should include a set of responses for a log to assert relative to the
cert type asserted by the CA or Subject. For example, "I don't do checks", "I don't
check this cert type/version", "I checked it and it passed" and "I checked it and it
failed" or "the submitted said no criteria exists, so I didn't check."

A log, if it elects to perform checks, will know which checks to perform based on the
value asserted in the log request. A Monitor that performs checks can make use of this info,
because it will be part of the log entry. A Client that wants to accept SCTs from a log
based on its ability (and willingness) to perform checks van learn what is and is not
checked by the logs that generated the SCTs that the client encounters.

This is a powerful mechanism for CT. One does need separate RFCs to define each set of
checks, but the log interface and SCT format have to accommodate expressing the CA/Subject
and log assertions if this capability is to be enabled. Thus the base doc needs to
include such specifications.

For the Web PKI context, the policies that exist are ones defined by the CABF,
as profiles of RFC 5280 and RFC 3279. These policies apply to ALL CAs issuing EV certs,
by definition, across all jurisdictions, AFAIK. I am not aware of any legal system
differences that have arisen at the level of the specification that we are discussing.
CABF members include CAs from North American, Europe, and Asia, and several of these
CAs offer services in other parts of the world, e.g., Africa, via local RAs.
Do you have some examples of the differences that are of concern, at the level of
specification that we're discussing?

More to the point, recall that my revised proposal does not require a log to perform
any syntactic checks; it allows a log to do so, and to advertise the result of what it
did, which provides for grater "transparency" wrt log operation.
The focus should be on what the minimum requirements are for inclusion
into the log in such a way that the log is able to fulfill its function.
Again, if you have read my revised proposal, the syntactic checks do not preclude
inclusion of ANY cert into a log. Syntactic checking by a log is an optional
service. I believe that Monitors ought to be required to perform syntactic
checks, as well as semantic checks, so that clients know what services they
get from Monitors, in a uniform, easy to understand fashion. But, that is a
separate debate, right?
Being resistant to spam/dos attacks is an important factor. But should we
just mention it in the security sections and leave it open for everyone to
decide on? Someone might want _only_ self signed certificates in their log
server and it would be wrong if the base specification would forbid that.
Two comments here:
    - 6962-bis mandates path checking (not well specified)  to address one form
of dos attack against logs.
     - you mention self-signed certs, but they (and DANE "certs") are explicitly
excluded by 6962 and 7962-bis, based on the anti-dos mechanism noted above.
So, your two observations above seem to be in conflict. Are you suggesting a
change of scope in that respect?  Is your comment here a direction issued as
WG co-chair to the document editors?
The serial number seems to be a hard requirement, as it is needed to
uniquely identify the certificate. CABF policy is not. I'm sure there
will be logs that will only allow EV certs. That's fine. Those policies
do not belong in our document.
I presume your comment about serial numbers is saying that a log entry needs to
include a cert serial number, but that checking syntax (beyond the path validation
requirement), is not essential to the function of a log. I agree.

But, enabling a log to perform this function, by requiring the log interface and
log entry and SCT formats to accommodate a simple assertion about cert type,
and whether a log elected to perform syntax checks, does seem very valuable.
This is especially true if one wants to expand logs to accommodate other forms
of certs in the future, as you suggested above.

Also, to be precise, my proposed does not impose a requirement that a cert be
evaluated against DV or EV requirements, by a log. A CA or Subject can submit
a (pre-) cert and assert that it does NOT purport to comply with any criteria.
Using the IANA registry model I described above, other cert types can be
accommodated cleanly, and need I say, transparently, while making it easy for
Monitors and clients to know what type of cert has been logged.

For the base document, we need to focus only on the requirements needed
for self-preservation of the log.
A log is one element of CT. We also need to describe the security functions
of Monitors, clients, and Auditors (if this last one survives). I also think we
need to include an attack analysis.
If someone is interested in writing a separate policy document for a
specific type of log, that would be great. For instance a log that only
takes in CABF members issued certificates.
I don't think you meant exactly what you said; a non-CABF member might assert
that they issue DV or EV certs.

In summary, what I propose is that 6962-bis be revised to:

    - include an attack analysis

    - accommodate an assertion by a CA or Subject about a cert submitted to a log
      in the log submission, log entry, and SCT formats

    - accommodate an assertion by a log of what checks it performed, if any, and
      what was the outcome, in the log entry and SCT formats

    - refer to a separate RFC that creates the IANA registry for these assertions,
      and establishes the range of log assertions

Yet another RFC will define CA/Subject assertions values for DV and EV certs,
and the associated syntactic and semantic checks for these types of Web PKI certs.
Since the focus of the initial doc being produced by TRANS is Web PKI certs, I think
it is appropriate to cite this last RFC as consistent with that focus.

Steve

--------------000409050908060901010404-- From nobody Thu Oct 9 14:21:14 2014 Return-Path: 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 794371A6FD6 for ; Thu, 9 Oct 2014 14:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 k-JR66f_83fQ for ; Thu, 9 Oct 2014 14:21:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D975E1A8878 for ; Thu, 9 Oct 2014 14:21:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47988 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XcL8s-00064T-QS for trans@ietf.org; Thu, 09 Oct 2014 17:20:59 -0400 Message-ID: <5436FC38.1070201@bbn.com> Date: Thu, 09 Oct 2014 17:20:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------020708040705050607030002" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/nohOLvlgMfclX-pDULc-qTgK-RE Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:21:08 -0000 This is a multi-part message in MIME format. --------------020708040705050607030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In response to some of the issues Paul and others have raised, I have generated some text that tries to characterize the goal of CT, establishes a generic framnework for defining checks for mis-issuance, and sets the stage for references to two RFcs that will define syntactic and semantic checks for Web PKI certs claiming to conform to CABF DV or EV guidelines. Note that this text do not require a log to perform any checks; it allows a log to indicate if has performed applicable checks, and the results of such checking. Steve ------- 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 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. A certificate mis-issued by a CA, and detected by the CT system, is presumed to damage the reputation of the CA. Thus it is anticipated that CT will deter mis-issuance via monitoring of logs. It also is anticipated that CT also will help remedy mis-issuance, in two ways. When a mis-issued certificate is detected as such, the Subject will be notified. The Subject can contact the issuer and request revocation of the bogus certificate, using information from the log. A certificate is characterized as mis-issued if the certificate does not conform to requirements established for the class of certificate in question. The term "class" refers to certificates used in different application contexts and issued under different sets of syntactic and semantic guidelines. Thus, for example, most certificates used in the Web PKI context are issued by CAs under guidelines published by the CA Browser Forum (CABF). (If a new version of guidelines is created for a class of certificates, a new certificate class ID (CCID) will be assigned. This allows certificates issued under old and new sets of guidelines to be checked appropriately, without introducing ambiguity.) Certificates used with IPsec, S/MIME, or other security protocols each constitute a different class. A certificate that is not issued in accordance with any published set of requirements is assigned a reserved CCID. 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. This document establishes an IANA registry of CCIDs (see Section *Y*) to enable CT to deal with additional classes of certificates in the future. The registry is initially populated with CCIDs deemed appropriate for the Web PKI context (see Section *Y*). Every registry entry lists the RFC (or analogous document) that specifies the checks applicable to the registered certificate class. One entry is established to indicate a CCID for which no applicable checks have been defined. Mis-issuance Mis-issuance takes two primary forms: syntactic mis-issuance and semantic mis-issuance. 1.A certificate may fail to meet the syntactic constraints established for a specified certificate class. Such failure can have serious security implications, e.g., a failure to include the basicConstrainst extension in a Web PKI certificate can allow the holder of an EE certificate to issue subordinate certificates that may be accepted by browsers. Most syntactic constraints can be checked via examination of a certificate chain, without reference to Subject-specific or CA-specific data. This means that these constraints can be verified by logs without access to Subject-specific data. 2.A certificate may fail to meet the semantic constraints established for a specified certificate class. The usual (though not universal) semantic constraint is that a certificate is issued only to an entity that is authorized to represent the Subject name (subjectAltName) in the certificate. This constraint can be verified by comparing a certificate against the set of "reference" certificates supplied by a Subject. In the Web PKI context, the Subject (subjectAltName) represents a web server, and the entity to which the certificate is issued is presumed to be authorized by the owner of the corresponding DNS name. For other classes of certificates, the relevant name might be an IP address, an e-mail address, or some other identifier appropriate to the application context in which the certificate is used. A log MAY perform the syntactic checks consistent with the certificate class asserted by the CA or Subject that submits a (pre-) certificate to the log. This behavior is RECOMMENDED to provide timely feedback to CAs and Subjects when certificates are submitted to logs. For a CA it can detect potential syntactic mis-issuance before a certificate is issued. For a Subject, it provides an indication of whether its certificate conforms to the asserted criteria. A log MUST include the asserted certificate class ID in the log entry. 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 is 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 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. A Monitor also may perform syntactic checks of certificates. It may do so because a certificate was not checked by a log (as indicated in the log entry), or as a way to detect logs that have been compromised or that are deficient or malicious. Detection of semantic mis-issuance requires access to one or more "reference" certificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificate issued to a specified Subject, consistent with the guidelines specified by the certificate class ID.) As noted above, the primary attack addressed by detection of semantic mis-issuance is issuance of a certificate to an entity that is not authorized to represent the host (web server) named in the certificate Subject field (or subjectAltName extension). Section *Y.* IANA Registry for Certificate Class Identifiers (CCIDs) The name of the registry shall be "Certificate Class Identifiers for use with Certificate Transparency", This is a "Standards Action" registry.Each registry entry consists of a positive integer (16-bit) and a reference to the RFC that defines the syntactic and semantics checks applicable to the certificate class identified by the integer. The first entry "0" designates a certificate class for which no syntactic or semantic checks are defined. The following initial entries are created by this RFC: ValueRFC 0N/A 1XXXX (certificate checks derived from [CABF-DV]) 2XXXX (certificate checks derived from [CABF-EV]) Section Z. Syntax Verification Value (SVV) Definitions The following integer (8-bit) values are defined for the Syntax Verification Values (SVVs) generated by a log. ValueInterpretation 0The CCID value was 0, so not checks were performed 1This log does not perform syntax checks 2This log does not support syntax checks for the asserted CCID 3This log performed the syntax checks for the asserted CCID, and the certificate passed 4This log performed the syntax checks for the asserted CCID, and the certificate failed No other SVV values are defined by this RFC. --------------020708040705050607030002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In response to some of the issues Paul and others have raised, I have generated
some text that tries to characterize the goal of CT, establishes a generic framnework
for defining checks for mis-issuance, and sets the stage for references to two RFcs
that will define syntactic and semantic checks for Web PKI certs claiming to conform to
CABF DV or EV guidelines.

Note that this text do not require a log to perform any checks; it allows a log to
indicate if has performed applicable checks, and the results of such checking.

Steve
-------

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

 

A certificate mis-issued by a CA, and detected by the CT system, is presumed to damage the reputation of the CA. Thus it is anticipated that CT will deter mis-issuance via monitoring of logs. It also is anticipated that CT also will help remedy mis-issuance, in two ways. When a mis-issued certificate is detected as such, the Subject will be notified. The Subject can contact the issuer and request revocation of the bogus certificate, using information from the log.

 

A certificate is characterized as mis-issued if the certificate does not conform to requirements established for the class of certificate in question. The term “class” refers to certificates used in different application contexts and issued under different sets of syntactic and semantic guidelines. Thus, for example, most certificates used in the Web PKI context are issued by CAs under guidelines published by the CA Browser Forum (CABF). (If a new version of guidelines is created for a class of certificates, a new certificate class ID (CCID) will be assigned. This allows certificates issued under old and new sets of guidelines to be checked appropriately, without introducing ambiguity.) Certificates used with IPsec, S/MIME, or other security protocols each constitute a different class. A certificate that is not issued in accordance with any published set of requirements is assigned a reserved CCID.

 

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.

 

This document establishes an IANA registry of CCIDs (see Section Y) to enable CT to deal with additional classes of certificates in the future. The registry is initially populated with CCIDs deemed appropriate for the Web PKI context (see Section Y). Every registry entry lists the RFC (or analogous document) that specifies the checks applicable to the registered certificate class. One entry is established to indicate a CCID for which no applicable checks have been defined.

 

Mis-issuance

 

Mis-issuance takes two primary forms: syntactic mis-issuance and semantic mis-issuance.

 

1. A certificate may fail to meet the syntactic constraints established for a specified certificate class. Such failure can have serious security implications, e.g., a failure to include the basicConstrainst extension in a Web PKI certificate can allow the holder of an EE certificate to issue subordinate certificates that may be accepted by browsers. Most syntactic constraints can be checked via examination of a certificate chain, without reference to Subject-specific or CA-specific data. This means that these constraints can be verified by logs without access to Subject-specific data.

 

2. A certificate may fail to meet the semantic constraints established for a specified certificate class. The usual (though not universal) semantic constraint is that a certificate is issued only to an entity that is authorized to represent the Subject name (subjectAltName) in the certificate. This constraint can be verified by comparing a certificate against the set of “reference” certificates supplied by a Subject. In the Web PKI context, the Subject (subjectAltName) represents a web server, and the entity to which the certificate is issued is presumed to be authorized by the owner of the corresponding DNS name. For other classes of certificates, the relevant name might be an IP address, an e-mail address, or some other identifier appropriate to the application context in which the certificate is used.

 

A log MAY perform the syntactic checks consistent with the certificate class asserted by the CA or Subject that submits a (pre-) certificate to the log. This behavior is RECOMMENDED to provide timely feedback to CAs and Subjects when certificates are submitted to logs. For a CA it can detect potential syntactic mis-issuance before a certificate is issued. For a Subject, it provides an indication of whether its certificate conforms to the asserted criteria. A log MUST include the asserted certificate class ID in the log entry.

 

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

 

A Monitor also may perform syntactic checks of certificates. It may do so because a certificate was not checked by a log (as indicated in the log entry), or as a way to detect logs that have been compromised or that are deficient or malicious.

 

Detection of semantic mis-issuance requires access to one or more “reference” certificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificate issued to a specified Subject, consistent with the guidelines specified by the certificate class ID.) As noted above, the primary attack addressed by detection of semantic mis-issuance is issuance of a certificate to an entity that is not authorized to represent the host (web server) named in the certificate Subject field (or subjectAltName extension).

 

 

Section Y. IANA Registry for Certificate Class Identifiers (CCIDs)

 

The name of the registry shall be " Certificate Class Identifiers for use with Certificate Transparency",

 

This is a “Standards Action” registry.  Each registry entry consists of a positive integer (16-bit) and a reference to the RFC that defines the syntactic and semantics checks applicable to the certificate class identified by the integer. The first entry “0” designates a certificate class for which no syntactic or semantic checks are defined.

 

The following initial entries are created by this RFC:

 

Value       RFC

0                 N/A

1                 XXXX (certificate checks derived from [CABF-DV])

2                 XXXX (certificate checks derived from [CABF-EV])

  

 

Section Z. Syntax Verification Value (SVV) Definitions

 

The following integer (8-bit) values are defined for the Syntax Verification Values (SVVs) generated by a log.

 

Value     Interpretation

0                 The CCID value was 0, so not 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.


--------------020708040705050607030002-- From nobody Mon Oct 13 15:21:03 2014 Return-Path: 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 56AD91A03A9 for ; Mon, 13 Oct 2014 15:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] 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 qLJAcORDNHiH for ; Mon, 13 Oct 2014 15:20:58 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750131A03A2 for ; Mon, 13 Oct 2014 15:20:58 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5974A80055; Mon, 13 Oct 2014 18:20:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1413238857; bh=z4BRH2jwLjRZ70TrYVROmd5p8Luc16T8ed38Kp3EoLo=; h=Date:From:To:Subject; b=k9DZnrf5uqRAQV0TxzWeYV8kdp02fgL4sD0u/e5uKa31ABlyqzLMLDSgSmwhkzwyp u29ETCCZgpCEw/sESizNeNLqec0bK0j+bAY9KVThfI+UDoNotR536nnXXedHqib9Xo NfffjqAKPWDPUWwePocvRdymIRPtpP7ThyR2RmFs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s9DMKuBI001428; Mon, 13 Oct 2014 18:20:57 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 13 Oct 2014 18:20:56 -0400 (EDT) From: Paul Wouters To: Trans , Melinda Shore Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/trans/s6cNpCar9d1ggXEfwofdtzKa57c Subject: [Trans] Agenda for IETF-91 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 22:21:00 -0000 Below is our draft agenda for IETF-91. If you wish to add something, please let us know as soon as possible. Paul & Melinda IETF-91 trans agenda 15:20 - 17:20 Monday 10 Nov 2014 Agenda Issue tracker status Requirements for entry into the log 6962-bis update Gossip protocol document Client/monitor protocol document CT for DNSSEC CT for executables Compressed CRLs [Phillip] Any other business? Agenda administrivia (~5 minutes) blue sheets, scribes, agenda-bashing Status update (~15 minutes) milestone review quickie overview of draft status open trac issues run-down (Eran) Requirements for entry into the log (~20 minutes) discussion 6962-bis (Ben, ~10 minutes) current state what needs to be done between now and working group last call Gossip protocol (Linus?, Daniel?, ~10 minutes) current state Client/monitor protocol document (~5 minutes) Looking for volunteers CT for DNSSEC (Dacheng, ~15 minutes) CT for executables (Dacheng, ~15 minutes) Compressed CRLs (Phillip, ~10 minutes) Any other business? From nobody Tue Oct 14 09:42:54 2014 Return-Path: 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 0EB6B1A8A89 for ; Tue, 14 Oct 2014 09:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 9wgH_Pq21agd for ; Tue, 14 Oct 2014 09:42:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADD91A8A64 for ; Tue, 14 Oct 2014 09:42:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60615 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xe5BI-0004DC-0K for trans@ietf.org; Tue, 14 Oct 2014 12:42:41 -0400 Message-ID: <543D527E.40506@bbn.com> Date: Tue, 14 Oct 2014 12:42:38 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------090405070409020507010508" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/A1NoiskTkQI9rJfW4oMvgfWpucQ Subject: [Trans] attack analysis, revised X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:42:53 -0000 This is a multi-part message in MIME format. --------------090405070409020507010508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The text below is my current take on an attack analysis for CT, revised to reflect the goal of a broader, long-term scope, but emphasizing the current, Web PKI-centric focus of the charter. It also has been changed based on several comments from folks over the past week or so. I think this analysis belongs in 6962-bis. It raises some questions that need to be answered as revisions proceed, and suggests some topics that should be discussed in the security considerations section. Comments (especially revised text) welcome, Steve ------- *XX*. Attack Model and Discussion of Detection and Mitigation Options Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to detect and redress mis-issuance depends on the context and the entities involved in the mis-issuance. This attack model applies to the Web PKI context. If CT is applied to other contexts, each will require its own attack model, although most of the model described here is likely to be applicable. Certificates are issued by CAs, so the top level differentiation is whether the CA that mis-issued a certificate did so maliciously or not. If not, then the next point of differentiation is whether the mis-issuance was the result of an accident or an attack. In the case of an attack, it is necessary to consider whether the certificate was logged, and if so, whether the log conspired with the attacker. If the CA acted maliciously, it is necessary to ask whether it logged a mis-issued certificate. If so, then one must consider whether the CA conspired with one or more log operators, or conspired with one of more Monitors (for not self-monitoring Subjects). The following sections examine each of these cases, for both syntactic and semantic mis-issuance. As noted above, the focus here is on the Web PKI context, although most of the analysis is applicable to other PKI contexts. *XX*.1 A non-malicious Web PKI CA If a certificate is submitted to a log, either prior to issuance (a pre-certificate), or post-issuance, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted (pre-) certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance. If syntactic validation fails, this will be noted in the SCT returned to the CA, and because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again. Thus syntactic mis-issuance can be avoided by a CA if it makes use of logs that are capable of performing these checks for the types of certificates that are submitted, assuming that it acts on the feedback it receives. If a CA uses a log that does not perform such checks, or if the CA requests checking relative to criteria not supported by the log, then syntactic mis-issuance will not be detected. *XX*.1.1 A CA may issue the certificate to an unauthorized party (semantic mis-issuance), as a result of an error or because it was the victim of a social engineering attack. We will refer to such a certificate as "bogus". In this case the CA has a record of the bogus certificate and it is prepared to revoke the bogus certificate once it has confirmed its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is "protecting" the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate is irrelevant to the mitigation procedure in this case. (See Note 1 below.) Because the mis-issuance was not malicious, there is no notion of a log operator or a Monitor conspiring with the CA. *XX*.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a certificate. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content. *XX*.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and alert it. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will make use of the log entry (supplied by the Subject) to determine the serial number of the mis-issued certificate, and revoke it (after investigation). (See Notes 1 + 2.) If TLS clients reject a certificate when no SCT is provided, this might motivate the attacker to log the bogus certificates, which helps justify such client behavior. (See Note 3.) *XX*.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If TLS clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3.) XX.1.2.3 The bogus certificate may have been submitted to logs that are conspiring with the attacker. In this case, Monitors will not detect the bogus certificate because the logs will suppress a bogus certificate log entry. TLS clients will not reject a bogus certificate in this case, because it is accompanied by an SCT. In this scenario, unless Monitors or Auditors "gossip" to detect conspiring logs, the bogus certificate will not be detected. *XX*.2 A Malicious Web PKI CA *XX*.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance. Because the CA is presumed to be malicious, the CA may cause the log to not perform checks, in one of two ways. The CA may assert that the certificate is being issued w/o regard to any guidelines (the "no guidelines" reserved CCID), or it may assert a CCID that has not been registered. In this fashion the CA can prevent the log from performing checks, and the SCT and log entry will not contain an indication of a failed check. Alternatively, the CA may submit a (pre-) certificate to a log that is known to not perform syntactic checks, and thus avoid syntactic checking. If a client rejects a certificate that has not been syntactically checked (as indicated by the SCT), the first approach to subverting syntax checking will fail. If a client rejects a certificate that was logged by an operator that does not perform syntactic checks, the third approach noted above will fail. If a client is configured to know which versions of CABF guidelines exist, the second approach to avoiding syntactic checking also can be thwarted. *XX*.2.2 Because the CA is presumed malicious, it may choose to not submit a certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case. (See Note 3.) *XX*.2.3 A malicious CA may submit a certificate to one or more logs that collude with this CA to not perform syntactic checks, even though they claim to do so. In this case the syntactic mis-issuance will not be detected by logs. The log entry and the SCT for a syntactically invalid certificate will assert that the certificate syntax was verified. Unless Monitors also perform syntactic checks, this form of mis-issuance will not be thwarted in this case. TLS clients will believe that the certificate has been syntactically verified. *XX*.2.4 A malicious CA may semantically mis-issue a certificate that is syntactically valid. Because it is syntactically valid, logs will not reject the bogus certificate. This situation might result because the CA was bribed or was compelled to issue the bogus certificate. A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.This CA might be one or more tiers below a trust anchor (aka root CA). *XX*.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3.) *XX*.2.4.2 A bogus certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor protecting the targeted Subject will detect a bogus certificate and alert the targeted subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc. In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4.) *XX*.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will not detect the bogus certificate, even if it is trying to protect the targeted Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semantically mis-issued certificate. Auditors are intended to detect logs that conspire to suppress log entries, based on consistency checking of logs and use of a "gossip" protocol. Until such checks are clearly defined and a gossip protocol is defined and deployed, CT does not provide the necessary info to detect this form of mis-issuance. When Auditors can detect a conspiring log, Monitors and clients can be alerted to it (how?). This would cause Monitors to avoid using such a log, and clients would reject SCTs generated by such a log. (See Note 5 below.) Notes: 1.If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide "sufficient" coverage. If a Subject acts as its own Monitor, this problem is solved for that Subject. It is not clear how a Monitor becomes aware of all (relevant?) logs, including newly added logs. The means by which Monitors become aware of new logs MUST accommodate self-monitoring by a potentially very large number of web site operators. 2.A CA being presented with evidence of a bogus certificate, in the form of a log entry, will need to examine its records to determine if it has knowledge of the certificate in question. It also will likely require the targeted Subject to provide assurances that it is the authorized entity representing the Subject name (subjectAltname) in question. Thus a Subject should not expect immediate revocation of a contested certificate. The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA. Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on applicable criteria. The SCT and log entry, because each contains a timestamp from a third party, is probably valuable for forensic purposes (assuming a non-conspiring log operator). 3.If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules. Until a mechanism is defined that accommodates incremental deployment of this capability, attackers should not be expected to submit bogus certificates to (non-conspiring) logs. 4.A targeted Subject might request the parent of a malicious CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If one can configure a browser to reject a specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. This mitigation strategy calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication has not been specified, i.e., there no standard ways to configure a browser to reject individual bogus certificates based on info provided by a Monitor. Moreover, the same or another malicious CA could issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks. 5.The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or more SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if Monitors and clients reject certificates that contains SCTs from conspiring logs (based on info from Audotirs) will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients and Monitors must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, it appears that the client MUST verify all of them if it is to counter the threat posed by conspiring logs. Absent a "gossip" protocol that enables Auditors to verify that data from logs are reported in a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance. Monitors play a critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. A monitor (including a Subject performing self-monitoring) examines logs for certificates associated with one or more Subjects. It must obtain a list valid certificates for the Subject being monitored, in a secure manner. A Monitor must not rely on a CA or RA database for this information or use certificate discovery protocols; this information must be acquired by the Monitor based on reference certificates it has obtained and installed. If a Monitor were to rely on a CA or RA database (for the CA that issued a targeted certificate), the Monitor would not detect mis-issuance due to malfeasance on the part of that CA or the RA, or due to compromise of the CA or the RA. If a CA or RA database is used, it does detect mis-issuance by an unauthorized CA. A Monitor must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms might result in mis-issued certificates being added to the list. Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden of Monitor operation may be viewed as too great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise. Now that certificate pinning has been approved as a standard, it is appropriate to factor in its use by TLS clients. It would appear that pinning will dramatically reduce the set of TLS clients that are vulnerable to mis-issuance; a client that pins a certificate for a web site would reject a bogus certificate even without use of any CT mechanisms. The security considerations section of 6962-bis needs to note this, as it suggests that deployment of pinning reduces the need for CT. --------------090405070409020507010508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The text below is my current take on an attack analysis for CT, revised to
reflect the goal of a broader, long-term scope, but emphasizing the current,
Web PKI-centric focus of the charter. It also has been changed based on several
comments from folks over the past week or so.  I think this analysis belongs in
6962-bis. It raises some questions that need to be answered as revisions proceed,
and suggests some topics that should be discussed in the security considerations section.

Comments (especially revised text) welcome,

Steve
-------

XX. Attack Model and Discussion of Detection and Mitigation Options

 

Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to detect and redress mis-issuance depends on the context and the entities involved in the mis-issuance. This attack model applies to the Web PKI context. If CT is applied to other contexts, each will require its own attack model, although most of the model described here is likely to be applicable.

 

Certificates are issued by CAs, so the top level differentiation is whether the CA that mis-issued a certificate did so maliciously or not. If not, then the next point of differentiation is whether the mis-issuance was the result of an accident or an attack. In the case of an attack, it is necessary to consider whether the certificate was logged, and if so, whether the log conspired with the attacker.

 

If the CA acted maliciously, it is necessary to ask whether it logged a mis-issued certificate. If so, then one must consider whether the CA conspired with one or more log operators, or conspired with one of more Monitors (for not self-monitoring Subjects).

 

The following sections examine each of these cases, for both syntactic and semantic mis-issuance. As noted above, the focus here is on the Web PKI context, although most of the analysis is applicable to other PKI contexts.

 

 

XX.1 A non-malicious Web PKI CA

 

If a certificate is submitted to a log, either prior to issuance (a pre-certificate), or post-issuance, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted (pre-) certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance. If syntactic validation fails, this will be noted in the SCT returned to the CA, and because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again.

 

Thus syntactic mis-issuance can be avoided by a CA if it makes use of logs that are capable of performing these checks for the types of certificates that are submitted, assuming that it acts on the feedback it receives. If a CA uses a log that does not perform such checks, or if the CA requests checking relative to criteria not supported by the log, then syntactic mis-issuance will not be detected.

 

XX.1.1 A CA may issue the certificate to an unauthorized party (semantic mis-issuance), as a result of an error or because it was the victim of a social engineering attack. We will refer to such a certificate as “bogus”. In this case the CA has a record of the bogus certificate and it is prepared to revoke the bogus certificate once it has confirmed its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is “protecting” the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate is irrelevant to the mitigation procedure in this case. (See Note 1 below.) Because the mis-issuance was not malicious, there is no notion of a log operator or a Monitor conspiring with the CA.

 

XX.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a certificate. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content.

 

XX.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and alert it. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will make use of the log entry (supplied by the Subject) to determine the serial number of the mis-issued certificate, and revoke it (after investigation). (See Notes 1 + 2.) If TLS clients reject a certificate when no SCT is provided, this might motivate the attacker to log the bogus certificates, which helps justify such client behavior. (See Note 3.)

 

XX.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If TLS clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3.)

 

XX.1.2.3 The bogus certificate may have been submitted to logs that are conspiring with the attacker. In this case, Monitors will not detect the bogus certificate because the logs will suppress a bogus certificate log entry. TLS clients will not reject a bogus certificate in this case, because it is accompanied by an SCT. In this scenario, unless Monitors or Auditors “gossip” to detect conspiring logs, the bogus certificate will not be detected.

 

 

XX.2 A Malicious Web PKI CA

 

XX.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance.

 

Because the CA is presumed to be malicious, the CA may cause the log to not perform checks, in one of two ways. The CA may assert that the certificate is being issued w/o regard to any guidelines (the “no guidelines” reserved CCID), or it may assert a CCID that has not been registered. In this fashion the CA can prevent the log from performing checks, and the SCT and log entry will not contain an indication of a failed check. Alternatively, the CA may submit a (pre-) certificate to a log that is known to not perform syntactic checks, and thus avoid syntactic checking.

 

If a client rejects a certificate that has not been syntactically checked (as indicated by the SCT), the first approach to subverting syntax checking will fail. If a client rejects a certificate that was logged by an operator that does not perform syntactic checks, the third approach noted above will fail. If a client is configured to know which versions of CABF guidelines exist, the second approach to avoiding syntactic checking also can be thwarted.

 

XX.2.2 Because the CA is presumed malicious, it may choose to not submit a certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case. (See Note 3.)

 

XX.2.3 A malicious CA may submit a certificate to one or more logs that collude with this CA to not perform syntactic checks, even though they claim to do so. In this case the syntactic mis-issuance will not be detected by logs.  The log entry and the SCT for a syntactically invalid certificate will assert that the certificate syntax was verified. Unless Monitors also perform syntactic checks, this form of mis-issuance will not be thwarted in this case. TLS clients will believe that the certificate has been syntactically verified.

 

XX.2.4 A malicious CA may semantically mis-issue a certificate that is syntactically valid. Because it is syntactically valid, logs will not reject the bogus certificate. This situation might result because the CA was bribed or was compelled to issue the bogus certificate. A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.  This CA might be one or more tiers below a trust anchor (aka root CA).

 

XX.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3.)

 

XX.2.4.2 A bogus certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor protecting the targeted Subject will detect a bogus certificate and alert the targeted subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc. In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4.)

 

XX.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will not detect the bogus certificate, even if it is trying to protect the targeted Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semantically mis-issued certificate.

 

Auditors are intended to detect logs that conspire to suppress log entries, based on consistency checking of logs and use of a “gossip” protocol. Until such checks are clearly defined and a gossip protocol is defined and deployed, CT does not provide the necessary info to detect this form of mis-issuance.  When Auditors can detect a conspiring log, Monitors and clients can be alerted to it (how?). This would cause Monitors to avoid using such a log, and clients would reject SCTs generated by such a log. (See Note 5 below.)

 

Notes:

 

1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide “sufficient” coverage. If a Subject acts as its own Monitor, this problem is solved for that Subject. It is not clear how a Monitor becomes aware of all (relevant?) logs, including newly added logs. The means by which Monitors become aware of new logs MUST accommodate self-monitoring by a potentially very large number of web site operators.

 

2. A CA being presented with evidence of a bogus certificate, in the form of a log entry, will need to examine its records to determine if it has knowledge of the certificate in question. It also will likely require the targeted Subject to provide assurances that it is the authorized entity representing the Subject name (subjectAltname) in question. Thus a Subject should not expect immediate revocation of a contested certificate. The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA. Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on applicable criteria. The SCT and log entry, because each contains a timestamp from a third party, is probably valuable for forensic purposes (assuming a non-conspiring log operator).

 

3. If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules. Until a mechanism is defined that accommodates incremental deployment of this capability, attackers should not be expected to submit bogus certificates to (non-conspiring) logs.

 

4. A targeted Subject might request the parent of a malicious CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If one can configure a browser to reject a specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. This mitigation strategy calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication has not been specified, i.e., there no standard ways to configure a browser to reject individual bogus certificates based on info provided by a Monitor. Moreover, the same or another malicious CA could issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks.

 

5. The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or more SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if Monitors and clients reject certificates that contains SCTs from conspiring logs (based on info from Audotirs) will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients and Monitors must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, it appears that the client MUST verify all of them if it is to counter the threat posed by conspiring logs.

 

Absent a “gossip” protocol that enables Auditors to verify that data from logs are reported in a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance.

 

Monitors play a critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. A monitor (including a Subject performing self-monitoring) examines logs for certificates associated with one or more Subjects. It must obtain a list valid certificates for the Subject being monitored, in a secure manner.  A Monitor must not rely on a CA or RA database for this information or use certificate discovery protocols; this information must be acquired by the Monitor based on reference certificates it has obtained and installed. If a Monitor were to rely on a CA or RA database (for the CA that issued a targeted certificate), the Monitor would not detect mis-issuance due to malfeasance on the part of that CA or the RA, or due to compromise of the CA or the RA.  If a CA or RA database is used, it does detect mis-issuance by an unauthorized CA.  A Monitor must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms might result in mis-issued certificates being added to the list.

 

Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden of Monitor operation may be viewed as too great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise.

 

Now that certificate pinning has been approved as a standard, it is appropriate to factor in its use by TLS clients. It would appear that pinning will dramatically reduce the set of TLS clients that are vulnerable to mis-issuance; a client that pins a certificate for a web site would reject a bogus certificate even without use of any CT mechanisms. The security considerations section of 6962-bis needs to note this, as it suggests that deployment of pinning reduces the need for CT.


--------------090405070409020507010508-- From nobody Wed Oct 15 12:02:50 2014 Return-Path: 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 A9B1C1A910A for ; Wed, 15 Oct 2014 12:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZQVXl-Z2P8Qs for ; Wed, 15 Oct 2014 12:02:36 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357991A1B19 for ; Wed, 15 Oct 2014 12:02:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,726,1406606400"; d="scan'208,217";a="2346324" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge2.cygnacom.com with ESMTP; 15 Oct 2014 15:02:35 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 15:02:34 -0400 From: Santosh Chokhani To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] attack analysis, revised Thread-Index: AQHP583qoU57jVIvnUGLLs4FVpQNS5wxgfEg Date: Wed, 15 Oct 2014 19:02:34 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E8113923E418@scygexch10.cygnacom.com> References: <543D527E.40506@bbn.com> In-Reply-To: <543D527E.40506@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.7] Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E8113923E418scygexch10cygnaco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2YbWoeF-GkM__eTp0ytGxSWH858 Subject: Re: [Trans] attack analysis, revised X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:02:47 -0000 --_000_4262AC0DB9856847A2D00EF817E8113923E418scygexch10cygnaco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, Looks good to me. See a few comments editorial and substantive in-line bel= ow starting at Note 4. From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, October 14, 2014 12:43 PM To: trans@ietf.org Subject: [Trans] attack analysis, revised The text below is my current take on an attack analysis for CT, revised to reflect the goal of a broader, long-term scope, but emphasizing the current= , Web PKI-centric focus of the charter. It also has been changed based on sev= eral comments from folks over the past week or so. I think this analysis belong= s in 6962-bis. It raises some questions that need to be answered as revisions pr= oceed, and suggests some topics that should be discussed in the security considera= tions section. Comments (especially revised text) welcome, Steve ------- XX. Attack Model and Discussion of Detection and Mitigation Options Certificate mis-issuance may arise in one of several ways. The ways that CT= enables a Subject (or others) to detect and redress mis-issuance depends o= n the context and the entities involved in the mis-issuance. This attack mo= del applies to the Web PKI context. If CT is applied to other contexts, eac= h will require its own attack model, although most of the model described h= ere is likely to be applicable. Certificates are issued by CAs, so the top level differentiation is whether= the CA that mis-issued a certificate did so maliciously or not. If not, th= en the next point of differentiation is whether the mis-issuance was the re= sult of an accident or an attack. In the case of an attack, it is necessary= to consider whether the certificate was logged, and if so, whether the log= conspired with the attacker. If the CA acted maliciously, it is necessary to ask whether it logged a mis= -issued certificate. If so, then one must consider whether the CA conspired= with one or more log operators, or conspired with one of more Monitors (fo= r not self-monitoring Subjects). The following sections examine each of these cases, for both syntactic and = semantic mis-issuance. As noted above, the focus here is on the Web PKI con= text, although most of the analysis is applicable to other PKI contexts. XX.1 A non-malicious Web PKI CA If a certificate is submitted to a log, either prior to issuance (a pre-cer= tificate), or post-issuance, syntactic mis-issuance can be detected, and no= ted. This will happen only if the log performs syntactic checks in general,= and if the log is capable of performing the checks applicable to the submi= tted (pre-) certificate. A (pre-) certificate will be logged even if it fai= ls syntactic validation, thus logging takes precedence over detection of sy= ntactic mis-issuance. If syntactic validation fails, this will be noted in = the SCT returned to the CA, and because the CA is non-malicious, it will re= medy the syntactic problem and re-submit the (pre-) certificate to a log ag= ain. Thus syntactic mis-issuance can be avoided by a CA if it makes use of logs = that are capable of performing these checks for the types of certificates t= hat are submitted, assuming that it acts on the feedback it receives. If a = CA uses a log that does not perform such checks, or if the CA requests chec= king relative to criteria not supported by the log, then syntactic mis-issu= ance will not be detected. XX.1.1 A CA may issue the certificate to an unauthorized party (semantic mi= s-issuance), as a result of an error or because it was the victim of a soci= al engineering attack. We will refer to such a certificate as "bogus". In t= his case the CA has a record of the bogus certificate and it is prepared to= revoke the bogus certificate once it has confirmed its error. If the CA is= submitting (pre-) certificates for logging, there will be evidence of the = mis-issuance in one or more logs. If a Monitor is "protecting" the targeted= Subject, it will detect the mis-issuance, and will alert the Subject. Beca= use the CA has a record of the mis-issuance, it should revoke the bogus cer= tificate, after investigating, based on the information provided by the leg= itimate certificate Subject. The presence of an embedded SCT in the bogus c= ertificate, or an SCT accompanying the bogus certificate is irrelevant to t= he mitigation procedure in this case. (See Note 1 below.) Because the mis-i= ssuance was not malicious, there is no notion of a log operator or a Monito= r conspiring with the CA. XX.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack= (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a certi= ficate. In this case the CA is not aware of the mis-issuance and may have n= o record of the certificate content. XX.1.2.1 The mis-issued certificate may have been submitted to one or more = logs prior to issuance, to acquire an embedded SCT, or post-issuance to acq= uire a standalone SCT. In either case, a Monitor that is protecting the tar= geted Subject will detect the bogus certificate and alert it. The Subject, = in turn, will request the CA to revoke the bogus certificate. In this case,= the CA will make use of the log entry (supplied by the Subject) to determi= ne the serial number of the mis-issued certificate, and revoke it (after in= vestigation). (See Notes 1 + 2.) If TLS clients reject a certificate when n= o SCT is provided, this might motivate the attacker to log the bogus certif= icates, which helps justify such client behavior. (See Note 3.) XX.1.2.2 The bogus certificate may not have been submitted to any logs. In = this case, Monitors will not detect the bogus certificate. If TLS clients r= eject a certificate that lacks (or is not accompanied by) an SCT, the attac= ker will be thwarted in this case. (See Note 3.) XX.1.2.3 The bogus certificate may have been submitted to logs that are con= spiring with the attacker. In this case, Monitors will not detect the bogus= certificate because the logs will suppress a bogus certificate log entry. = TLS clients will not reject a bogus certificate in this case, because it is= accompanied by an SCT. In this scenario, unless Monitors or Auditors "goss= ip" to detect conspiring logs, the bogus certificate will not be detected. XX.2 A Malicious Web PKI CA XX.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, synt= actic mis-issuance can be detected, and noted. This will happen only if the= log performs syntactic checks in general, and if the log is capable of per= forming the checks applicable to the submitted certificate. A (pre-) certif= icate will be logged even if it fails syntactic validation, thus logging ta= kes precedence over detection of syntactic mis-issuance. Because the CA is presumed to be malicious, the CA may cause the log to not= perform checks, in one of two ways. The CA may assert that the certificate= is being issued w/o regard to any guidelines (the "no guidelines" reserved= CCID), or it may assert a CCID that has not been registered. In this fashi= on the CA can prevent the log from performing checks, and the SCT and log e= ntry will not contain an indication of a failed check. Alternatively, the C= A may submit a (pre-) certificate to a log that is known to not perform syn= tactic checks, and thus avoid syntactic checking. If a client rejects a certificate that has not been syntactically checked (= as indicated by the SCT), the first approach to subverting syntax checking = will fail. If a client rejects a certificate that was logged by an operator= that does not perform syntactic checks, the third approach noted above wil= l fail. If a client is configured to know which versions of CABF guidelines= exist, the second approach to avoiding syntactic checking also can be thwa= rted. XX.2.2 Because the CA is presumed malicious, it may choose to not submit a = certificate to a log. This avoids detection of syntactic mis-issuance by a = log, but it also means there is no SCT for the certificate. If clients reje= ct a certificate that lacks (or is not accompanied by) an SCT, this form of= mis-issuance will be thwarted in this case. (See Note 3.) XX.2.3 A malicious CA may submit a certificate to one or more logs that col= lude with this CA to not perform syntactic checks, even though they claim t= o do so. In this case the syntactic mis-issuance will not be detected by lo= gs. The log entry and the SCT for a syntactically invalid certificate will= assert that the certificate syntax was verified. Unless Monitors also perf= orm syntactic checks, this form of mis-issuance will not be thwarted in thi= s case. TLS clients will believe that the certificate has been syntacticall= y verified. XX.2.4 A malicious CA may semantically mis-issue a certificate that is synt= actically valid. Because it is syntactically valid, logs will not reject th= e bogus certificate. This situation might result because the CA was bribed = or was compelled to issue the bogus certificate. A CA might be compelled to= issue a bogus certificate by a government agency or a criminal organizatio= n. This CA might be one or more tiers below a trust anchor (aka root CA). XX.2.4.1 A bogus certificate may not have been submitted to any logs. In th= is case, Monitors will not detect the bogus certificate. If clients reject = a certificate that lacks (or is not accompanied by) an SCT, the attacker wi= ll be thwarted in this case. (See Note 3.) XX.2.4.2 A bogus certificate may have been submitted to one or more logs pr= ior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a= standalone SCT. In either case, a Monitor protecting the targeted Subject = will detect a bogus certificate and alert the targeted subject. The Subject= , in turn, will request the CA to revoke the bogus certificate. In this cas= e, the CA may refuse, or substantially delay, to revoke the bogus certifica= te. It could make excuses about inadequate proof that the certificate is bo= gus, or argue that it cannot quickly revoke the certificate because of loca= l, legal concerns, etc. In this case, the CT mechanisms have detected mis-i= ssuance, but the information logged by CT does not help remedy the problem.= (See Note 4.) XX.2.5 A bogus certificate may have been submitted to one or more conspirin= g logs. These logs will issue SCTs, but will hide the log entries from some= or all Monitors. Any Monitor from which the log is hiding data will not de= tect the bogus certificate, even if it is trying to protect the targeted Su= bject. If a client accepts an SCT from a conspiring log, then the client wi= ll not reject the bogus certificate on the basis of a missing SCT. In this = case CT will not detect the semantically mis-issued certificate. Auditors are intended to detect logs that conspire to suppress log entries,= based on consistency checking of logs and use of a "gossip" protocol. Unti= l such checks are clearly defined and a gossip protocol is defined and depl= oyed, CT does not provide the necessary info to detect this form of mis-iss= uance. When Auditors can detect a conspiring log, Monitors and clients can= be alerted to it (how?). This would cause Monitors to avoid using such a l= og, and clients would reject SCTs generated by such a log. (See Note 5 belo= w.) Notes: 1. If a CA submits a bogus certificate to one or more logs, but these logs = are not watched by a Monitor that is protecting the targeted Subject, CT wi= ll not mitigate this type of mis-issuance attack. It is not clear whether e= very Monitor MUST offer to track every Subject that requests protection. Ab= sent such a guarantee, how do Subjects know which set of Monitors will prov= ide "sufficient" coverage. If a Subject acts as its own Monitor, this probl= em is solved for that Subject. It is not clear how a Monitor becomes aware = of all (relevant?) logs, including newly added logs. The means by which Mon= itors become aware of new logs MUST accommodate self-monitoring by a potent= ially very large number of web site operators. 2. A CA being presented with evidence of a bogus certificate, in the form o= f a log entry, will need to examine its records to determine if it has know= ledge of the certificate in question. It also will likely require the targe= ted Subject to provide assurances that it is the authorized entity represen= ting the Subject name (subjectAltname) in question. Thus a Subject should n= ot expect immediate revocation of a contested certificate. The time frame i= n which a CA will respond to a revocation request usually is described in t= he CPS for the CA. Other certificate fields and extensions may be of intere= st for forensic purposes, but are not required to effect revocation nor to = verify that the certificate to be revoked is bogus, based on applicable cri= teria. The SCT and log entry, because each contains a timestamp from a thir= d party, is probably valuable for forensic purposes (assuming a non-conspir= ing log operator). 3. If a TLS client is to reject a certificate that lacks an embedded SCT, o= r is not accompanied by an SCT transported via the TLS handshake, this beha= vior needs to be defined in a way that is compatible with incremental deplo= yment. Issuing a warning to a (human) user is probably insufficient, based = on experience with warnings displayed for expired certificates, lack of cer= tificate revocation status information, and similar errors that violate RFC= 5280 path validation rules. Until a mechanism is defined that accommodates= incremental deployment of this capability, attackers should not be expecte= d to submit bogus certificates to (non-conspiring) logs. 4. A targeted Subject might request the parent of a malicious CA to revoke = the certificate of the non-cooperative CA. However, a request of this sort = may be rejected, e.g., because of the potential for significant collateral = damage. A browser might be configured to reject all certificates issued by = the malicious CA, e.g., using a CA hot list distributed by a browser vendor= . However, if the malicious CA has a sufficient number of legitimate client= s, treating all of them as bogus still represents serious collateral damage= . If one can configure a browser to reject a specific, bogus certificate id= entified by a Monitor, then the bogus certificate could be rejected in that= fashion. This mitigation strategy calls for communication between Monitors= and browsers, or between Monitors and browser vendors. Such communication = has not been specified, i.e., there [Santosh] (Add "is" here) no standard w= ays to configure a browser to reject individual bogus certificates based on= info provided by a Monitor. Moreover, the same or another malicious CA cou= ld issue new bogus certificates for the targeted Subject, which would have = to be detected and rejected in this (as yet unspecified) fashion. Thus, for= now, CT does not seem to provide a way to mitigate this form of attack, ev= en though it provides a basis for detecting such attacks. 5. The combination of a malicious CA and one or more conspiring logs motiva= tes the use of Auditors, to detect conspiring logs. If a Monitor protecting= s Subject does not see mis-issued certificates, it cannot alert the Subjec= t. If one or more SCTs are present in a certificate, or passed via the TLS = handshake, a client has no way to know that the logged certificate is not v= isible to Monitors. Only if Monitors and clients reject certificates that c= ontains SCTs from conspiring logs (based on info from Audotirs) will CT be = able to deter use of such logs. Thus the means by which Auditors detect suc= h logs, and inform TLS clients and Monitors must be specified. Moreover, if= a certificate (or TLS handshake) contains more than one SCT, it appears th= at the client MUST verify all of them if it is to counter the threat posed = by conspiring logs. Absent a "gossip" protocol that enables Auditors to verify that data from l= ogs are reported in a consistent fashion to many (all?) Monitors, CT does n= ot provide protection against logs that may conspire with, or be victims of= , attackers effecting certificate mis-issuance. When a gossip protocol is d= efined and deployed, it will be necessary to describe how the CT system wil= l deal with a mis-behaving or compromised log. For example, will there be a= mechanism to alert all TLS clients to reject SCTs issued by such a log. Ab= sent a description of a mitigation strategy to deal with mis-behaving or co= mpromised logs, CT cannot ensure detection of mis-issuance. Monitors play a critical role in detecting semantic certificate mis-issuanc= e, for Subjects that have requested monitoring of their certificates. A mon= itor (including a Subject performing self-monitoring) examines logs for cer= tificates associated with one or more Subjects. It must obtain a list valid= certificates for the Subject being monitored, in a secure manner. A Monit= or must not rely on a CA or RA database for this information or use certifi= cate discovery protocols; this information must be acquired by the Monitor = based on reference certificates [Santosh] (replace "it" with "subject") it= has obtained and installed. If a Monitor were to rely on a CA or RA databa= se (for the CA that issued a targeted certificate), the Monitor would not d= etect mis-issuance due to malfeasance on the part of that CA or the RA, or = due to compromise of the CA or the RA. If a CA or RA database is used, it = does detect mis-issuance by an unauthorized CA. A Monitor must not rely on= certificate discovery mechanisms to build the list of valid certificates s= ince such mechanisms might result in mis-issued certificates being added to= the list. Monitors represent another target for adversaries who wish to effect certif= icate mis-issuance. If a Monitor is compromised by, or conspires with, an a= ttacker, it will fail to alert a Subject to a mis-issued certificate target= ing that Subject. This suggests that a Subject SHOULD request certificate m= onitoring from multiple sources to guard against such failures. Operation o= f a Monitor by a Subject, on its own behalf, avoids dependence on third par= ty Monitors, but the burden of Monitor operation may be viewed as too great= for many web sites, and thus this mode of operation ought not be assumed t= o be universal when evaluating protection against Monitor compromise. Now that certificate pinning has been approved as a standard, it is appropr= iate to factor in its use by TLS clients. It would appear that pinning will= dramatically reduce the set of TLS clients that are vulnerable to mis-issu= ance; a client that pins a certificate for a web site would reject a bogus = certificate even without use of any CT mechanisms. The security considerati= ons section of 6962-bis needs to note this, as it suggests that deployment = of pinning reduces the need for CT. --_000_4262AC0DB9856847A2D00EF817E8113923E418scygexch10cygnaco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

 

Looks good to me= .  See a few comments editorial and substantive in-line below starting= at Note 4.

 

From: Trans [mailto:trans-bounces@= ietf.org] On Behalf Of Stephen Kent
Sent: Tuesday, October 14, 2014 12:43 PM
To: trans@ietf.org
Subject: [Trans] attack analysis, revised

 

The text below is my current take on an attack analy= sis for CT, revised to
reflect the goal of a broader, long-term scope, but emphasizing the current= ,
Web PKI-centric focus of the charter. It also has been changed based on sev= eral
comments from folks over the past week or so.  I think this analysis b= elongs in
6962-bis. It raises some questions that need to be answered as revisions pr= oceed,
and suggests some topics that should be discussed in the security considera= tions section.

Comments (especially revised text) welcome,

Steve
-------


XX. Attack Model and Discussion of Detection and Mitiga= tion Options

 

Certificate mis-issuance may a= rise in one of several ways. The ways that CT enables a Subject (or others)= to detect and redress mis-issuance depends on the context and the entities involved in the mis-issuance. This attack = model applies to the Web PKI context. If CT is applied to other contexts, e= ach will require its own attack model, although most of the model described= here is likely to be applicable.

 

Certificates are issued by CAs= , so the top level differentiation is whether the CA that mis-issued a cert= ificate did so maliciously or not. If not, then the next point of differentiation is whether the mis-issuance wa= s the result of an accident or an attack. In the case of an attack, it is n= ecessary to consider whether the certificate was logged, and if so, whether= the log conspired with the attacker.

 

If the CA acted maliciously, i= t is necessary to ask whether it logged a mis-issued certificate. If so, th= en one must consider whether the CA conspired with one or more log operators, or conspired with one of more Monitors (fo= r not self-monitoring Subjects).

 

The following sections examine= each of these cases, for both syntactic and semantic mis-issuance. As note= d above, the focus here is on the Web PKI context, although most of the analysis is applicable to other PKI cont= exts.

 

 

XX.1 A non-malicious Web PKI CA

 

If a certificate is submitted = to a log, either prior to issuance (a pre-certificate), or post-issuance, s= yntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in g= eneral, and if the log is capable of performing the checks applicable to th= e submitted (pre-) certificate. A (pre-) certificate will be logged even if= it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance. If= syntactic validation fails, this will be noted in the SCT returned to the = CA, and because the CA is non-malicious, it will remedy the syntactic probl= em and re-submit the (pre-) certificate to a log again.

 

Thus syntactic mis-issuance ca= n be avoided by a CA if it makes use of logs that are capable of performing= these checks for the types of certificates that are submitted, assuming that it acts on the feedback it receives. If = a CA uses a log that does not perform such checks, or if the CA requests ch= ecking relative to criteria not supported by the log, then syntactic mis-is= suance will not be detected.

 

XX.1.1 A CA may issue the certificate to an unauthorize= d party (semantic mis-issuance), as a result of an error or because it was the victim of a social engineering attack. W= e will refer to such a certificate as “bogus”. In this case the= CA has a record of the bogus certificate and it is prepared to revoke the = bogus certificate once it has confirmed its error. If the CA is submitting (pre-) certificates for logging, there will= be evidence of the mis-issuance in one or more logs. If a Monitor is ̶= 0;protecting” the targeted Subject, it will detect the mis-issuance, = and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, afte= r investigating, based on the information provided by the legitimate certif= icate Subject. The presence of an embedded SCT in the bogus certificate, or= an SCT accompanying the bogus certificate is irrelevant to the mitigation procedure in this case. (See Note 1 below.= ) Because the mis-issuance was not malicious, there is no notion of a log o= perator or a Monitor conspiring with the CA.

 

XX.1.2 A non-malicious Web PKI CA may be the victim of = an undetected attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a certificate. In this case the = CA is not aware of the mis-issuance and may have no record of the certifica= te content.

 

XX.1.2.1 The mis-issued certificate may have been submi= tted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. = In either case, a Monitor that is protecting the targeted Subject will dete= ct the bogus certificate and alert it. The Subject, in turn, will request t= he CA to revoke the bogus certificate. In this case, the CA will make use of the log entry (supplied by the Subje= ct) to determine the serial number of the mis-issued certificate, and revok= e it (after investigation). (See Notes 1 + 2.) If TLS clients reject a = certificate when no SCT is provided, this might motivate the attacker to log the bogus certificates, which help= s justify such client behavior. (See Note 3.)

 

XX.1.2.2 The bogus certificate may not have been submit= ted to any logs. In this case, Monitors will not detect the bogus certificate. If TLS clients reject a certificate= that lacks (or is not accompanied by) an SCT, the attacker will be thwarte= d in this case. (See Note 3.)

 

XX.1.2.3 The bogus certificate= may have been submitted to logs that are conspiring with the attacker. In = this case, Monitors will not detect the bogus certificate because the logs will suppress a bogus certificate log e= ntry. TLS clients will not reject a bogus certificate in this case, because= it is accompanied by an SCT. In this scenario, unless Monitors or Auditors= “gossip” to detect conspiring logs, the bogus certificate will not be detected.

 

 

XX.2 A Malicious Web PKI CA

 

XX.2.1 If a (pre-) certificate is submitted to a (non-c= onspiring) log, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntacti= c checks in general, and if the log is capable of performing the checks app= licable to the submitted certificate. A (pre-) certificate will be logged e= ven if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance.

 

Because the CA is presumed to = be malicious, the CA may cause the log to not perform checks, in one of two= ways. The CA may assert that the certificate is being issued w/o regard to any guidelines (the “no guidelinesR= 21; reserved CCID), or it may assert a CCID that has not been registered. I= n this fashion the CA can prevent the log from performing checks, and the S= CT and log entry will not contain an indication of a failed check. Alternatively, the CA may submit a (pre-) certificate t= o a log that is known to not perform syntactic checks, and thus avoid synta= ctic checking.

 

If a client rejects a certific= ate that has not been syntactically checked (as indicated by the SCT), the = first approach to subverting syntax checking will fail. If a client rejects a certificate that was logged by an operato= r that does not perform syntactic checks, the third approach noted above wi= ll fail. If a client is configured to know which versions of CABF guideline= s exist, the second approach to avoiding syntactic checking also can be thwarted.

 

XX.2.2 Because the CA is presumed malicious, it may cho= ose to not submit a certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also mean= s there is no SCT for the certificate. If clients reject a certificate that= lacks (or is not accompanied by) an SCT, this form of mis-issuance will be= thwarted in this case. (See Note 3.)

 

XX.2.3 A malicious CA may submit a certificate to one o= r more logs that collude with this CA to not perform syntactic checks, even though they claim to do so. In this cas= e the syntactic mis-issuance will not be detected by logs.  The log en= try and the SCT for a syntactically invalid certificate will assert that th= e certificate syntax was verified. Unless Monitors also perform syntactic checks, this form of mis-issuance will not= be thwarted in this case. TLS clients will believe that the certificate ha= s been syntactically verified.

 

XX.2.4 A malicious CA may semantically mis-issue a cert= ificate that is syntactically valid. Because it is syntactically valid, logs will not reject the bogus certificate. Thi= s situation might result because the CA was bribed or was compelled to issu= e the bogus certificate. A CA might be compelled to issue a bogus certifica= te by a government agency or a criminal organization.  This CA might be one or more tiers below a trust ancho= r (aka root CA).

 

XX.2.4.1 A bogus certificate may not have been submitte= d to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lac= ks (or is not accompanied by) an SCT, the attacker will be thwarted in this= case. (See Note 3.)

 

XX.2.4.2 A bogus certificate may have been submitted to= one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In= either case, a Monitor protecting the targeted Subject will detect a bogus= certificate and alert the targeted subject. The Subject, in turn, will req= uest the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to r= evoke the bogus certificate. It could make excuses about inadequate proof t= hat the certificate is bogus, or argue that it cannot quickly revoke the ce= rtificate because of local, legal concerns, etc. In this case, the CT mechanisms have detected mis-issuance,= but the information logged by CT does not help remedy the problem. (See No= te 4.)

 

XX.2.5 A bogus certificate may have been submitted to o= ne or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any M= onitor from which the log is hiding data will not detect the bogus certific= ate, even if it is trying to protect the targeted Subject. If a client acce= pts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a mi= ssing SCT. In this case CT will not detect the semantically mis-issued cert= ificate.

 

Auditors are intended to detec= t logs that conspire to suppress log entries, based on consistency checking= of logs and use of a “gossip” protocol. Until such checks are clearly defined and a gossip protocol is defined and= deployed, CT does not provide the necessary info to detect this form of mi= s-issuance.  When Auditors can detect a conspiring log, Monitors and c= lients can be alerted to it (how?). This would cause Monitors to avoid using such a log, and clients would reject S= CTs generated by such a log. (See Note 5 below.)

 

Notes:

 

1. If a CA submits a bogus certific= ate to one or more logs, but these logs are not watched by a Monitor that i= s protecting the targeted Subject, CT will not mitigate this type of mis-is= suance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. = Absent such a guarantee, how do Subjects know which set of Monitors will pr= ovide “sufficient” coverage. If a Subject acts as its own Monit= or, this problem is solved for that Subject. It is not clear how a Monitor becomes aware of all (relevant?) logs, inclu= ding newly added logs. The means by which Monitors become aware of new logs= MUST accommodate self-monitoring by a potentially very large number of web= site operators.

 

2. A CA being presented with eviden= ce of a bogus certificate, in the form of a log entry, will need to examine= its records to determine if it has knowledge of the certificate in questio= n. It also will likely require the targeted Subject to provide assurances that it is the authorized entity re= presenting the Subject name (subjectAltname) in question. Thus a Subject sh= ould not expect immediate revocation of a contested certificate. The time f= rame in which a CA will respond to a revocation request usually is described in the CPS for the CA. Other = certificate fields and extensions may be of interest for forensic purposes,= but are not required to effect revocation nor to verify that the certifica= te to be revoked is bogus, based on applicable criteria. The SCT and log entry, because each contains a tim= estamp from a third party, is probably valuable for forensic purposes (assu= ming a non-conspiring log operator).

 

3. If a TLS client is to reject a c= ertificate that lacks an embedded SCT, or is not accompanied by an SCT tran= sported via the TLS handshake, this behavior needs to be defined in a way t= hat is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, = based on experience with warnings displayed for expired certificates, lack = of certificate revocation status information, and similar errors that viola= te RFC 5280 path validation rules. Until a mechanism is defined that accommodates incremental deployment of t= his capability, attackers should not be expected to submit bogus certificat= es to (non-conspiring) logs.

 

4. A targeted Subject might request= the parent of a malicious CA to revoke the certificate of the non-cooperat= ive CA. However, a request of this sort may be rejected, e.g., because of t= he potential for significant collateral damage. A browser might be configured to reject all certificates issued by= the malicious CA, e.g., using a CA hot list distributed by a browser vendo= r. However, if the malicious CA has a sufficient number of legitimate clien= ts, treating all of them as bogus still represents serious collateral damage. If one can configure a browser= to reject a specific, bogus certificate identified by a Monitor, then the = bogus certificate could be rejected in that fashion. This mitigation strate= gy calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such commu= nication has not been specified, i.e., there [Santosh] (Add “is”= ; here) no standard ways to configure a = browser to reject individual bogus certificates based on info provided by a= Monitor. Moreover, the same or another malicious CA could issue new bogus = certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) = fashion. Thus, for now, CT does not seem to provide a way to mitigate this = form of attack, even though it provides a basis for detecting such attacks.=

 

5. The combination of a malicious C= A and one or more conspiring logs motivates the use of Auditors, to detect = conspiring logs. If a Monitor protecting s Subject does not see mis-issued = certificates, it cannot alert the Subject. If one or more SCTs are present in a certificate, or passed via t= he TLS handshake, a client has no way to know that the logged certificate i= s not visible to Monitors. Only if Monitors and clients reject certificates= that contains SCTs from conspiring logs (based on info from Audotirs) will CT be able to deter use of such lo= gs. Thus the means by which Auditors detect such logs, and inform TLS clien= ts and Monitors must be specified. Moreover, if a certificate (or TLS hands= hake) contains more than one SCT, it appears that the client MUST verify all of them if it is to counter the= threat posed by conspiring logs.

 

Absent a “gossip” = protocol that enables Auditors to verify that data from logs are reported i= n a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be vic= tims of, attackers effecting certificate mis-issuance. When a gossip protoc= ol is defined and deployed, it will be necessary to describe how the CT sys= tem will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TL= S clients to reject SCTs issued by such a log. Absent a description of a mi= tigation strategy to deal with mis-behaving or compromised logs, CT cannot = ensure detection of mis-issuance.

 

Monitors play a critical role in detect= ing semantic certificate mis-issuance, for Subjects that have requested mon= itoring of their certificates. A monitor (including a Subject p= erforming self-monitoring) examines logs for certificates associated with o= ne or more Subjects. It must obtain a list valid certificates for the Subje= ct being monitored, in a secure manner.  A Monitor must not rely on a CA or RA database for this information or use= certificate discovery protocols; this information must be acquired by the = Monitor based on reference certificates [Santosh]  (replace ̶= 0;it” with “subject”) it has obtained and installed.&n= bsp;If a Monitor were to rely on a CA or RA database (for the CA that issue= d a targeted certificate), the Monitor would not detect mis-issuance due to= malfeasance on the part of that CA or the RA, or due to compromise of the CA or the RA.  If a CA or RA= database is used, it does detect mis-issuance by an unauthorized CA. = A Monitor must not rely on certificate discovery mechanisms to build the l= ist of valid certificates since such mechanisms might result in mis-issued certificates being added to the list.

 

Monitors represent another tar= get for adversaries who wish to effect certificate mis-issuance. If a Monit= or is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate t= argeting that Subject. This suggests that a Subject SHOULD request certific= ate monitoring from multiple sources to guard against such failures. Operat= ion of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden = of Monitor operation may be viewed as too great for many web sites, and thu= s this mode of operation ought not be assumed to be universal when evaluati= ng protection against Monitor compromise.

 

Now that certificate pinning h= as been approved as a standard, it is appropriate to factor in its use by T= LS clients. It would appear that pinning will dramatically reduce the set of TLS clients that are vulnerable to mis= -issuance; a client that pins a certificate for a web site would reject a b= ogus certificate even without use of any CT mechanisms. The security consid= erations section of 6962-bis needs to note this, as it suggests that deployment of pinning reduces the need f= or CT.

 

--_000_4262AC0DB9856847A2D00EF817E8113923E418scygexch10cygnaco_-- From nobody Thu Oct 16 08:09:57 2014 Return-Path: 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 3DC361A1B96 for ; Thu, 16 Oct 2014 08:09:50 -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 wtxT6tmmiA-Q for ; Thu, 16 Oct 2014 08:09:49 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7641A1BB1 for ; Thu, 16 Oct 2014 08:09:14 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id n8so2542605qaq.14 for ; Thu, 16 Oct 2014 08:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=oz4ct6EBGNymqka11JP1BUIjPoBfE7Xq0UfdBHaUlSY=; b=HD5kUc6mk6qMYpuRxKt/SZPXACxgj2C/V6YMC2InYSEvSdnFvchhRNDKKYBoZIYO3n YsYujltIh+dYQ2CX/jIB6ZrORu7S95PLwYNNTtaIOmd2TPfBbamcwvpqMC6kX/EiVyyf m+sBkOEm68QjA66ARsiHIyhGADZyF+Ko+QRGPnlJWS4UTDBtAIh0FFFrz+jifHf2LdMD GKqqjI1e/K9qSQJx25CfAQSmBFBB0rQlQGcAJNbGt6MWY7fq7k55y5pO9dZ09h0VeX+K k0hsIXMh4N9YcogJWY9fQs6NnT+OcbOhybkn0lqNmhyMjjAQCEFwh6TXef6xLTbxgJop UsCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=oz4ct6EBGNymqka11JP1BUIjPoBfE7Xq0UfdBHaUlSY=; b=bjxYsgSor67ekw8vUEg3yjcbLGoq6Y5WRwos3InhWU/3RkADAxZI9QxSAA7DW+z45K 1njuTlPgseZOUGsw7CLgDp2CzUbISNogoO5ShRfyBFTHEndkps/3AV4o75bpHRhLGa9z kzKvQQq9hVMZ14JgeUezXdZkkL8alhXoXjl41o4HOT2JsB+qClVqgU2o2QiW64Uehg1N m9s4g6rLm4SfIwayrlPZfVC5Twnco+zrA6U0/NF6TohgKG496lEF0+wO5JptH0uaDI0w UI9EotXyvys2sd1g92ZKVdrzEGgNi9e6cdAgISCABT/a/GzsAUV3+wD1MWuR8MabV1pS ZEQg== X-Gm-Message-State: ALoCoQnt3lcaXO0rlBFfGQdL0PKS46B/H/y6tZbr2tm/Mxshpp0XsLEjB6J/RkgWWEuGlbdRk3aU X-Received: by 10.140.19.107 with SMTP id 98mr2876462qgg.37.1413472153900; Thu, 16 Oct 2014 08:09:13 -0700 (PDT) MIME-Version: 1.0 From: Ben Laurie Date: Thu, 16 Oct 2014 15:09:13 +0000 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11354e4ea24bc905058ba117 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qQm22P-9cLOYvBMjt6Ov-rnxhjA Subject: [Trans] Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:09:50 -0000 --001a11354e4ea24bc905058ba117 Content-Type: text/plain; charset=UTF-8 We (the 6962-bis editors) would like to propose that we replace the existing precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays to rest, we think, any possible confusion with X509v3 certs, whilst allowing a simple mapping between the final cert and the pre-cert. Obviously there are details to be nailed down, but before we do so, we'd like to hear any discussion on the general idea. --001a11354e4ea24bc905058ba117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We (the 6962-bis editors) would like to propose that we replace the existin= g precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays= to rest, we think, any possible confusion with X509v3 certs, whilst allowi= ng a simple mapping between the final cert and the pre-cert.

=
Obviously there are details to be nailed down, but before we do so, we= 'd like to hear any discussion on the general idea.
--001a11354e4ea24bc905058ba117-- From nobody Thu Oct 16 15:41:44 2014 Return-Path: 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 2DCE91A8AA6 for ; Thu, 16 Oct 2014 15:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 K8cnfIgZ9745 for ; Thu, 16 Oct 2014 15:41:40 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689571A88DE for ; Thu, 16 Oct 2014 15:41:40 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so4076526pde.0 for ; Thu, 16 Oct 2014 15:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5o2oSJbRSjWyWopuVhJYF59YsTR+Vh1pNkV9EhDcbA4=; b=gRfVv8faS0iwZp83mVLeryP2R69Q8XXZ4Ndk3oz18/vWhYxvxz0OBQT9sq/Htra03n g4r3FZfTk1XeDjR3jGzuINW2yf9sICeoodsJgN1J/eZLFxnRb8VcFH+90LU0rit4X6VO kNsUNSFWEzwdM6ffTincxKhJa7Mk9aDASm0p5athJR35keKblHDRd0BbjXkIsArMHquX KGshZoxTQOrGi7S8EQ5FUIITLInVE6uv/Uku8s2y7LaVOQSHFy+pQI3668dR9Zh4mV+Z qItwGcU0qczEgzYcHmfthjIPqeEXgSuyyD4RNs/tj3wHcs+S6wqZqyrXxkBVjzUvC5Q/ f67Q== X-Received: by 10.67.13.205 with SMTP id fa13mr4387316pad.118.1413499300088; Thu, 16 Oct 2014 15:41:40 -0700 (PDT) Received: from spandex.local (74-124-98-47-rb2.sol.dsl.dynamic.acsalaska.net. [74.124.98.47]) by mx.google.com with ESMTPSA id uw1sm14303211pab.30.2014.10.16.15.41.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 15:41:39 -0700 (PDT) Message-ID: <544049A1.6010308@gmail.com> Date: Thu, 16 Oct 2014 14:41:37 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: trans@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mpiikTW8uvakFoTQ1KaCfSB0k_I Subject: Re: [Trans] Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:41:42 -0000 On 10/16/14 7:09 AM, Ben Laurie wrote: > We (the 6962-bis editors) would like to propose that we replace the > existing precertificate formats with a TBSCertificate wrapped in PKCS#7. > This lays to rest, we think, any possible confusion with X509v3 certs, > whilst allowing a simple mapping between the final cert and the pre-cert. > > Obviously there are details to be nailed down, but before we do so, we'd > like to hear any discussion on the general idea. Please give this some attention - we've been trying to come to agreement on precertificate format since the working group was chartered, and it will be a glorious day indeed when we can close the ticket. Melinda From nobody Fri Oct 17 05:50:59 2014 Return-Path: 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 D77741ACD52 for ; Fri, 17 Oct 2014 05:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 KlLP3RnCRfRX for ; Fri, 17 Oct 2014 05:50:54 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EE61ACD50 for ; Fri, 17 Oct 2014 05:50:54 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9HCoqFq005920 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Oct 2014 14:50:52 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s9HConqe007386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Oct 2014 12:50:51 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1413550251; bh=gHaAwpqRw1qUrvOpZ0iZo8RV+7vonRYu1LTbv57ne6A=; h=From:To:Subject:Date; b=IujsRCmUfO9EHUz17xbL2a6n5Q6O5tdAjwljsQGg+Uz4cILjv1T+xcxpyreVjC6do RllCAnd3T1Sx0DoX0gbKp3G0NBrXe1PyyfyCHIKg04c02gzIS7jYlDy6i/1/FUWbs8 nZ+wXvo2wyaODux9aQ37VrI09yNHjD1i8wkn4mdY= X-Footer: bm9yZHUubmV0 Received: from flogsta.nordberg.se ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) for trans@ietf.org; Fri, 17 Oct 2014 14:50:47 +0200 From: Linus Nordberg To: trans@ietf.org Organization: NORDUnet A/S Date: Fri, 17 Oct 2014 14:51:14 +0200 Message-ID: <871tq6uaf1.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aN4cOQAO - 2241192b0d4b - 20141017 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/J88oQaDA7BR29TcrYjwDpBrEeYI Subject: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 12:50:58 -0000 Hi list, 6962bis-4 says that logs may log and publish invalid certificates as long as the chain ends in a known cert. It then lists three examples of what can be accepted, all related to time. Logs MUST verify that the submitted end-entity certificate or Precertificate has a valid signature chain leading back to a trusted root CA certificate, using the chain of intermediate CA certificates provided by the submitter. Logs MAY accept certificates that have expired, are not yet valid, have been revoked, or are otherwise not fully valid according to X.509 verification rules in order to accommodate quirks of CA certificate-issuing software. However, logs MUST refuse to publish certificates without a valid chain to a known root CA. If a certificate is accepted and an SCT issued, the accepting log MUST store the entire chain used for verification, including the certificate or Precertificate itself and including the root certificate used to verify the chain (even if it was omitted from the submission), and MUST present this chain for auditing upon request. This chain is required to prevent a CA from avoiding blame by logging a partial or empty chain. (Note: This effectively excludes self-signed and DANE-based certificates until some mechanism to limit the submission of spurious certificates is found. The authors welcome suggestions.) Since the purpose of the log is to put light on bad certificates, would it make sense to instead have text 1) specifying a minimum of checks to be done (i.e. the chain) and 2) encouraging logging and publishing of all other certificates? On a minor note, I think that "trusted" in the very first sentence should be changed to "known. Should I use the issue tracker? From nobody Fri Oct 17 16:44:06 2014 Return-Path: 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 2B0DC1A8758 for ; Fri, 17 Oct 2014 16:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OU2YdY6CSjtg for ; Fri, 17 Oct 2014 16:44:04 -0700 (PDT) Received: from mail.hezmatt.org (sasquatch.hezmatt.org [70.85.129.92]) by ietfa.amsl.com (Postfix) with ESMTP id EAADE1A8755 for ; Fri, 17 Oct 2014 16:44:03 -0700 (PDT) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id E5513282E37 for ; Sat, 18 Oct 2014 10:44:00 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 1016D9FCFF; Sat, 18 Oct 2014 10:44:00 +1100 (EST) Date: Sat, 18 Oct 2014 10:44:00 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20141017234400.GT9502@hezmatt.org> References: <871tq6uaf1.fsf@nordberg.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871tq6uaf1.fsf@nordberg.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/A-Dj90yggtmW3jmlV6Y6UmUCNxc Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:44:05 -0000 On Fri, Oct 17, 2014 at 02:51:14PM +0200, Linus Nordberg wrote: > 6962bis-4 says that logs may log and publish invalid certificates as > long as the chain ends in a known cert. It then lists three examples of > what can be accepted, all related to time. [...] > Since the purpose of the log is to put light on bad certificates, would > it make sense to instead have text 1) specifying a minimum of checks to > be done (i.e. the chain) and 2) encouraging logging and publishing of > all other certificates? IMO, yes. My opinion is that a log which rejects certificates for reasons other than those required to maintain the operation of the log (ie spamming) is worthless -- you're *not* getting a complete view of what a CA intended to issue, you're getting some sort of filtered, sanitised view of it. > On a minor note, I think that "trusted" in the very first sentence > should be changed to "known. Should I use the issue tracker? I've been advised that for small, non-controversial changes, submitting a pull request direct to the github repo is fine. - Matt From nobody Fri Oct 17 18:01:03 2014 Return-Path: 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 68DEB1A000B for ; Fri, 17 Oct 2014 18:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 c4FmMDqFuED3 for ; Fri, 17 Oct 2014 18:01:01 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DBE1A0006 for ; Fri, 17 Oct 2014 18:01:01 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id rd3so1754665pab.34 for ; Fri, 17 Oct 2014 18:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zyRsfL80alK5eF1/0V6Q5i0YcOOj/hgFkgA8Yxt4rXM=; b=W+YysjIBCTaoU0cmkC3vG6hRx0tDEUBg619RpUnSP3hDg/Rp9zV8YAb+Uq4Q8Jxt/g 5H2VnRjROU6+hlQijQ2ZxESUjnioNQx3JQlZV47OSTEWaNTms8l2QxTz7yeCMumiUhFG 751p3cC4vL6CwI2RO23gqHYVUY4wq9HMaXXymdKh3QAZLqBRzASmX9bisZ91KC4cRKUo hovxP1pwC5vxdT0yPQAx9At/D8e8v0P1B6rDJ/yqXyfBL0TnxiOao+2yC9YWrbdQbDJ7 jSaPOwUwxAELIKo05vux8DgbxP1e40zsNw4nR2BvED6SeNnFxTuYLW/cJJTQm2LPWKnZ +Adw== X-Received: by 10.70.93.104 with SMTP id ct8mr12109162pdb.72.1413594060694; Fri, 17 Oct 2014 18:01:00 -0700 (PDT) Received: from spandex.local (74-124-98-47-rb2.sol.dsl.dynamic.acsalaska.net. [74.124.98.47]) by mx.google.com with ESMTPSA id yr3sm2639666pac.1.2014.10.17.18.00.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 18:00:59 -0700 (PDT) Message-ID: <5441BBC9.6060007@gmail.com> Date: Fri, 17 Oct 2014 17:00:57 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wsQY7p3YnM6q1sbyFRQvVqETAIw Subject: [Trans] IETF schedule X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 01:01:02 -0000 In case you've missed it, the final agenda is out: https://datatracker.ietf.org/meeting/91/agenda.html We're meeting on Monday afternoon from 3:20 to 6:30. Melinda From nobody Sat Oct 18 05:22:22 2014 Return-Path: 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 200011A6FF4 for ; Sat, 18 Oct 2014 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 dR2Hxqe9Djha for ; Sat, 18 Oct 2014 05:22:18 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663051A6FEE for ; Sat, 18 Oct 2014 05:22:18 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9ICM5tE024443 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Oct 2014 14:22:05 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s9ICLvk8018856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Oct 2014 12:22:00 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1413634925; bh=9Emze6XTcaJxwpcmIvwDC8MJowNlkpWVB1fX83hfu68=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=bFGae0g/korzdkMv8Qfk4jMj53fCO5s9oIrbYUUgzi+23bOmFFJyYYCPLZ7hztdXY VPEb7v7h6PPjlIbqp+iOSeLGlmn0QJQoQTgw9dnYHwZGd2g6LgGHAIwA2qNzCK/59P wn8LPdZCQiJN9QY2qgWlGTZnfBZDzl7e+Bn1kryo= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 18 Oct 2014 14:21:57 +0200 From: Linus Nordberg To: Matt Palmer Organization: NORDUnet A/S References: <871tq6uaf1.fsf@nordberg.se> <20141017234400.GT9502@hezmatt.org> Date: Sat, 18 Oct 2014 14:22:22 +0200 In-Reply-To: <20141017234400.GT9502@hezmatt.org> (Matt Palmer's message of "Sat, 18 Oct 2014 10:44:00 +1100") Message-ID: <87y4sdmutd.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aN4Am59k - 425ea6254b3a - 20141018 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YC1Msgqx7-Se_Bu_6NJlpWbGnsA Cc: trans@ietf.org Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 12:22:20 -0000 Matt Palmer wrote Sat, 18 Oct 2014 10:44:00 +1100: | > Since the purpose of the log is to put light on bad certificates, would | > it make sense to instead have text 1) specifying a minimum of checks to | > be done (i.e. the chain) and 2) encouraging logging and publishing of | > all other certificates? | | IMO, yes. My opinion is that a log which rejects certificates for reasons | other than those required to maintain the operation of the log (ie spamming) | is worthless -- you're *not* getting a complete view of what a CA intended | to issue, you're getting some sort of filtered, sanitised view of it. Thanks, this is my view as well. Happy to try to provide text unless other people on the list have a good case against this. | > On a minor note, I think that "trusted" in the very first sentence | > should be changed to "known. Should I use the issue tracker? | | I've been advised that for small, non-controversial changes, submitting a | pull request direct to the github repo is fine. Thanks, did that. From nobody Mon Oct 20 05:09:54 2014 Return-Path: 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 1FFC61A7113 for ; Mon, 20 Oct 2014 05:09:52 -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 N-wnRbEpOwbP for ; Mon, 20 Oct 2014 05:09:50 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023E71A7D80 for ; Mon, 20 Oct 2014 05:09:49 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id b13so3943474qcw.34 for ; Mon, 20 Oct 2014 05:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=pTVXkNGnuomvIAJGENNeMES8O8QCsXhGCjf8NgKGRdc=; b=YkY/4p5Bg+9BcMWVovyYos6LMNV3KlUx2z0APlt08p06by+A3cn4tCoPxajOgxypUu HT6kUNTYMIHRlTno9NUfo6T0tGdrIPXBIPpwbyOe4EZ21Zbmf89h2Cl9mj7WpNA2cL/I +l8P8Esr/wOMV5GLyXI7ovpxfK+qlGKS2vNrwULqPG595BKzIIDGmu894DZP3YU/2FQP uo6CQI48eGKpELTEozqHwC97a7p3ir0xY6sUQ77DJtLo09jgvx42hFTstudwaqLv73WX CD4DOLtwEAc4LK3NMAWWBfyzUhZyyNVXzJ/bKQLcmLVJll2Uur6Qo21FuzBkG+b9uFcA Vo1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=pTVXkNGnuomvIAJGENNeMES8O8QCsXhGCjf8NgKGRdc=; b=SVFbOVwqts2Hi1Yg0mjWKsVm7cOwgMlc0qhnT+4t32YWboXDCDrp7bNjCBSKcusqKm W8f5mjpui8f7zqYMWRgXLuHYDWX2Br3Zr2JJ+q3MGW6ZbTSpDnpQek/mwYOp1QWcQG3U PMSkLNwpWyB9NSO2kR/weptpUbnAO7X4RTc+kK9E/aL30JhJ7B3B0jpaYmnQj5jDTK+G AHB7x8n87LnWZagzgxTpcU8z2lRVUO73Xpee5Y2cpkas7/u8jkWraPt4XtWK2AAfcInt DoNfN+NDWLXRke3lrnK0bt7laLTDHcCv1c5ckc2vhATgAPT/Vkbt6kNNJKrJC2wyQJ6Q BJOQ== X-Gm-Message-State: ALoCoQnPd8IRCgCXg851fhHH/iP1gSOpXs/AKkaT5/nCgX+8TJAOAhYU4W2D49SMWIbaf2jFWOa2 X-Received: by 10.140.104.200 with SMTP id a66mr19346556qgf.37.1413806989153; Mon, 20 Oct 2014 05:09:49 -0700 (PDT) MIME-Version: 1.0 References: <871tq6uaf1.fsf@nordberg.se> From: Ben Laurie Date: Mon, 20 Oct 2014 12:09:48 +0000 Message-ID: To: Linus Nordberg , trans@ietf.org Content-Type: multipart/alternative; boundary=001a1135339a5eb1690505d9970b Archived-At: http://mailarchive.ietf.org/arch/msg/trans/SFRWze_ARqrNQ8h_5iBElhCezCI Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:09:52 -0000 --001a1135339a5eb1690505d9970b Content-Type: text/plain; charset=UTF-8 On Fri Oct 17 2014 at 1:51:01 PM Linus Nordberg wrote: > Hi list, > > 6962bis-4 says that logs may log and publish invalid certificates as > long as the chain ends in a known cert. It then lists three examples of > what can be accepted, all related to time. > > Logs MUST verify that the submitted end-entity certificate or > Precertificate has a valid signature chain leading back to a trusted > root CA certificate, using the chain of intermediate CA certificates > provided by the submitter. Logs MAY accept certificates that have > expired, are not yet valid, have been revoked, or are otherwise not > fully valid according to X.509 verification rules in order to > accommodate quirks of CA certificate-issuing software. However, logs > MUST refuse to publish certificates without a valid chain to a known > root CA. If a certificate is accepted and an SCT issued, the > accepting log MUST store the entire chain used for verification, > including the certificate or Precertificate itself and including the > root certificate used to verify the chain (even if it was omitted > from the submission), and MUST present this chain for auditing upon > request. This chain is required to prevent a CA from avoiding blame > by logging a partial or empty chain. (Note: This effectively > excludes self-signed and DANE-based certificates until some mechanism > to limit the submission of spurious certificates is found. The > authors welcome suggestions.) > > Since the purpose of the log is to put light on bad certificates, would > it make sense to instead have text 1) specifying a minimum of checks to > be done (i.e. the chain) Since checking is for spam limitation, and different logs may have different views on what is spam, I am not convinced this is a good idea - for example, any chain check would appear to automatically rule out logging self-signed certs, and it seems to me that should be left open to log operators to think about (e.g. Microsoft would appear to have sufficient information to do spam limitation through use measurement: http://blogs.technet.com/b/pki/archive/2014/02/22/a-novel-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx ) > and 2) encouraging logging and publishing of > all other certificates? > That seems like a good plan :-) > > > On a minor note, I think that "trusted" in the very first sentence > should be changed to "known. Should I use the issue tracker? > Yes, please. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1135339a5eb1690505d9970b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri Oct 17 2014 at 1:51:01 PM Linus N= ordberg <linus@nordu.net> wrot= e:
Hi list,

6962bis-4 says that logs may log and publish invalid certificates as
long as the chain ends in a known cert. It then lists three examples of
what can be accepted, all related to time.

=C2=A0 =C2=A0Logs MUST verify that the submitted end-entity certificate or<= br> =C2=A0 =C2=A0Precertificate has a valid signature chain leading back to a t= rusted
=C2=A0 =C2=A0root CA certificate, using the chain of intermediate CA certif= icates
=C2=A0 =C2=A0provided by the submitter.=C2=A0 Logs MAY accept certificates = that have
=C2=A0 =C2=A0expired, are not yet valid, have been revoked, or are otherwis= e not
=C2=A0 =C2=A0fully valid according to X.509 verification rules in order to<= br> =C2=A0 =C2=A0accommodate quirks of CA certificate-issuing software.=C2=A0 H= owever, logs
=C2=A0 =C2=A0MUST refuse to publish certificates without a valid chain to a= known
=C2=A0 =C2=A0root CA.=C2=A0 If a certificate is accepted and an SCT issued,= the
=C2=A0 =C2=A0accepting log MUST store the entire chain used for verificatio= n,
=C2=A0 =C2=A0including the certificate or Precertificate itself and includi= ng the
=C2=A0 =C2=A0root certificate used to verify the chain (even if it was omit= ted
=C2=A0 =C2=A0from the submission), and MUST present this chain for auditing= upon
=C2=A0 =C2=A0request.=C2=A0 This chain is required to prevent a CA from avo= iding blame
=C2=A0 =C2=A0by logging a partial or empty chain.=C2=A0 (Note: This effecti= vely
=C2=A0 =C2=A0excludes self-signed and DANE-based certificates until some me= chanism
=C2=A0 =C2=A0to limit the submission of spurious certificates is found.=C2= =A0 The
=C2=A0 =C2=A0authors welcome suggestions.)

Since the purpose of the log is to put light on bad certificates, would
it make sense to instead have text 1) specifying a minimum of checks to
be done (i.e. the chain)

Since checking is = for spam limitation, and different logs may have different views on what is= spam, I am not convinced this is a good idea - for example, any chain chec= k would appear to automatically rule out logging self-signed certs, and it = seems to me that should be left open to log operators to think about (e.g. = Microsoft would appear to have sufficient information to do spam limitation= through use measurement:=C2=A0http://blogs.technet.com/b/pki/archive/2014/02/22/a-nov= el-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx= )
=C2=A0
and 2) encourag= ing logging and publishing of
all other certificates?

That seems like= a good plan :-)
=C2=A0


On a minor note, I think that "trusted" in the very first sentenc= e
should be changed to "known. Should I use the issue tracker?

Yes, please.
=C2=A0

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans
--001a1135339a5eb1690505d9970b-- From nobody Mon Oct 20 05:32:09 2014 Return-Path: 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 896C81A8028 for ; Mon, 20 Oct 2014 05:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.028 X-Spam-Level: * X-Spam-Status: No, score=1.028 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 Gv3WxRqtDLZl for ; Mon, 20 Oct 2014 05:32:05 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79891A0127 for ; Mon, 20 Oct 2014 05:32:04 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9KCW1CI012923 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 14:32:01 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s9KCVvVr018003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 12:32:00 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1413808320; bh=1AfjqcNm2FfzXpQQAHQsG/aAYQ+3LHeR7JTAruTDUPM=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=s0SoReBX2/Z9cYTv5DXS3l4n96okSSuKX2Q9sqkdZZMihAg4LC8PpBSTPknHmQI8l 5i6aNrOYFWrhnR/oBtsRLqKlEPflq/qw/Scgpar1WcqmoKeFEqomCMUU25wvBfrsGw 2G81PQU0h7h6anv7Pnbfl9jbDZ9SGPAS9aUoZUTg= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 20 Oct 2014 14:31:56 +0200 From: Linus Nordberg To: Ben Laurie Organization: NORDUnet A/S References: <871tq6uaf1.fsf@nordberg.se> Date: Mon, 20 Oct 2014 14:32:24 +0200 In-Reply-To: (Ben Laurie's message of "Mon, 20 Oct 2014 12:09:48 +0000") Message-ID: <87ppdmhqg7.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aN5ow1VF - 4c142f364231 - 20141020 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/oVrceCHh7V2VyRnWsxXKWveXyxU Cc: trans@ietf.org Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:32:07 -0000 Ben Laurie wrote Mon, 20 Oct 2014 12:09:48 +0000: | On Fri Oct 17 2014 at 1:51:01 PM Linus Nordberg wrote: | | > Hi list, | > | > 6962bis-4 says that logs may log and publish invalid certificates as | > long as the chain ends in a known cert. It then lists three examples of | > what can be accepted, all related to time. | > | > Logs MUST verify that the submitted end-entity certificate or | > Precertificate has a valid signature chain leading back to a trusted | > root CA certificate, using the chain of intermediate CA certificates | > provided by the submitter. Logs MAY accept certificates that have | > expired, are not yet valid, have been revoked, or are otherwise not | > fully valid according to X.509 verification rules in order to | > accommodate quirks of CA certificate-issuing software. However, logs | > MUST refuse to publish certificates without a valid chain to a known | > root CA. If a certificate is accepted and an SCT issued, the | > accepting log MUST store the entire chain used for verification, | > including the certificate or Precertificate itself and including the | > root certificate used to verify the chain (even if it was omitted | > from the submission), and MUST present this chain for auditing upon | > request. This chain is required to prevent a CA from avoiding blame | > by logging a partial or empty chain. (Note: This effectively | > excludes self-signed and DANE-based certificates until some mechanism | > to limit the submission of spurious certificates is found. The | > authors welcome suggestions.) | > | > Since the purpose of the log is to put light on bad certificates, would | > it make sense to instead have text 1) specifying a minimum of checks to | > be done (i.e. the chain) | | | Since checking is for spam limitation, and different logs may have | different views on what is spam, I am not convinced this is a good idea - | for example, any chain check would appear to automatically rule out logging | self-signed certs, and it seems to me that should be left open to log (Depends on how you define "trusted/known root CA certificate", but OK that might be a stretch.) But the current text _does_ require a chain check, doesn't it? Logs MUST verify that the submitted end-entity certificate or Precertificate has a valid signature chain leading back to a trusted root CA certificate, using the chain of intermediate CA certificates provided by the submitter. and However, logs MUST refuse to publish certificates without a valid chain to a known root CA. My intention was to make the specification less restrictive by changing Logs MAY accept certificates that have expired, are not yet valid, have been revoked, or are otherwise not fully valid according to X.509 verification rules in order to accommodate quirks of CA certificate-issuing software. to something indicating that anything more than a chain check is either forbidden or discouraged. | operators to think about (e.g. Microsoft would appear to have sufficient | information to do spam limitation through use measurement: | http://blogs.technet.com/b/pki/archive/2014/02/22/a-novel-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx) | | | > and 2) encouraging logging and publishing of | > all other certificates? | > | | That seems like a good plan :-) | | | > | > | > On a minor note, I think that "trusted" in the very first sentence | > should be changed to "known. Should I use the issue tracker? | > | | Yes, please. Is this the right place? https://github.com/google/certificate-transparency-rfcs/pull/7 From nobody Mon Oct 20 05:43:47 2014 Return-Path: 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 0BA251A8713 for ; Mon, 20 Oct 2014 05:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 0AMlfhg-5ipg for ; Mon, 20 Oct 2014 05:43:44 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0B51A8720 for ; Mon, 20 Oct 2014 05:43:42 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id dc16so3191195qab.39 for ; Mon, 20 Oct 2014 05:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=Rb9j+1u9Pwqmbd9eY3wkeeiJk1q6i2L3vcU1nB/RG3E=; b=FLYFtcSmVrAkxepjnKVnnuyODUFbeG90LZX4xOo4Vxz9uTUF4xsWEyaqDWa1v4hQju ClNBxWcU2fbjQMVvelKO1M6KOf/o6nkVOWARIKjEKVWxbYjBebHK0Z3ED9tclULQO7M7 NP3OEdVedOeJ36ZVJmv8Po1NzJeR1ShqqmQxtn1/Xy8GLITMk+VL209MfqlRetSNtyd0 TjXNQzt+nVHSxxtq0e9JtXbwBqNXC2ZwiUYDMcBVmf3YSed2MVZSyHmelF62BkgeQLez 8mGaJhtE/f/J4udYI+BHenVW61+srSyHPZZkoix2hwYVOUzHutzl9nx2SyB/GhRSfWSH 2W+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-type; bh=Rb9j+1u9Pwqmbd9eY3wkeeiJk1q6i2L3vcU1nB/RG3E=; b=CRmbPAZ/c37u4snGKXW4SSIUmpl0St74XyiYKef5NYCH0/ZFWmhPtQZzZ5xn9KLMy/ OMiXVOJNloEEhdJgP+W1KjZbYE2WxkpPy+Y8ZBOYTjfX2D3ygntQN8X4XYq5+UGicxK8 ev05eUrwtMAOCc7trMcIv+Umf7PzsUaYrKqYkgvpNVs6dFawaFXKHUlS3joVAr4NMp8i qm9WPeetPK3/oYvSqGtTsls0afSsX+6iUhLasmD8g7YOeIVkr5al4iMpq+6WwoHpknqX hvNQxScEpN7he9Jn2VUaJSCapAI0a/psCWa5dueuM92BxcaZGyQ1siuzD4pTo3f2Z7i3 r5DA== X-Gm-Message-State: ALoCoQlGi+S4a3vIwOSMOVo05kFZmtY38/+2uupa0dGkUyn39qvQh+yk9xD92ZY00hIMfFIKIYvI X-Received: by 10.229.40.71 with SMTP id j7mr35229543qce.21.1413809019977; Mon, 20 Oct 2014 05:43:39 -0700 (PDT) MIME-Version: 1.0 References: <871tq6uaf1.fsf@nordberg.se> <87ppdmhqg7.fsf@nordberg.se> From: Ben Laurie Date: Mon, 20 Oct 2014 12:43:39 +0000 Message-ID: To: Linus Nordberg Content-Type: multipart/alternative; boundary=001a1133b8cc6aaa6b0505da101c Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3Fly0yUPCn9VlP9-IlYGEv2Szes Cc: trans@ietf.org Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:43:46 -0000 --001a1133b8cc6aaa6b0505da101c Content-Type: text/plain; charset=UTF-8 On Mon Oct 20 2014 at 1:32:02 PM Linus Nordberg wrote: > Ben Laurie wrote > Mon, 20 Oct 2014 12:09:48 +0000: > > | On Fri Oct 17 2014 at 1:51:01 PM Linus Nordberg wrote: > | > | > Hi list, > | > > | > 6962bis-4 says that logs may log and publish invalid certificates as > | > long as the chain ends in a known cert. It then lists three examples of > | > what can be accepted, all related to time. > | > > | > Logs MUST verify that the submitted end-entity certificate or > | > Precertificate has a valid signature chain leading back to a trusted > | > root CA certificate, using the chain of intermediate CA certificates > | > provided by the submitter. Logs MAY accept certificates that have > | > expired, are not yet valid, have been revoked, or are otherwise not > | > fully valid according to X.509 verification rules in order to > | > accommodate quirks of CA certificate-issuing software. However, > logs > | > MUST refuse to publish certificates without a valid chain to a known > | > root CA. If a certificate is accepted and an SCT issued, the > | > accepting log MUST store the entire chain used for verification, > | > including the certificate or Precertificate itself and including the > | > root certificate used to verify the chain (even if it was omitted > | > from the submission), and MUST present this chain for auditing upon > | > request. This chain is required to prevent a CA from avoiding blame > | > by logging a partial or empty chain. (Note: This effectively > | > excludes self-signed and DANE-based certificates until some > mechanism > | > to limit the submission of spurious certificates is found. The > | > authors welcome suggestions.) > | > > | > Since the purpose of the log is to put light on bad certificates, would > | > it make sense to instead have text 1) specifying a minimum of checks to > | > be done (i.e. the chain) > | > | > | Since checking is for spam limitation, and different logs may have > | different views on what is spam, I am not convinced this is a good idea - > | for example, any chain check would appear to automatically rule out > logging > | self-signed certs, and it seems to me that should be left open to log > > (Depends on how you define "trusted/known root CA certificate", but OK > that might be a stretch.) > > But the current text _does_ require a chain check, doesn't it? > Yes. This may be a bug. :-) However, you should probably look at the archives, there's been considerable debate around checking! > Logs MUST verify that the submitted end-entity certificate or > Precertificate has a valid signature chain leading back to a trusted > root CA certificate, using the chain of intermediate CA certificates > provided by the submitter. > > and > > However, logs > MUST refuse to publish certificates without a valid chain to a known > root CA. > > My intention was to make the specification less restrictive by changing > > Logs MAY accept certificates that have > expired, are not yet valid, have been revoked, or are otherwise not > fully valid according to X.509 verification rules in order to > accommodate quirks of CA certificate-issuing software. > > to something indicating that anything more than a chain check is either > forbidden or discouraged. > > > | operators to think about (e.g. Microsoft would appear to have sufficient > | information to do spam limitation through use measurement: > | http://blogs.technet.com/b/pki/archive/2014/02/22/a- > novel-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx > ) > | > | > | > and 2) encouraging logging and publishing of > | > all other certificates? > | > > | > | That seems like a good plan :-) > | > | > | > > | > > | > On a minor note, I think that "trusted" in the very first sentence > | > should be changed to "known. Should I use the issue tracker? > | > > | > | Yes, please. > > Is this the right place? > https://github.com/google/certificate-transparency-rfcs/pull/7 > > --001a1133b8cc6aaa6b0505da101c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon Oct 20 2014 at 1:32:02 PM Linus N= ordberg <linus@nordu.net> wrot= e:
Ben Laurie <benl@google.com> wrote
Mon, 20 Oct 2014 12:09:48 +0000:

| On Fri Oct 17 2014 at 1:51:01 PM Linus Nordberg <linus@nordu.net> wrote:
|
| > Hi list,
| >
| > 6962bis-4 says that logs may log and publish invalid certificates as=
| > long as the chain ends in a known cert. It then lists three examples= of
| > what can be accepted, all related to time.
| >
| >=C2=A0 =C2=A0 Logs MUST verify that the submitted end-entity certific= ate or
| >=C2=A0 =C2=A0 Precertificate has a valid signature chain leading back= to a trusted
| >=C2=A0 =C2=A0 root CA certificate, using the chain of intermediate CA= certificates
| >=C2=A0 =C2=A0 provided by the submitter.=C2=A0 Logs MAY accept certif= icates that have
| >=C2=A0 =C2=A0 expired, are not yet valid, have been revoked, or are o= therwise not
| >=C2=A0 =C2=A0 fully valid according to X.509 verification rules in or= der to
| >=C2=A0 =C2=A0 accommodate quirks of CA certificate-issuing software.= =C2=A0 However, logs
| >=C2=A0 =C2=A0 MUST refuse to publish certificates without a valid cha= in to a known
| >=C2=A0 =C2=A0 root CA.=C2=A0 If a certificate is accepted and an SCT = issued, the
| >=C2=A0 =C2=A0 accepting log MUST store the entire chain used for veri= fication,
| >=C2=A0 =C2=A0 including the certificate or Precertificate itself and = including the
| >=C2=A0 =C2=A0 root certificate used to verify the chain (even if it w= as omitted
| >=C2=A0 =C2=A0 from the submission), and MUST present this chain for a= uditing upon
| >=C2=A0 =C2=A0 request.=C2=A0 This chain is required to prevent a CA f= rom avoiding blame
| >=C2=A0 =C2=A0 by logging a partial or empty chain.=C2=A0 (Note: This = effectively
| >=C2=A0 =C2=A0 excludes self-signed and DANE-based certificates until = some mechanism
| >=C2=A0 =C2=A0 to limit the submission of spurious certificates is fou= nd.=C2=A0 The
| >=C2=A0 =C2=A0 authors welcome suggestions.)
| >
| > Since the purpose of the log is to put light on bad certificates, wo= uld
| > it make sense to instead have text 1) specifying a minimum of checks= to
| > be done (i.e. the chain)
|
|
| Since checking is for spam limitation, and different logs may have
| different views on what is spam, I am not convinced this is a good idea -=
| for example, any chain check would appear to automatically rule out loggi= ng
| self-signed certs, and it seems to me that should be left open to log

(Depends on how you define "trusted/known root CA certificate", b= ut OK
that might be a stretch.)

But the current text _does_ require a chain check, doesn't it?

Yes. This may be a bug. :-)

However, you should probably look at the archives, there's been c= onsiderable debate around checking!=C2=A0


=C2=A0 =C2=A0Logs MUST verify that the submitted end-entity certificate or<= br> =C2=A0 =C2=A0Precertificate has a valid signature chain leading back to a t= rusted
=C2=A0 =C2=A0root CA certificate, using the chain of intermediate CA certif= icates
=C2=A0 =C2=A0provided by the submitter.

and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0However, logs=
=C2=A0 =C2=A0MUST refuse to publish certificates without a valid chain to a= known
=C2=A0 =C2=A0root CA.

My intention was to make the specification less restrictive by changing

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Logs MAY accept certificates that hav= e
=C2=A0 =C2=A0expired, are not yet valid, have been revoked, or are otherwis= e not
=C2=A0 =C2=A0fully valid according to X.509 verification rules in order to<= br> =C2=A0 =C2=A0accommodate quirks of CA certificate-issuing software.

to something indicating that anything more than a chain check is either
forbidden or discouraged.


| operators to think about (e.g. Microsoft would appear to have sufficient<= br> | information to do spam limitation through use measurement:
| http://blogs.technet.com/b/pki/archive/2014/02/22/a-= novel-method-in-ie11-for-dealing-with-fraudulent-digital-cert= ificates.aspx)
|
|
| > and 2) encouraging logging and publishing of
| > all other certificates?
| >
|
| That seems like a good plan :-)
|
|
| >
| >
| > On a minor note, I think that "trusted" in the very first = sentence
| > should be changed to "known. Should I use the issue tracker? | >
|
| Yes, please.

Is this the right place?
https://github.com/google/certificate-transparency= -rfcs/pull/7

--001a1133b8cc6aaa6b0505da101c-- From nobody Mon Oct 20 06:39:27 2014 Return-Path: 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 12AC71A8769 for ; Mon, 20 Oct 2014 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 P1Z1i1yk4hat for ; Mon, 20 Oct 2014 06:39:24 -0700 (PDT) Received: from service5.mimecast-offshore.com (service5.mimecast-offshore.com [213.167.75.19]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19591A877F for ; Mon, 20 Oct 2014 06:37:49 -0700 (PDT) Received: from QVGOEX01.qvglobal.local ([fe80::4c66:d515:bd1e:6a22]) by qvgoex01.qvglobal.local ([fe80::4c66:d515:bd1e:6a22%10]) with mapi id 14.03.0181.006; Mon, 20 Oct 2014 10:34:43 -0300 From: Stephen Davidson To: Ben Laurie , "trans@ietf.org" Thread-Topic: [Trans] Precertificate format Thread-Index: AQHP6VLgU6eU5in8gU2ughrEJe66iJw5AnFA Date: Mon, 20 Oct 2014 13:34:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [199.68.195.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01CFEC51.DBCB8CD0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/GmlxjwUiTFa7Uw4pNFrfVMymjYg Subject: Re: [Trans] Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 13:39:26 -0000 ------=_NextPart_000_0014_01CFEC51.DBCB8CD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0015_01CFEC51.DBCB8CD0" ------=_NextPart_001_0015_01CFEC51.DBCB8CD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello: What do you propose re the launch of CT in Chrome? It would be preferable to have the actual CT implementation match the CT standard rather than for CAs to have to rejig the logging later. Kind regards, Stephen From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Thursday, October 16, 2014 12:07 PM To: trans@ietf.org Subject: [Trans] Precertificate format We (the 6962-bis editors) would like to propose that we replace the existing precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays to rest, we think, any possible confusion with X509v3 certs, whilst allowing a simple mapping between the final cert and the pre-cert. Obviously there are details to be nailed down, but before we do so, we'd like to hear any discussion on the general idea. ------=_NextPart_001_0015_01CFEC51.DBCB8CD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello:

 

What do you propose re the launch of CT in Chrome?=C2=A0 It would be = preferable to have the actual CT implementation match the CT standard = rather than for CAs to have to rejig the logging = later.

 

Kind regards,

Stephen

 

 

 

 

From:= = Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben = Laurie
Sent: Thursday, October 16, 2014 12:07 PM
To: = trans@ietf.org
Subject: [Trans] Precertificate = format

 

We (the 6962-bis editors) would like to propose that = we replace the existing precertificate formats with a TBSCertificate = wrapped in PKCS#7. This lays to rest, we think, any possible confusion = with X509v3 certs, whilst allowing a simple mapping between the final = cert and the pre-cert.

 

Obviously there are details to be nailed down, but = before we do so, we'd like to hear any discussion on the general = idea.

------=_NextPart_001_0015_01CFEC51.DBCB8CD0-- ------=_NextPart_000_0014_01CFEC51.DBCB8CD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRhzCCBV4w ggRGoAMCAQICBEIf1bMwDQYJKoZIhvcNAQEFBQAwfzELMAkGA1UEBhMCQk0xGTAXBgNVBAoTEFF1 b1ZhZGlzIExpbWl0ZWQxJTAjBgNVBAsTHFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxLjAs BgNVBAMTJVF1b1ZhZGlzIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTAwNDA4MTMw OTA1WhcNMjAwNDA4MTMwOTA1WjBzMQswCQYDVQQGEwJCTTEZMBcGA1UEChMQUXVvVmFkaXMgTGlt aXRlZDEoMCYGA1UECxMfSXNzdWluZyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEfMB0GA1UEAxMW UXVvVmFkaXMgSXNzdWluZyBDQSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOwO R7Lqg0CHZ7zXHFGKs6orQHPkVKGhkDkOViIPlyyFU0fDOF6zvlNS4103DmSkrJJLxMTIOVfAKuia 6luSFJPvpc7wG/Y+wx1VlDTGXKH48pAMm4BnjJgA6AMUkIA7zsyXCVma+3xtE0PscaNW9gKp8Ds+ fTxbYA0MhjFruwBvnrBkhlQeCWJzw9azm8NqzrfIUKqsusLsnEto/lQPAsyaLrDxlAIpTWvc8VCt fmbCPIsHrL1ovrjzbZLsDcjRJfnMUcGFtK5aWuHhwUEHBRN/VTL7RnS1rxDvMkkO0x+DIGts9X1Q tQLO5dKx1+ML3EGXX+1EjBmGk7r189p/oNZXLHgndIXafKRJtAQWkvgmXrkMOjlpfPhMEaDr1DpV pF2TogSCL+ZI220D7TeLdSJOfG6LNX60h7JvC81/o06IwWqlRM8O2mT8EMIi1ChEeKqllAs6IU/h 3N3xujFMlYghlbswK+CLmZ4d3R2qSg7Y8265eGapCljsC/Rxt9yLMrijU/yi1s6EsdWGAFBbmPQo YoM84SmX6m6Ddz6nL8M2WxLTfCWhkNwW30Lm1sFd/J1pkKgApTJ+OJwXm8F6C753pi0tIrwXOzod rD1Doz8V307X07Ye92IGbw+Jz5CA1oqmPd43THYo6ToYIPXpUGWGoATF7kavxgzUWW3vnH/RAgMB AAGjge0wgeowDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwOgYIKwYBBQUHAQEE LjAsMCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC5xdW92YWRpc2dsb2JhbC5jb20wDgYDVR0PAQH/ BAQDAgEGMB8GA1UdIwQYMBaAFItLbe3TKbkGGew5Oanwl4Rqy+/fMDgGA1UdHwQxMC8wLaAroCmG J2h0dHA6Ly9jcmwucXVvdmFkaXNnbG9iYWwuY29tL3F2cmNhLmNybDAdBgNVHQ4EFgQUjY+su1iU N6xpL+HxFqntOUuAtjQwDQYJKoZIhvcNAQEFBQADggEBAGeeDGWXiENoaAEofMiuLPV/RFBgcMjC 7QKi0rdvMi7wA2H79zAEy/VYyXT3G1DpgYbkvENgdM5jWmrcr6iBX/eiG3Tz6Te2YCHOZxDFKxS3 +nZokTZaMH01+ddHf8x9JtsndQLh9InteTlrnqy6A5gGH/ahQrv7COL91CyUTJtIXVpFjXzwP9RH cAk7VN5GIrZ/75CotR16+GvNXKozQU/mNMhuck2wBIC3eeN1MwivJ8I8/9vQjIOXm+xuJC31Tt7d SkKcLewyov7hmAIXFxxSfv5L+dnBOytlYUK7Q+vHGlsjUvLU+S5yjan9n1YYQtC8yYS9u1faIlHa 6nehFDswggXQMIIEuKADAgECAgQ6tlCLMA0GCSqGSIb3DQEBBQUAMH8xCzAJBgNVBAYTAkJNMRkw FwYDVQQKExBRdW9WYWRpcyBMaW1pdGVkMSUwIwYDVQQLExxSb290IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MS4wLAYDVQQDEyVRdW9WYWRpcyBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTAxMDMxOTE4MzMzM1oXDTIxMDMxNzE4MzMzM1owfzELMAkGA1UEBhMCQk0xGTAXBgNVBAoTEFF1 b1ZhZGlzIExpbWl0ZWQxJTAjBgNVBAsTHFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxLjAs BgNVBAMTJVF1b1ZhZGlzIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC/YbWVU7pX/PryZws6Gt8RgGSVtNG8zXrP9imWLiRUQCQ49xqF 3FhMy6QnQpfQn4OKw+QGA1sApVEecAR04sHUOqvXrTsHGAWO/YOs6mbZGBtoivVXGpi69e12PXzZ 3pRqO0sXwdWPvWU4OpXQPVU2Tt95VzEqHthZZUlYIJh+q19+n+nWTeyDdKnHbNjuKUqFKgYU+VTm 09plB4tjNxLX0OzDeyBBRKPty6AX4XFlzh1mMfd2ARnIfQNYtpVJHaYSJujGDHbg42bL6l2mJu7l zF+9Z6cBJw6iylTFsXqVHXEeSimKA9xqRcGkGV5vNs3DorC3/lw44lK8+ERD5pC7AgMBAAGjggJS MIICTjA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHBzOi8vb2NzcC5xdW92YWRpc29m ZnNob3JlLmNvbTAPBgNVHRMBAf8EBTADAQH/MIIBGgYDVR0gBIIBETCCAQ0wggEJBgkrBgEEAb5Y AAEwgfswgdQGCCsGAQUFBwICMIHHGoHEUmVsaWFuY2Ugb24gdGhlIFF1b1ZhZGlzIFJvb3QgQ2Vy dGlmaWNhdGUgYnkgYW55IHBhcnR5IGFzc3VtZXMgYWNjZXB0YW5jZSBvZiB0aGUgdGhlbiBhcHBs aWNhYmxlIHN0YW5kYXJkIHRlcm1zIGFuZCBjb25kaXRpb25zIG9mIHVzZSwgY2VydGlmaWNhdGlv biBwcmFjdGljZXMsIGFuZCB0aGUgUXVvVmFkaXMgQ2VydGlmaWNhdGUgUG9saWN5LjAiBggrBgEF BQcCARYWaHR0cDovL3d3dy5xdW92YWRpcy5ibTAdBgNVHQ4EFgQUi0tt7dMpuQYZ7Dk5qfCXhGrL 798wga4GA1UdIwSBpjCBo4AUi0tt7dMpuQYZ7Dk5qfCXhGrL79+hgYSkgYEwfzELMAkGA1UEBhMC Qk0xGTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxJTAjBgNVBAsTHFJvb3QgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxLjAsBgNVBAMTJVF1b1ZhZGlzIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHmCBDq2UIswDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCK1BS1/vSakqcZ1KR+ chiP2Wh8UiTdZ285esSqXj3iWLBNcJiEYegb42kYDs77R1CgTv/wJB+9ss71J/zsL1Oqc3sDPXRu 5hae66UuxL9WJ1ArYrq+Sxw8VVxBHSS+giBHXdVEfnoWaN99TVFweFcdMx79ApmcDM0KBU/Hu46k dfpKbbGAjglWuZwaYP5dwdd63BF40NZdwbfVrTKZAzqKzFQlOTGBexMiUbpGbKG7nvoEbEkmdI/S c+vMMKLm6lkih/iX9Q796sySpBbEUhjqIc6x8eaEgeW6qYYo8kNaXRKdrB7ZqOUKaqd/oIcpz/KJ TdTsxeLmetA2I4pKdDb5MIIGTTCCBDWgAwIBAgIUAd6jUcVNHdb4/R4NiNJj8cbsSyAwDQYJKoZI hvcNAQEFBQAwczELMAkGA1UEBhMCQk0xGTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxKDAmBgNV BAsTH0lzc3VpbmcgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxHzAdBgNVBAMTFlF1b1ZhZGlzIElz c3VpbmcgQ0EgRzMwHhcNMTMwOTAzMTIzMzIzWhcNMTUwOTE0MDAwMDAwWjBxMQswCQYDVQQGEwJC TTEZMBcGA1UEChMQUXVvVmFkaXMgTGltaXRlZDEZMBcGA1UEAxMQU3RlcGhlbiBEYXZpZHNvbjEs MCoGCSqGSIb3DQEJARYdcy5kYXZpZHNvbkBxdW92YWRpc2dsb2JhbC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCcRl4PI5FLAXfb+NCmuqlh268Xj2nowaNWbycXUanj39Ttp5S+ LddJl4MGn3V8ttRk0RsEpQe1fLlmfxAHpw4pkWCLMVyE1k/pcF4h+tWtH76jvgWdF3ydloQjL/5n aOGHJgqdfiXrdV7aLc7kOBnoLtpl4BYTuK9YN47vdghj7GeI00EeKc3spE64rZEyY3Apik2/Qbi7 DKcbCDhqB+04ywCs+UHf3RHRYuy3LhhcC3H9fPBIyzP3U8pfKUV+aqEXsYvbpJ9C7UfVGn2BYdBA s3NkS51yZIuwGN0+zE+jwdmZSPpNjy7w+rS2hjNaw6Ds+OlN2Elo7oqsViHi7ZfzAgMBAAGjggHZ MIIB1TBWBgNVHREETzBNgR1zLmRhdmlkc29uQHF1b3ZhZGlzZ2xvYmFsLmNvbaAsBgorBgEEAYI3 FAIDoB4MHHNkYXZpZHNvbkBxdW92YWRpc2dsb2JhbC5jb20wcwYIKwYBBQUHAQEEZzBlMCoGCCsG AQUFBzABhh5odHRwOi8vb2NzcC5xdW92YWRpc2dsb2JhbC5jb20wNwYIKwYBBQUHMAKGK2h0dHA6 Ly90cnVzdC5xdW92YWRpc2dsb2JhbC5jb20vcXZpY2FnMy5jcnQwTwYDVR0gBEgwRjBEBgorBgEE Ab5YAYFIMDYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cucXVvdmFkaXNnbG9iYWwuY29tL3JlcG9z aXRvcnkwDgYDVR0PAQH/BAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYB BAGCNxQCAjAfBgNVHSMEGDAWgBSNj6y7WJQ3rGkv4fEWqe05S4C2NDA6BgNVHR8EMzAxMC+gLaAr hilodHRwOi8vY3JsLnF1b3ZhZGlzZ2xvYmFsLmNvbS9xdmljYWczLmNybDAdBgNVHQ4EFgQU3Q2L iC0roY37+vUYurfJ+wzIbF8wDQYJKoZIhvcNAQEFBQADggIBAH7AEsvIT4v/4t9vOXyIyXSfgB+3 57Z+DXrZJxce1ZZlhpc1UYR0vdWHrKlaLasDv5KXFjyNPu7fD7XG3L7TkQpmvEYMWsbrDjP14QL5 JtOec8bqV/QGcW544PGZdAgw8oRLqDDTFnYK/Fz8yUTPVOqp66vczpHtj7HTyBfhw4Kgfnu5KsYC 98CSPhJj6Dp8k/Guoj99DYT5MRKatyrQdAi1j3hFdpxeNwEzdyKM0q0OY4wTcn2zLO16TBr0kOMm HwuPUJyVVzrRmp6YIJbpFDWty9+kx9dVpeQktzW8mSXOtX+c+QKfu+tfPO/hNaHYQIGY/XgVTJZN 5zZsQHzPmMzUZ0OQHnB8BQxjAADJ3+G7zBEG/SxVW1c7A3vK29DTdCfwwLzW7MV8AsbNSJGkOkEC zwrsnu6j6wCkk+XFDBvyToteSue++xdQ4CIeuKZ7iCb46ZuyEecyKIovAuZIhVw/cCO6a+l0U4s0 lkVMuzTuWhhTNY9fcqWyc08WsaPzNpyR1wZqqvql9Am7hbWe/29C6W7ii5EIvEoo+F8sXnpHR7Rj UQ6XZOREwllKpOJ4tK/bhZH8yoJxrHvWJqYAaC3HFm/H4wQ4D7d242JAOsERCLth1nCUieKohBrY 3Xir8ptsgXJ6EmOXkn8LpeWDanp2IZUmIUf7fxROzprWwd5zMYIDsTCCA60CAQEwgYswczELMAkG A1UEBhMCQk0xGTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxKDAmBgNVBAsTH0lzc3VpbmcgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkxHzAdBgNVBAMTFlF1b1ZhZGlzIElzc3VpbmcgQ0EgRzMCFAHe o1HFTR3W+P0eDYjSY/HG7EsgMAkGBSsOAwIaBQCgggH6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTAyMDEzMzczNFowIwYJKoZIhvcNAQkEMRYEFEkQfhk78ub0 6BhLDo/5g+WbftDTMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGcBgkrBgEE AYI3EAQxgY4wgYswczELMAkGA1UEBhMCQk0xGTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxKDAm BgNVBAsTH0lzc3VpbmcgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxHzAdBgNVBAMTFlF1b1ZhZGlz IElzc3VpbmcgQ0EgRzMCFAHeo1HFTR3W+P0eDYjSY/HG7EsgMIGeBgsqhkiG9w0BCRACCzGBjqCB izBzMQswCQYDVQQGEwJCTTEZMBcGA1UEChMQUXVvVmFkaXMgTGltaXRlZDEoMCYGA1UECxMfSXNz dWluZyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEfMB0GA1UEAxMWUXVvVmFkaXMgSXNzdWluZyBD QSBHMwIUAd6jUcVNHdb4/R4NiNJj8cbsSyAwDQYJKoZIhvcNAQEBBQAEggEAHRkqJ8keWFSr1DEk lONvGKjZPSv4NnFgbiCOammNTQNa3KdZZwW8lQplnbjxYw0Xoj2pBSXHkDg8yoxbOQdceRpT6kQI kQeLyLBxpKPnR/t+k5L0i3OEcsFwcLnDePx9O51eRxa3B4UIMnt3qR6Jbef5BgaDaNYKtGpFOYEX wv164FH3LJnBz9BmlyfWE1e416iSL0KrFRXvERPiy2CxYxPalKGB/pBooKZoV/SUKhoUImdZ2oIv U3ZcI5m+/e2fCWM0fXyv653xIhQQhwg7n7J0xVmWQbOBEmUbsqDG8OvDIAFHlmxFcE0NtCShvoio N8gWBvVj9Cg25oCiZmDDQwAAAAAAAA== ------=_NextPart_000_0014_01CFEC51.DBCB8CD0-- From nobody Mon Oct 20 06:43:51 2014 Return-Path: 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 259A01A8733 for ; Mon, 20 Oct 2014 06:43:42 -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 qoWZDoZi3M9h for ; Mon, 20 Oct 2014 06:43:41 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507611A8753 for ; Mon, 20 Oct 2014 06:42:21 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id i13so3370480qae.27 for ; Mon, 20 Oct 2014 06:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=yJkiKFxVyXb+FKegFXq9WSuKcoswrzd28m31gubL63M=; b=RaffFAk1L4IBF17aw87CFLIx6D/blj3CMnaUksn4jF2ABM6zm1YncHRliG9N3Zf2Sp Mwij/bSBAVn94QptnBqesHtQlVC59ARSOMCPc63LYQ5i1l2F84doGdFxSqxoEDrATze1 jiw80ecxN9tRdrHzrkrRBgSf+caAu+GfmhIE5yRa0vNMwjtlVQofKz+KIyTos4cxMQtG 57KvxAh+RMCnGR8ZiTb3M9J/Ud3lZpCGP/rywUfHr2putxRGlzyfCHr4y/3biys4RxNH II9rIEQXiquTuJsrVQ4wmIxdbvptFI9GR/JDpuFuBmlKUsc4Zar0OSvfpPPxooJYjzzT 5ahA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=yJkiKFxVyXb+FKegFXq9WSuKcoswrzd28m31gubL63M=; b=NZV+53R1YL8YdrxiquZHjq5fNit2odPnrT5Vpzm6aguaIFAnJH31aI2MZaQ4HP2cth KI1D8tikG5m//T+G2TX2FIySwrWYJR7Co74aOQzTq/DxQfOBbwje2YA2c8VKJ6faHozZ wia0frN8GH7ZnuM6fE+8lwVxSwzja2LswmxFl/+TCv5jmISd0JdZTtk3xIphgenFG3wZ pJRhfl6JKEIPmutiw6neB/HtZ70fkGWMNrFGkVeA6a08gYbIvZBYoeVQWm86+OExxS/w QU6UNqn59qVAyX3YmHV+9kkTYhbW1WMYgZzA7sUADbkC5wlGp2KmOMUtZtscswJGcRdy 3fTg== X-Gm-Message-State: ALoCoQn51DFzCJJScpvK7BxQi9i26NfMI55xVb2PJIU27GJ1ZXwD7q+X/TuL6SqgP/pkBRymTZVO X-Received: by 10.224.171.194 with SMTP id i2mr35990424qaz.59.1413812540289; Mon, 20 Oct 2014 06:42:20 -0700 (PDT) MIME-Version: 1.0 References: From: Ben Laurie Date: Mon, 20 Oct 2014 13:42:19 +0000 Message-ID: To: Stephen Davidson , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2b2763e6da60505dae286 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ILvbNYD1Wg9yIUG6ZXiKIIq_rG4 Subject: Re: [Trans] Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 13:43:42 -0000 --001a11c2b2763e6da60505dae286 Content-Type: text/plain; charset=UTF-8 On Mon Oct 20 2014 at 2:37:43 PM Stephen Davidson < S.Davidson@quovadisglobal.com> wrote: > Hello: > > > > What do you propose re the launch of CT in Chrome? It would be preferable > to have the actual CT implementation match the CT standard rather than for > CAs to have to rejig the logging later. > The CT launch in Chrome will implement RFC 6962. > > > Kind regards, > > Stephen > > > > > > > > > > *From:* Trans [mailto:trans-bounces@ietf.org] *On Behalf Of *Ben Laurie > *Sent:* Thursday, October 16, 2014 12:07 PM > *To:* trans@ietf.org > *Subject:* [Trans] Precertificate format > > > > We (the 6962-bis editors) would like to propose that we replace the > existing precertificate formats with a TBSCertificate wrapped in PKCS#7. > This lays to rest, we think, any possible confusion with X509v3 certs, > whilst allowing a simple mapping between the final cert and the pre-cert. > > > > Obviously there are details to be nailed down, but before we do so, we'd > like to hear any discussion on the general idea. > --001a11c2b2763e6da60505dae286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon Oct 20 2014 at 2:37:43 PM Stephen= Davidson <S.Davidson@q= uovadisglobal.com> wrote:

Hello:

=C2=A0

What do you propose re the launch of CT = in Chrome?=C2=A0 It would be preferable to have the actual CT implementatio= n match the CT standard rather than for CAs to have to rejig the logging la= ter.

The CT launch in Chrome will i= mplement RFC 6962.
=C2=A0

=C2=A0

Kind regards,

Stephen=

=C2=A0<= /span>

=C2=A0

= =C2=A0

<= u>=C2=A0

From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben La= urie
Sent: Thursday, October 16, 2014 12:07 PM
To: trans@ietf.org
Su= bject: [Trans] Precertificate format

=C2=A0

We (the 6962-bis edito= rs) would like to propose that we replace the existing precertificate forma= ts with a TBSCertificate wrapped in PKCS#7. This lays to rest, we think, an= y possible confusion with X509v3 certs, whilst allowing a simple mapping be= tween the final cert and the pre-cert.

=C2=A0

Obviousl= y there are details to be nailed down, but before we do so, we'd like t= o hear any discussion on the general idea.

--001a11c2b2763e6da60505dae286-- From nobody Mon Oct 20 06:44:07 2014 Return-Path: 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 AA4291A876B for ; Mon, 20 Oct 2014 06:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xTMVGlv_mgqL for ; Mon, 20 Oct 2014 06:43:51 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731051A877E for ; Mon, 20 Oct 2014 06:42:35 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id la4so3577057vcb.27 for ; Mon, 20 Oct 2014 06:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=e8Zx0HsGOl2N64uruf88FZfvLOOwHCkIKQ4JMQtfvtg=; b=jaTdorD18Txb7Jk5DHeXMB+V3UDmLC+p1hm1iAg4vcoo70+tBloAiYaywSX/Mzd1JK QyKMir1RobGBmU8idWFHLMnHW5jDecMk+bZrW7PjiQAvqjl4XXM7PEVnrTWtkpPEX8pQ 9xMqyMdFLDzsnTlotmXRjsQYNK2W/VuF2XHrtziTzNdREtH1xOLDukwbW7r6zI2jqKeC VzYYYCUnLCPCzOdbhJYh5E/Ugtro3/uUkqrtPI25yKE+fwe6+VEvB3vSwLCM56aoGG8L mQAWtfWbRe0KJwx9462IxYpCo0yQwnTHXCI45tkdQVef/FQ2DS5fWQbPtSXDXiFbH6x0 PYJA== MIME-Version: 1.0 X-Received: by 10.220.82.199 with SMTP id c7mr828158vcl.61.1413812554378; Mon, 20 Oct 2014 06:42:34 -0700 (PDT) Received: by 10.52.35.235 with HTTP; Mon, 20 Oct 2014 06:42:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 15:42:34 +0200 Message-ID: From: Erwann Abalea To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=089e016340381569580505dae344 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/UK21kAWvI6f0tt_JHA-AuBXKa54 Subject: [Trans] Fwd: Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 13:43:53 -0000 --089e016340381569580505dae344 Content-Type: text/plain; charset=UTF-8 Discussion around the format happened in mid/late september, the idea of a CMS/PKCS#7 structure to hold the signature seems fine. Additional questions come in: is the new format intended to *replace* or *complement* the current one? If it's a replacement, what timeframe? CAs are already doing software modifications and deployment, please be nice :) The same question remains on the knowledge of the serial number before generating the final certificate, with no objection so far, even with arguments raised by Stephen Kent (valid ones, I used such HSMs in the past for SET certs, the BBN SafeKeyper Signer). It seems that no public CA concerned by CT is using such HSM, I guess they all use a HSM for its key handling job and do certificate generation at a software level. 2014-10-16 17:09 GMT+02:00 Ben Laurie : > We (the 6962-bis editors) would like to propose that we replace the > existing precertificate formats with a TBSCertificate wrapped in PKCS#7. > This lays to rest, we think, any possible confusion with X509v3 certs, > whilst allowing a simple mapping between the final cert and the pre-cert. > > Obviously there are details to be nailed down, but before we do so, we'd > like to hear any discussion on the general idea. > -- Erwann. --089e016340381569580505dae344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Discussion around the format happened in mid/late septembe= r, the idea of a CMS/PKCS#7 structure to hold the signature seems fine.Additional questions come in: is the new format intended to *replace* or *= complement* the current one? If it's a replacement, what timeframe? CAs= are already doing software modifications and deployment, please be nice :)=

The same question remains on the knowledge of the serial = number before generating the final certificate, with no objection so far, e= ven with arguments raised by Stephen Kent (valid ones, I used such HSMs in = the past for SET certs, the BBN SafeKeyper Signer).
It seems that= no public CA concerned by CT is using such HSM, I guess they all use a HSM= for its key handling job and do certificate generation at a software level= .

2014-10-16 1= 7:09 GMT+02:00 Ben Laurie <benl@google.com>:
We (the 6962-bis editors) would like to propose that we re= place the existing precertificate formats with a TBSCertificate wrapped in = PKCS#7. This lays to rest, we think, any possible confusion with X509v3 cer= ts, whilst allowing a simple mapping between the final cert and the pre-cer= t.

Obviously there are details to be nailed down, but be= fore we do so, we'd like to hear any discussion on the general idea.

--
Erwann.
--089e016340381569580505dae344-- From nobody Mon Oct 20 10:45:03 2014 Return-Path: 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 627CF1A88C2 for ; Mon, 20 Oct 2014 10:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 HN76UIKILP4O for ; Mon, 20 Oct 2014 10:45:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C3C1A88F3 for ; Mon, 20 Oct 2014 10:44:59 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5874080055; Mon, 20 Oct 2014 13:44:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1413827098; bh=AweHjXYTE8Ti/v/4gjE3+mdV/HQTn/JFlrPrtcnIjto=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DqfrebdCwAKkiyip3z62WugXZG14IhNQq+kSIkrKCBBLRtXlb7UVZBNFIqYXJB9Iw O0Uyid8T1VsfZukSRUJWE03xRwLRdy42oMkiMf68fiznNFMBc6kOUM1r+oxNz6lTzr SrihnFPW6M6fo8BTXpxHiyTJVpzS29XCdtpmKUig= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s9KHivhA005785; Mon, 20 Oct 2014 13:44:58 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 20 Oct 2014 13:44:57 -0400 (EDT) From: Paul Wouters To: Linus Nordberg In-Reply-To: <87ppdmhqg7.fsf@nordberg.se> Message-ID: References: <871tq6uaf1.fsf@nordberg.se> <87ppdmhqg7.fsf@nordberg.se> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-Xcd5635tqSIZqBjZ6Up8s_LXmA Cc: trans@ietf.org Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:45:02 -0000 On Mon, 20 Oct 2014, Linus Nordberg wrote: as individual without chair hat... > Logs MUST verify that the submitted end-entity certificate or > My intention was to make the specification less restrictive by changing > > Logs MAY accept certificates that have > expired, are not yet valid, have been revoked, or are otherwise not > fully valid according to X.509 verification rules in order to > accommodate quirks of CA certificate-issuing software. That seems to bring up the topic a bit too broadly I think? How about: Logs MUST protect themselves against spam. They MAY require a fully validated X.509 certification chain to one of their configured trusted root CA's. That leaves out the discussion for other checks, that may or may not go into a separate section or document. Paul From nobody Mon Oct 20 14:33:33 2014 Return-Path: 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 94E4A1ACEF4 for ; Mon, 20 Oct 2014 14:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 4KSd4HovpDg1 for ; Mon, 20 Oct 2014 14:33:30 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4EA1A00B7 for ; Mon, 20 Oct 2014 14:33:29 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9KLXRwq022458 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 23:33:27 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s9KLXNHR022277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 21:33:26 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1413840806; bh=bPMIP5/Z4N5lED4ctUgdL4l4OD4H0Dv2oCB63m6rmhs=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=cLAlI8yELdo9ZR8VLxZu+zTmEluRn9iJukvW84sgebx3UWPIeMnN/IjKHcwAw3qur 543y05bVJVDIb2003KWzC3oFEdhs5rPK4Rh8bdyWyhb2KtvHAcfbrnT0tz7NXqbGyX 5u6EleuAMUmefs4eWpvxrpRkjYu6b+DL3torjTok= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 20 Oct 2014 23:33:23 +0200 From: Linus Nordberg To: Paul Wouters Organization: NORDUnet A/S References: <871tq6uaf1.fsf@nordberg.se> <87ppdmhqg7.fsf@nordberg.se> Date: Mon, 20 Oct 2014 23:33:51 +0200 In-Reply-To: (Paul Wouters's message of "Mon, 20 Oct 2014 13:44:57 -0400 (EDT)") Message-ID: <87zjcqjuio.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aN5xxrTC - cbe5064c2d83 - 20141020 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/KeQhbXQIpfWn0l6egrdeYXKqLGc Cc: trans@ietf.org Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:33:31 -0000 Paul Wouters wrote Mon, 20 Oct 2014 13:44:57 -0400 (EDT): | On Mon, 20 Oct 2014, Linus Nordberg wrote: | | as individual without chair hat... | | > Logs MUST verify that the submitted end-entity certificate or | | > My intention was to make the specification less restrictive by changing | > | > Logs MAY accept certificates that have | > expired, are not yet valid, have been revoked, or are otherwise not | > fully valid according to X.509 verification rules in order to | > accommodate quirks of CA certificate-issuing software. | | That seems to bring up the topic a bit too broadly I think? How about: The text above is the current text in 6962bis-4. | Logs MUST protect themselves against spam. They MAY require a | fully validated X.509 certification chain to one of their configured | trusted root CA's. This may be OK for the spam issue but certainly not for attribution. My current standpoint is that I think logs MUST perform signature chain validation up to any root in a set of known root certs, chosen by the log operator, and MUST NOT reject a certificate for any other reasons. This effectively rules out self-signed certs, which I dislike, but that is not a change from current text. Maybe I'm just rehashing some of the points in the "path validation" thread (started 2014-09-29). A summary of points in that thread by someone who understands that discussion might help here. Afraid I was lost pretty early. From nobody Mon Oct 20 14:38:11 2014 Return-Path: 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 E730A1ACEF2 for ; Mon, 20 Oct 2014 14:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7YtbRaBJhm0E for ; Mon, 20 Oct 2014 14:38:05 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759151ACEFE for ; Mon, 20 Oct 2014 14:38:05 -0700 (PDT) X-AuditID: d80ac3f1-f791a6d0000069e3-0f-544580bc8555 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id A2.66.27107.CB085445; Mon, 20 Oct 2014 22:38:04 +0100 (BST) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1XgKeS-0002Hu-KU; Mon, 20 Oct 2014 21:38:04 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Mon, 20 Oct 2014 14:38:04 -0700 From: Rick Andrews To: Stephen Kent , "trans@ietf.org" Date: Mon, 20 Oct 2014 14:38:02 -0700 Thread-Topic: [Trans] Goals and generic mis-issuance fgramework Thread-Index: Ac/kBvkH0jFjwnzRSUS20XV+fS4VXgIpDMgw Message-ID: <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <5436FC38.1070201@bbn.com> In-Reply-To: <5436FC38.1070201@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607D2BA8687TUS1XCHEVSPIN_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsVyg+vQb909Da4hBmdPGFpsnM1osfbxRRYH Jo+p50M9liz5yRTAFMVlk5Kak1mWWqRvl8CVcX/rbbaCUzMZKxZsv8/cwHi/lbGLkZNDQsBE 4uasBnYIW0ziwr31bF2MXBxCAh8YJfo75kE5rxglfhy6xgzhrGKUWPvwJDNIC5uAnsSWx1fA 2kUEnCTud79hArFZBFQlmuavZQWxhQXsJHpf3mOGqLGXOLt1HROEbSRxdPYusF5egSiJ9ulz wOqFBNQkJu6eB1bDKaAu0fLkGpjNCHTe91NrwGxmAXGJW0/mM0GcLSCxZM95ZghbVOLl43+s EPWiEnfa1zNC1OdLtLccYIHYJShxcuYTFoh6SYmDK26wTGAUm4Vk7CwkLbOQtEDEdSQW7P7E BmFrSyxb+JoZxj5z4DETsvgCRvZVjDIlpcWGxbkl+aUlBakVBoZ6xZW5icCoTNZLzs/dxAiO zMMfdzAe3et4iFGAg1GJh/dMjWuIEGtiGVDlIUYJDmYlEd6/MUAh3pTEyqrUovz4otKc1OJD jNIcLErivG8r7EKEBNITS1KzU1MLUotgskwcnFINjJ0ydfEa+i8MvzGmLjgv277TISDi92Yh +yzlSy+kJpl857+iMqFVP59FKsThd7CZdZLL/g7FtObzhuuN9ky4Hy/Gfb7lT+2sxJULjff3 zdfQ8q38yf776OcvrE7LZt//f59vo83+vScnCfqEvlwS6xF7KOdLjoOa34yQ69Zsxa08n/1E k9eXK7EUZyQaajEXFScCAErw1wTIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/trans/OtPeWi6hsl_rdOOIxFqUKHaNQyQ 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:38:10 -0000 --_000_544B0DD62A64C1448B2DA253C011414607D2BA8687TUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen, Some comments inline. -Rick From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Thursday, October 09, 2014 2:21 PM To: trans@ietf.org Subject: [Trans] Goals and generic mis-issuance fgramework In response to some of the issues Paul and others have raised, I have gener= ated some text that tries to characterize the goal of CT, establishes a generic = framnework for defining checks for mis-issuance, and sets the stage for references to = two RFcs that will define syntactic and semantic checks for Web PKI certs claiming t= o conform to CABF DV or EV guidelines. Note that this text do not require a log to perform any checks; it allows a= log to indicate if has performed applicable checks, and the results of such checki= ng. Steve ------- 1. Certificate Transparency Goals and Mechanisms The goals of Certificate Transparency (CT) are threefold: detection, deterr= ence, 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?].) I= n the future, it is anticipated that addition *additional* operational cont= exts may be supported. As a result, mis-issuance is defined in an fashion t= hat accommodates a range of types of certificates used in a range of contex= ts. CT supports detection of mis-issuance using logs of certificates, populated= by the CAs that issue them or by the Subjects of certificates. Monitors (d= escribed in Section X) are the primary elements of the CT system that check= certificates for syntactic and semantic mis-issuance, on behalf of Subject= s. 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 c= lasses of certificates, but a log is not required to offer certificate chec= king. 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 sugge= st "CT supports detection of mis-issuance using logs of certificates, popul= ated by the CAs that issue them, by the Subjects of certificates, or by any= one with knowledge of the entire certificate chain.". 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 t= he certificate class asserted by the CA or Subject. Hmm... Since anyone can send a cert to a log, the first sentence must refle= ct that. But that makes me wonder what should happen if the "Reporter" (I d= on'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 t= he cert.) Or sends the cert multiple times with different CCIDs? I guess Mo= nitors would have to expect multiple entries for a given certificate in a g= iven log, with different CCIDs. I'm not sure if 6962-bis imposes any unique= ness constraint that this might violate. 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 se= t 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 CCI= D, and the certificate passed 4 This log performed the syntax checks for the asserted CCI= D, and the certificate failed No other SVV values are defined by this RFC. --_000_544B0DD62A64C1448B2DA253C011414607D2BA8687TUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Stephen,

=  

Some comments inline.

 

-R= ick

 

Fro= m: Trans [mailto:trans-bounc= es@ietf.org] On Behalf Of Stephen Kent
Sent: Thursday, Oct= ober 09, 2014 2:21 PM
To: trans@ietf.org
Subject: [Tran= s] Goals and generic mis-issuance fgramework

 

In response to some of the iss= ues Paul and others have raised, I have generated
some text that tries t= o characterize the goal of CT, establishes a generic framnework
for defi= ning checks for mis-issuance, and sets the stage for references to two RFcs=
that will define syntactic and semantic checks for Web PKI certs claim= ing to conform to
CABF DV or EV guidelines.

Note that this text = do not require a log to perform any checks; it allows a log to
indicate= if has performed applicable checks, and the results of such checking.
<= br>Steve
-------


1. Certificate Transparency Goals and Mechan= isms

 

The goals of Certificate Transparency (CT) are thr= eefold: 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 c= lients [cite WPKOPS?].) In the future, it is anticipated that addition *additional<= /b>* operational contexts may be= supported. As a result, mis-issuance is defined in an fashion that accommo= dates a range of types of certificates used in a range of contexts.

&= nbsp;

CT supports detection of mis-issuance using logs of certificate= s, populated by the CAs that issue them or by the Subjects of certificates.= Monitors (described in Section X) are the primary elements of the C= T system that check certificates for syntactic and semantic mis-issuance, o= n 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 perf= orm syntactic checks for some classes of certificates, but a log is not req= uired to offer certificate checking.

The first sentence needs to be more br= oad, since anyone can send a cert to a log. But it’s most likely to b= e 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.”.

 

To enable Monitors (an= d, 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 genera= ted by the log. By providing the CCID in logs and SCTs, both Monitors and c= lients are empowered to perform applicable checks based on the certificate = class asserted by the CA or Subject.

Hmm… Since anyone can send a cer= t 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 int= roduce a new role) sends the wrong CCID? (By “wrong” I mean it&= #8217;s a valid CCID, but it’s not the one that the CA would associat= e with the cert.) Or sends the cert multiple times with different CCIDs? I = guess Monitors would have to expect multiple entries for a given certificat= e in a given log, with different CCIDs. I’m not sure if 6962-bis impo= ses any uniqueness constraint that this might violate.  

 

A log MUST= generate a Syntax Verification Value (SVV) for the certificate, and includ= e the SVV in the log entry and in the SCT.

The LVV *SVV* is *a* value spe= cified by this document (see Section Z) that indicates whether or not the l= og performed applicable syntactic checks, and whether the (pre-) certificat= e passed of *or* failed the checks. = Although it is anticipated that new certificate classes will arise over tim= e, the set of log actions with respect to syntax checking appears to be wel= l-defined and thus need not be represented in an IANA registry. Each SCT is= sued by a log MUST include an SVV.  

 

 

Value Interpretati= on

0   &nbs= p;             = The CCID value was 0, so not<= /s> *no* checks were performed<= /o:p>

1=       =            This log does not perform syntax checks

2     = ;            = This log does not support syntax checks= for the asserted CCID

3&= nbsp;           &nbs= p;    This log pe= rformed the syntax checks for the asserted CCID, and the certificate passed=

4    &= nbsp;            This log performed the syntax check= s for the asserted CCID, and the certificate failed

 

No o= ther SVV values are defined by this RFC.

 

= = --_000_544B0DD62A64C1448B2DA253C011414607D2BA8687TUS1XCHEVSPIN_-- From nobody Mon Oct 20 14:51:40 2014 Return-Path: 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 1149B1ACF57 for ; Mon, 20 Oct 2014 14:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 krQP5NsLZyfu for ; Mon, 20 Oct 2014 14:51:29 -0700 (PDT) Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 907BF1ACF5D for ; Mon, 20 Oct 2014 14:51:28 -0700 (PDT) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id EDA92282E37 for ; Tue, 21 Oct 2014 08:51:27 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 66DF8A5312; Tue, 21 Oct 2014 08:51:23 +1100 (EST) Date: Tue, 21 Oct 2014 08:51:23 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20141020215123.GO16429@hezmatt.org> References: <871tq6uaf1.fsf@nordberg.se> <87ppdmhqg7.fsf@nordberg.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/cgy47aSPV9fWUKjoV_dXWsQYd8I Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:51:33 -0000 On Mon, Oct 20, 2014 at 01:44:57PM -0400, Paul Wouters wrote: > On Mon, 20 Oct 2014, Linus Nordberg wrote: > > as individual without chair hat... > > > Logs MUST verify that the submitted end-entity certificate or > > >My intention was to make the specification less restrictive by changing > > > > Logs MAY accept certificates that have > > expired, are not yet valid, have been revoked, or are otherwise not > > fully valid according to X.509 verification rules in order to > > accommodate quirks of CA certificate-issuing software. > > That seems to bring up the topic a bit too broadly I think? How about: > > Logs MUST protect themselves against spam. They MAY require a > fully validated X.509 certification chain to one of their configured > trusted root CA's. I prefer a more broad wording: Logs MAY reject certificate submissions which would compromise the integrity or availability of the log. An example of a valid reason to reject a submission would be an attempt to "spam" the log with large numbers of certificates, consuming all its storage space and/or processing capacity. Logs MUST NOT reject certificates for any other reason. I'm willing to compromise a little on that last sentence, but I've seen some comments recently that suggest that some people think CT logs are a validation checker, not an activity log, so it'd be nice to clarify that in the spec. - Matt -- [An ad for Microsoft] uses the musical theme of the "Confutatis Maledictis" from Mozart's Requiem. "Where do you want to go today?" is on the screen, while the chorus sings "Confutatis maledictis, flammis acribus addictis,". Translation: "The damned and accursed are convicted to the flames of hell." From nobody Mon Oct 20 15:28:04 2014 Return-Path: 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 D34BF1ACF5E for ; Mon, 20 Oct 2014 15:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 L2aa4dBmqUK0 for ; Mon, 20 Oct 2014 15:28:00 -0700 (PDT) Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id A784B1ACF73 for ; Mon, 20 Oct 2014 15:28:00 -0700 (PDT) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id C0B9E282E37 for ; Tue, 21 Oct 2014 09:27:59 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 8F22FA5312; Tue, 21 Oct 2014 09:27:58 +1100 (EST) Date: Tue, 21 Oct 2014 09:27:58 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20141020222758.GQ16429@hezmatt.org> References: <871tq6uaf1.fsf@nordberg.se> <87ppdmhqg7.fsf@nordberg.se> <87zjcqjuio.fsf@nordberg.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zjcqjuio.fsf@nordberg.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3vo06fMfCcPk7KmIeX7ve4ZumM4 Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 22:28:02 -0000 On Mon, Oct 20, 2014 at 11:33:51PM +0200, Linus Nordberg wrote: > Paul Wouters wrote > Mon, 20 Oct 2014 13:44:57 -0400 (EDT): > > | On Mon, 20 Oct 2014, Linus Nordberg wrote: > | > | as individual without chair hat... > | > | > Logs MUST verify that the submitted end-entity certificate or > | > | > My intention was to make the specification less restrictive by changing > | > > | > Logs MAY accept certificates that have > | > expired, are not yet valid, have been revoked, or are otherwise not > | > fully valid according to X.509 verification rules in order to > | > accommodate quirks of CA certificate-issuing software. > | > | That seems to bring up the topic a bit too broadly I think? How about: > > The text above is the current text in 6962bis-4. > > > | Logs MUST protect themselves against spam. They MAY require a > | fully validated X.509 certification chain to one of their configured > | trusted root CA's. > > This may be OK for the spam issue but certainly not for attribution. Is attribution critical for the core functionality of CT? (I know this goes back to the "purpose of CT" thread that Stephen's done a lot of work defining, and I've got to get around to participating in that thread) While I agree that the remediation mechanisms available increase if you know which root CA to hassle to get a cert revoked, knowledge that a cert was issued still has *some* value, even if there's no clear indication of who issued it (in a fanciful future of infinite storage, where self-signed certs were accepted in logs). - Matt -- Java. The elegant simplicity of C++. The blazing speed of Smalltalk. -- From http://c2.com/cgi/wiki?SmalltalkMinusMinus From nobody Tue Oct 21 02:42:35 2014 Return-Path: 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 330861A01FA for ; Tue, 21 Oct 2014 02:42:33 -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 DdgWgBLzPhVB for ; Tue, 21 Oct 2014 02:42:32 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE4A1A03A5 for ; Tue, 21 Oct 2014 02:39:17 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so552774qga.3 for ; Tue, 21 Oct 2014 02:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=o6IxXy3NRDRv66ok0DaUC2cErfpe8rzNv0eXbI/tqww=; b=AX3cwRVp20THVWzN1/6Kuwrs9eJUlbUrEGIQLth1V8e+QcgY0TQWTDsIZGj9r6F8hg B9HH5LQ4HOvanNfCuE/Qq+JdH3dpM6ir8bLfXdltXXGHzsjE/D7+mHERjEMNweKG6H9n Q2Hly9/s9Y5xk9bG//j5GZOTwx1/Q7faz7uT+5BmKqINmSKqgJ/1rXE/dec8dYFuK9rA 85iG+CTyXOCbMbGdO8VlBCj+kBJGQEHB7iLAUXPI1/RTJMYsmHdmpWuXI4YkleAdXIfb 8UgHuSCQhxiOXgP/w2nkKIa9U9Z6iOm+M3yz2bnpFjass8H7gUejLDr25NsFDGs+Hx55 bjVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=o6IxXy3NRDRv66ok0DaUC2cErfpe8rzNv0eXbI/tqww=; b=bsEjH8Y4NHrohzteeckPVu8DykEE+Hy6J3ULvxS28TYFoIol6JZJAWftXpA9822Y/l QS5B7YGpkD/sCVEIQbIr40fuQgHEHv03bstH3fkECecGlB6R8ByiwrfuLoGupq1oiTc4 npWjbicMX6XfY/65n8JTBbXA8mAoIKNd5VJMJKSy5FWL4OILU9KDnbO6kHXOk3tA9f4s A6zZuchodLWGrLOOTxIuUWU8dXxx129wbXIDGUHieK2lkcFFn+vHA6IRwpMtA+tewmTo XsgfcxkXeDGfOrfec44HKBWrqNccgCUiC7Lt1aBu0osOXQEUbKORZiBMTA3CefhT+Nvl 4cJQ== X-Gm-Message-State: ALoCoQnt4uvnpZiq2x/Tm/ZAdf3rx9dsZnQoULdVfSh3uT/fBgr5Sycsk9WOTk1S8hdxqDKC9wsb X-Received: by 10.140.89.10 with SMTP id u10mr41049639qgd.70.1413884356330; Tue, 21 Oct 2014 02:39:16 -0700 (PDT) MIME-Version: 1.0 References: <871tq6uaf1.fsf@nordberg.se> <87ppdmhqg7.fsf@nordberg.se> <87zjcqjuio.fsf@nordberg.se> <20141020222758.GQ16429@hezmatt.org> From: Ben Laurie Date: Tue, 21 Oct 2014 09:39:15 +0000 Message-ID: To: Matt Palmer , trans@ietf.org Content-Type: multipart/alternative; boundary=001a11c1211ad0434c0505eb9a4f Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qhHj4unPgWGgaloT66oe8hww638 Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:42:33 -0000 --001a11c1211ad0434c0505eb9a4f Content-Type: text/plain; charset=UTF-8 On Mon Oct 20 2014 at 11:28:06 PM Matt Palmer wrote: > On Mon, Oct 20, 2014 at 11:33:51PM +0200, Linus Nordberg wrote: > > Paul Wouters wrote > > Mon, 20 Oct 2014 13:44:57 -0400 (EDT): > > > > | On Mon, 20 Oct 2014, Linus Nordberg wrote: > > | > > | as individual without chair hat... > > | > > | > Logs MUST verify that the submitted end-entity certificate or > > | > > | > My intention was to make the specification less restrictive by > changing > > | > > > | > Logs MAY accept certificates that have > > | > expired, are not yet valid, have been revoked, or are otherwise not > > | > fully valid according to X.509 verification rules in order to > > | > accommodate quirks of CA certificate-issuing software. > > | > > | That seems to bring up the topic a bit too broadly I think? How about: > > > > The text above is the current text in 6962bis-4. > > > > > > | Logs MUST protect themselves against spam. They MAY require a > > | fully validated X.509 certification chain to one of their > configured > > | trusted root CA's. > > > > This may be OK for the spam issue but certainly not for attribution. > > Is attribution critical for the core functionality of CT? (I know this > goes > back to the "purpose of CT" thread that Stephen's done a lot of work > defining, and I've got to get around to participating in that thread) > While > I agree that the remediation mechanisms available increase if you know > which > root CA to hassle to get a cert revoked, knowledge that a cert was issued > still has *some* value, even if there's no clear indication of who issued > it > (in a fanciful future of infinite storage, where self-signed certs were > accepted in logs). > Exactly - for example, accepting self-signed certificates would not change Chrome's behaviour when it sees one, whether it comes with an appropriate SCT or not. --001a11c1211ad0434c0505eb9a4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon Oct 20 2014 at 11:28:06 PM Matt P= almer <mpalmer@hezmatt.org>= ; wrote:
On Mon, Oct 20, 2014 at 11:33:51= PM +0200, Linus Nordberg wrote:
> Paul Wouters <p= aul@nohats.ca> wrote
> Mon, 20 Oct 2014 13:44:57 -0400 (EDT):
>
> | On Mon, 20 Oct 2014, Linus Nordberg wrote:
> |
> | as individual without chair hat...
> |
> | >=C2=A0 =C2=A0Logs MUST verify that the submitted end-entity cert= ificate or
> |
> | > My intention was to make the specification less restrictive by = changing
> | >
> | >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Logs MAY accept certificate= s that have
> | >=C2=A0 =C2=A0expired, are not yet valid, have been revoked, or a= re otherwise not
> | >=C2=A0 =C2=A0fully valid according to X.509 verification rules i= n order to
> | >=C2=A0 =C2=A0accommodate quirks of CA certificate-issuing softwa= re.
> |
> | That seems to bring up the topic a bit too broadly I think? How abou= t:
>
> The text above is the current text in 6962bis-4.
>
>
> |=C2=A0 =C2=A0 =C2=A0Logs MUST protect themselves against spam. They M= AY require a
> |=C2=A0 =C2=A0 =C2=A0fully validated X.509 certification chain to one = of their configured
> |=C2=A0 =C2=A0 =C2=A0trusted root CA's.
>
> This may be OK for the spam issue but certainly not for attribution.
Is attribution critical for the core functionality of CT?=C2=A0 (I know thi= s goes
back to the "purpose of CT" thread that Stephen's done a lot = of work
defining, and I've got to get around to participating in that thread)= =C2=A0 While
I agree that the remediation mechanisms available increase if you know whic= h
root CA to hassle to get a cert revoked, knowledge that a cert was issued still has *some* value, even if there's no clear indication of who issu= ed it
(in a fanciful future of infinite storage, where self-signed certs were
accepted in logs).

Exactly - for exampl= e, accepting self-signed certificates would not change Chrome's behavio= ur when it sees one, whether it comes with an appropriate SCT or not.
=

--001a11c1211ad0434c0505eb9a4f-- From nobody Tue Oct 21 06:52:46 2014 Return-Path: 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 04CF01A6F62 for ; Tue, 21 Oct 2014 06:52:42 -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 yAXVOP-cmvtq for ; Tue, 21 Oct 2014 06:52:38 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14131A6F49 for ; Tue, 21 Oct 2014 06:51:23 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j7so834861qaq.16 for ; Tue, 21 Oct 2014 06:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=zJ5ebU5OX+/8PEFw3Zv/hVru3rxuXWeTrRiUO+itq3s=; b=MIxfqy69isa+PWS7uuz6d/x++spu3CS5a5BAx+736GFCleaKh0pNAF2kUfhXUkmeJF jbB16NvIArmznReQBLZMWUBPnwUde/5NYnPWk8s7/MAWd7eAZxADETbLZIX00IF4dWPe USEZ8ywz3mf73rnHatrc2Odw9AVLGgX90Brdcols+yFbzGQeYid5hdMxkZH5991RVr4N AD3cEiSGjvegfSTHFTa4HM54ano9IP0gxMklj04ByvckBz4hHlmQsc1yq4gN3iojjwRZ VJ3ZKrILiuC9HijnDZIup7T08Bd5P9UUG0kFYOTf9v0Yt7aSeJiBAFmF2WLDwEo/jx07 x22w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=zJ5ebU5OX+/8PEFw3Zv/hVru3rxuXWeTrRiUO+itq3s=; b=d0OTITaREUIJemP+jZZRY4NHlr3m5lNyGv+lw/t20b1DOaflyzVNHFKDM6l1fiWxfx +lbQyuDXPOji3us+OlDSBfDOLVXvHfQgzJeGYWmob6mVIMm4Mf1sHaSyCzy827zxA1AJ gjIXUeeqyDcf8HNHg9EYH7SzvT4l7SYZbCcnXHDU3cZA4+0sg1BYu37cAoCGk3Ouv3um +VphaRBDAiioLAOkdQp6B3NLlkdoAHErvwfoPBa97T2ZPaH75n/Zq1/dbb8fMxay+3jH YrUH1F8wwbrW5jW23hBXTGJoDJN15A2seSpUGfmDwxfxpMg+xzxU4gt8zvooQTODnZxC GzPg== X-Gm-Message-State: ALoCoQkqFz+6HtwNqB2RS6jMHSQUB6xlHFh334aG1PSjkpP2d4KqccB9/dJh1fctf9Rwkra8d7v5 X-Received: by 10.140.31.139 with SMTP id f11mr22230916qgf.30.1413899478981; Tue, 21 Oct 2014 06:51:18 -0700 (PDT) MIME-Version: 1.0 References: From: Ben Laurie Date: Tue, 21 Oct 2014 13:51:18 +0000 Message-ID: To: Erwann Abalea , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113a92083199970505ef204d Archived-At: http://mailarchive.ietf.org/arch/msg/trans/nGNn8hZIW37U5RM65ZWTRvms8ok Subject: Re: [Trans] Fwd: Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:52:42 -0000 --001a113a92083199970505ef204d Content-Type: text/plain; charset=UTF-8 On Mon Oct 20 2014 at 2:44:07 PM Erwann Abalea wrote: > Discussion around the format happened in mid/late september, the idea of a > CMS/PKCS#7 structure to hold the signature seems fine. > Additional questions come in: is the new format intended to *replace* or > *complement* the current one? If it's a replacement, what timeframe? CAs > are already doing software modifications and deployment, please be nice :) > The proposal is to replace the current format. In terms of timeframe, Google has not announced any plans to move to 6962-bis (and is not likely to before it becomes an RFC). --001a113a92083199970505ef204d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon Oct 20 2014 at 2:44:07 PM Erwann = Abalea <eabalea@gmail.com> w= rote:
Discussion around = the format happened in mid/late september, the idea of a CMS/PKCS#7 structu= re to hold the signature seems fine.
Additional questions come in: is t= he new format intended to *replace* or *complement* the current one? If it&= #39;s a replacement, what timeframe? CAs are already doing software modific= ations and deployment, please be nice :)
<= br>
The proposal is to replace the current format.

=
In terms of timeframe, Google has not announced any plans to mov= e to 6962-bis (and is not likely to before it becomes an RFC).
--001a113a92083199970505ef204d-- From nobody Tue Oct 21 08:28:23 2014 Return-Path: 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 A0A7E1A87D9 for ; Tue, 21 Oct 2014 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GI0R3drCXpcL for ; Tue, 21 Oct 2014 08:28:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA5F1A87CB for ; Tue, 21 Oct 2014 08:28:07 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36187 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XgbMD-0003as-FF for trans@ietf.org; Tue, 21 Oct 2014 11:28:21 -0400 Message-ID: <54467B82.30502@bbn.com> Date: Tue, 21 Oct 2014 11:28:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070006070008090304010002" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/iF8G0G7M0dCoiBa9svZ9yEx_w7k Subject: Re: [Trans] Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:28:19 -0000 This is a multi-part message in MIME format. --------------070006070008090304010002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think that's an excellent idea. Steve > We (the 6962-bis editors) would like to propose that we replace the > existing precertificate formats with a TBSCertificate wrapped in > PKCS#7. This lays to rest, we think, any possible confusion with > X509v3 certs, whilst allowing a simple mapping between the final cert > and the pre-cert. > > Obviously there are details to be nailed down, but before we do so, > we'd like to hear any discussion on the general idea. > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --------------070006070008090304010002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think that's an excellent idea.

Steve

We (the 6962-bis editors) would like to propose that we replace the existing precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays to rest, we think, any possible confusion with X509v3 certs, whilst allowing a simple mapping between the final cert and the pre-cert.

Obviously there are details to be nailed down, but before we do so, we'd like to hear any discussion on the general idea.


_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans

--------------070006070008090304010002-- From nobody Tue Oct 21 08:46:13 2014 Return-Path: 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 92C261A876C for ; Tue, 21 Oct 2014 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RjyexCFdEFeN for ; Tue, 21 Oct 2014 08:46:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36801A87EF for ; Tue, 21 Oct 2014 08:46:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37825 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xgbdc-0003oe-VQ for trans@ietf.org; Tue, 21 Oct 2014 11:46:21 -0400 Message-ID: <54467FBA.8020903@bbn.com> Date: Tue, 21 Oct 2014 11:46:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Content-Type: multipart/alternative; boundary="------------050701060504040205010904" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Cs70QlIQwZ4vkRey3OcaWIong9M 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:46:11 -0000 This is a multi-part message in MIME format. --------------050701060504040205010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rick, Thanks for the comments. > ------- > > > 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.". > I'll use your text here, thanks. > > 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. > Thanks for catching the typo. If a (pre-) cert is submitted with a CCID that is inappropriate for the cert type, then there can be several outcomes, depending on the nature of the error and the log operation. If a cert class not yet accepted by the log, the log will not try to check it, and it will be marked that way. If the log does check the CCID in question, the cert may fail (but will still be logged) because the wrong syntactic checks were applied. The CA/Subject/other will get immediate feedback on that, which might cause re-sumbission to the log, with the right CCID. If the same cert is sent multiple times, with different CCIDS, this is something a Monitor will notice, if it's protecting the name in the cert in nquestion. The Subject should be notified of this anomalous behavior. An Auditor might note this behavior as well; we'll see when we have a concrete description of the functions that an Auditor performs. In any case, I don't see the multiple CCID situation as a problem for CT; it does provide more info to those watching logs. Since the same cert may be submitted to a log by multiple entities (CA, Subject, nosy 3rd party) already, I don't see any uniqueness constraint issues from 6962-bis. > > 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. > thanks again for catching that typo too. Santosh also noted this in a message to me. > > Value Interpretation > > 0The CCID value was 0, so not **no** checks were performed > Again, thanks for catching this typo. Steve --------------050701060504040205010904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rick,

Thanks for the comments.

-------


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


I'll use your text here, thanks.

 

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. 

Thanks for catching the typo. If a (pre-) cert is submitted with a CCID that is inappropriate
for the cert type, then there can be several outcomes, depending on the nature of the error and the log operation. If a cert class not yet accepted by the log, the log will not try to check it, and it will be marked that way.

If the log does check the CCID in question, the cert may fail (but will still be logged) because the wrong syntactic checks were applied. The CA/Subject/other will get immediate feedback on that, which might cause re-sumbission to the log, with the right CCID.

If the same cert is sent multiple times, with different CCIDS, this is something a Monitor will notice, if it's protecting the name in the cert in nquestion. The Subject should be notified of this anomalous behavior.

An Auditor might note this behavior as well; we'll see when we have a concrete description of the functions that an Auditor performs.

In any case, I don't see the multiple CCID situation as a problem for CT; it does provide more info to those watching logs. Since the same cert may be submitted to a log by multiple entities (CA, Subject, nosy 3rd party) already, I don't see any uniqueness constraint issues from 6962-bis.

 

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. 

thanks again for catching that typo too. Santosh also noted this in a message to me.

 

 

Value Interpretation

0                 The CCID value was 0, so not *no* checks were performed

Again, thanks for catching this typo.

Steve

--------------050701060504040205010904-- From nobody Tue Oct 21 08:46:36 2014 Return-Path: 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 605B01A8867 for ; Tue, 21 Oct 2014 08:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JW5fNWC5NE2u for ; Tue, 21 Oct 2014 08:46:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26421A87EF for ; Tue, 21 Oct 2014 08:46:26 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37827 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xgbds-0003ol-0S for trans@ietf.org; Tue, 21 Oct 2014 11:46:41 -0400 Message-ID: <54467FCA.4090200@bbn.com> Date: Tue, 21 Oct 2014 11:46:18 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <871tq6uaf1.fsf@nordberg.se> <87ppdmhqg7.fsf@nordberg.se> <87zjcqjuio.fsf@nordberg.se> <20141020222758.GQ16429@hezmatt.org> In-Reply-To: <20141020222758.GQ16429@hezmatt.org> Content-Type: multipart/alternative; boundary="------------020905030705090205000802" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/kDGsYmEDSCpSHANJV5LAgxVoMgE Subject: Re: [Trans] Certificate verification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:46:33 -0000 This is a multi-part message in MIME format. --------------020905030705090205000802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt, Fair question. If attribution is not possible, because we choose to not require chaining to a root accepted by the log (as currently called for) then the attack analysis will be updated to reflect this loss of security functionality in those cases. Note that my proposal to allow (not require) logs to perform syntactic checks, and to note the result of such checks, is compatible with logs that choose to not perform even basic path validation. It would be another class of (non) checks that can be registered in the proposed IANA registry and reported by a log. Also, if basic path validation is not performed, a log should advertise that, just as it should advertise the set of root CAs that it does check. This allows Monitors and clients to know what the log says it is doing, so that others do not have to guess or learn by some unspecified, OOB means. I suggest another registry entry for logging self-signed certs will make sense too, if 6962-bis stops excluding them. Steve > Is attribution critical for the core functionality of CT? (I know this goes > back to the "purpose of CT" thread that Stephen's done a lot of work > defining, and I've got to get around to participating in that thread) While > I agree that the remediation mechanisms available increase if you know which > root CA to hassle to get a cert revoked, knowledge that a cert was issued > still has *some* value, even if there's no clear indication of who issued it > (in a fanciful future of infinite storage, where self-signed certs were > accepted in logs). > > - Matt > --------------020905030705090205000802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Matt,

Fair question. If attribution is not possible, because we choose to not require
chaining to a root accepted by the log (as currently called for) then the attack
analysis will be updated to reflect this loss of security functionality in those
cases.

Note that my proposal to allow (not require) logs to perform syntactic checks,
and to note the result of such checks, is compatible with logs that choose to not
perform even basic path validation. It would be another class of (non) checks that
can be registered in the proposed IANA registry and reported by a log. Also, if
basic path  validation is not performed, a log should advertise that, just as it
should advertise the set of root CAs that it does check. This allows Monitors and
clients to know what the log says it is doing, so that others do not have to guess
or learn by some unspecified, OOB means.

I suggest  another registry entry for logging self-signed certs will make sense
too, if 6962-bis stops excluding them.

Steve


Is attribution critical for the core functionality of CT?  (I know this goes
back to the "purpose of CT" thread that Stephen's done a lot of work
defining, and I've got to get around to participating in that thread)  While
I agree that the remediation mechanisms available increase if you know which
root CA to hassle to get a cert revoked, knowledge that a cert was issued
still has *some* value, even if there's no clear indication of who issued it
(in a fanciful future of infinite storage, where self-signed certs were
accepted in logs).

- Matt

--------------020905030705090205000802-- From nobody Tue Oct 21 08:59:02 2014 Return-Path: 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 D21C31A87E1 for ; Tue, 21 Oct 2014 08:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 G7NfuBgpiTqE for ; Tue, 21 Oct 2014 08:58:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE821A88BB for ; Tue, 21 Oct 2014 08:58:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38890 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xgbpp-000Q0h-N7 for trans@ietf.org; Tue, 21 Oct 2014 11:58:57 -0400 Message-ID: <544682BF.3040407@bbn.com> Date: Tue, 21 Oct 2014 11:58:55 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <543D527E.40506@bbn.com> <4262AC0DB9856847A2D00EF817E8113923E418@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E8113923E418@scygexch10.cygnacom.com> Content-Type: multipart/alternative; boundary="------------090204020104030101010206" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/keZLfjPa-NMoZW19CJA4Ql9bVl0 Subject: Re: [Trans] attack analysis, revised X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:59:00 -0000 This is a multi-part message in MIME format. --------------090204020104030101010206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh, Thanks for the comments on Note 4. I have made appropriate changes to the text. > > Steve, > > Looks good to me. See a few comments editorial and substantive > in-line below starting at Note 4. > *Steve* --------------090204020104030101010206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Santosh,

Thanks for the comments on Note 4. I have made appropriate changes to the text.

Steve,

 

Looks good to me.  See a few comments editorial and substantive in-line below starting at Note 4.

 

Steve
--------------090204020104030101010206-- From nobody Sat Oct 25 09:51:56 2014 Return-Path: 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 8A3571A1AC5 for ; Sat, 25 Oct 2014 09:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.146 X-Spam-Level: X-Spam-Status: No, score=-97.146 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] 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 88GLMUfduCSY for ; Sat, 25 Oct 2014 09:51:53 -0700 (PDT) Received: from odin.smetech.net (unknown [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 80CBE1A1AB6 for ; Sat, 25 Oct 2014 09:51:53 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E68BFF9C064 for ; Sat, 25 Oct 2014 12:51:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id XesRrEsb1F47 for ; Sat, 25 Oct 2014 12:51:22 -0400 (EDT) Received: from [192.168.2.108] (pool-96-255-133-207.washdc.fios.verizon.net [96.255.133.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 21705F9C05B for ; Sat, 25 Oct 2014 12:51:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Sat, 25 Oct 2014 12:51:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <64F4A6B5-83B3-4C95-B163-15F2980F3425@vigilsec.com> References: To: "trans@ietf.org" X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/KFRJNBA8Vr5r3d3OBewCw3MXhOo Subject: Re: [Trans] Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 16:51:54 -0000 I think you are suggesting the format used in a .p7c file. If I = understand correctly, I fully support this idea. Russ > We (the 6962-bis editors) would like to propose that we replace the = existing precertificate formats with a TBSCertificate wrapped in PKCS#7. = This lays to rest, we think, any possible confusion with X509v3 certs, = whilst allowing a simple mapping between the final cert and the = pre-cert. >=20 > Obviously there are details to be nailed down, but before we do so, = we'd like to hear any discussion on the general idea. From nobody Sat Oct 25 10:01:53 2014 Return-Path: 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 989191A1A96 for ; Sat, 25 Oct 2014 10:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.044 X-Spam-Level: X-Spam-Status: No, score=-99.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] 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 WbN9CBj3gBRD for ; Sat, 25 Oct 2014 10:01:49 -0700 (PDT) Received: from odin.smetech.net (unknown [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFB11A1A8A for ; Sat, 25 Oct 2014 10:01:49 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id F37F2F9C05B; Sat, 25 Oct 2014 13:01:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id U4K-Z104ZI8n; Sat, 25 Oct 2014 13:01:17 -0400 (EDT) Received: from [192.168.2.108] (pool-96-255-133-207.washdc.fios.verizon.net [96.255.133.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4F7E4F2C0F6; Sat, 25 Oct 2014 13:01:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-396-10086083 From: Russ Housley In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Sat, 25 Oct 2014 13:01:06 -0400 Message-Id: <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> References: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: Rick Andrews , Steve Kent X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/p8iprilIGEEcy2hq7YvTsR_CtS0 Cc: trans@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 17:01:51 -0000 --Apple-Mail-396-10086083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Steve and Rick: >=20 > 1. Certificate Transparency Goals and Mechanisms > =20 > 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. > =20 > 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 =93self-monitoring=94.) 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=92s most likely to be the CAs or the Subjects, so = I would suggest =93CT 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.=94. 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. > =20 > 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=85 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 = =93Reporter=94 (I don=92t want to introduce a new role) sends the wrong = CCID? (By =93wrong=94 I mean it=92s a valid CCID, but it=92s 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=92m not sure if 6962-bis imposes any uniqueness constraint that = this might violate. =20 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. > =20 > 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. =20 > =20 > =20 > 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 > =20 > 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. Russ --Apple-Mail-396-10086083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

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 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 =93self-monitoring=94.) = 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=92s = most likely to be the CAs or the Subjects, so I would suggest =93CT = 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.=94.

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.

 
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=85 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 =93Reporter=94 (I don=92t want to introduce a new role) = sends the wrong CCID? (By =93wrong=94 I mean it=92s a valid CCID, but = it=92s 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=92m 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.

 
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  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  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
 The CCID value was 0, so not  checks were = performed
 This log does not perform syntax = checks
 This log does not support syntax checks = for the asserted CCID
 This log performed the syntax checks = for the asserted CCID, and the certificate = passed
 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.

Russ

= --Apple-Mail-396-10086083-- From nobody Mon Oct 27 15:32:53 2014 Return-Path: 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 19AD41A1B2E for ; Mon, 27 Oct 2014 15:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PhPj2oeErqio for ; Mon, 27 Oct 2014 15:32:45 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D35A1A1B1C for ; Mon, 27 Oct 2014 15:32:40 -0700 (PDT) X-AuditID: d80ac3f3-f790d6d00000101f-8c-544ec8074241 Received: from tus1smtintpin01.ges.symantec.com (tus1smtintpin01.ges.symantec.com [192.168.215.101]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id CE.74.04127.708CE445; Mon, 27 Oct 2014 22:32:39 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Xisq7-000G7B-9g; Mon, 27 Oct 2014 22:32:39 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Mon, 27 Oct 2014 15:32:56 -0700 From: Rick Andrews To: Russ Housley , Steve Kent Date: Mon, 27 Oct 2014 15:32:37 -0700 Thread-Topic: [Trans] Goals and generic mis-issuance fgramework Thread-Index: Ac/wdWgLhn5e0gqYQ0mP/Ff0roKrTwBvlz0g Message-ID: <544B0DD62A64C1448B2DA253C011414607D375BE52@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> In-Reply-To: <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607D375BE52TUS1XCHEVSPIN_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsVyg+vQb132E34hBndOy1u8enGT3WLjbEaL tY8vsjgwe0w9H+qxZMlPJo9Vd76wBjBHcdmkpOZklqUW6dslcGX0zPrCWvDvHGPFhGed7A2M B7YydjFyckgImEi8P3mICcIWk7hwbz1bFyMXh5DAR0aJqxfuskI4rxgl/r3uhHJWMUpMPHUe rJ1NQE9iy+Mr7CC2iICTxP1zU8BsZgFViW1Hn4LZLED2udsPwFYIC9hJ9L68xwxRby9xdus6 JgjbSOLWnq0sIDavQJTEu7c/GSGWrWWU2NSxHizBKeAg8fXhTbChjEC3fj+1hglimbjErSfz oX4QkFiy5zwzhC0q8fLxP1aIelGJO+3rGSHq8yXW9/1iglgmKHFy5hMWiHpJiYMrbrBMYBSf hWTsLCQts5C0QMR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMMiWlxYbFuSX5pSUFqRUG xnrFlbmJwBhO1kvOz93ECI7jw593MP7e43iIUYCDUYmHN3ajX4gQa2IZUOUhRgkOZiURXq8d QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8fyrsQoQE0hNLUrNTUwtSi2CyTBycUg2MLW9kzn5b zVMgUSxaFbb9/pInitKXrbbdc9qz70BSoDJbKJN1U3n0i15hhiXfd53tKd1urvvk+8nYwvvh 1s3xmTd2ajA/2/v0TbXmsfisGYZvvd4nS8+O/FQusPyokXGt8R/FAN5axan9/XWO3UX8Gr/i +595zTvU+ZC9+dTlxbrvJfUFFx1XYinOSDTUYi4qTgQAuopZHd8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EBTYIAeolqzgYEvup-6txBSUf7I Cc: "trans@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:32:51 -0000 --_000_544B0DD62A64C1448B2DA253C011414607D375BE52TUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ, comments inline. -Rick From: Trans [mailto: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, deterr= ence, 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?].) I= n the future, it is anticipated that addition *additional*operational conte= xts may be supported. As a result, mis-issuance is defined in an fashion th= at accommodates a range of types of certificates used in a range of context= s. CT supports detection of mis-issuance using logs of certificates, populated= by the CAs that issue them or by the Subjects of certificates. Monitors (d= escribed in Section X) are the primary elements of the CT system that check= certificates for syntactic and semantic mis-issuance, on behalf of Subject= s. 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 c= lasses of certificates, but a log is not required to offer certificate chec= king. 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 sugge= st "CT supports detection of mis-issuance using logs of certificates, popul= ated by the CAs that issue them, by the Subjects of certificates, or by any= one with knowledge of the entire certificate chain.". Can't anyone build the certificate chain? Since the logs are posting the s= upported trust anchors, anyone can build a chain for the end entity certifi= cate. [Rick] In most cases, yes. If someone has access to the server configured w= ith that certificate, they can do a TLS handshake and get the chain in near= ly 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 accep= t 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 t= he certificate class asserted by the CA or Subject. Hmm... Since anyone can send a cert to a log, the first sentence must refle= ct that. But that makes me wonder what should happen if the "Reporter" (I d= on'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 t= he cert.) Or sends the cert multiple times with different CCIDs? I guess Mo= nitors would have to expect multiple entries for a given certificate in a g= iven log, with different CCIDs. I'm not sure if 6962-bis imposes any unique= ness constraint that this might violate. Alternatively, a log could check to see if the reported certificate is alre= ady present, and if so, return the older entry to the party that reports th= e certificate. I seem to recall reading this idea at some point, buy I adm= it 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 certific= ate, 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 co= mplex, since the log server may not support the CCID or any checking, in wh= ich cases it would always log the entry with CCID =3D1 that indicates "This= log does not perform syntax checks", or CCID=3D2 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 se= t 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 CCI= D, and the certificate passed 4 This log performed the syntax checks for the asserted CCI= D, 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 relyi= ng 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, s= ince they have been pretty consistent in saying that CT doesn't require you= to trust anyone including the log server. --_000_544B0DD62A64C1448B2DA253C011414607D375BE52TUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ, com= ments inline.

 <= /o:p>

-Rick

 

From: Trans [mailto:trans-bounces@iet= f.org] On Behalf Of Russ Housley
Sent: Saturday, October 2= 5, 2014 10:01 AM
To: Rick Andrews; Steve Kent
Cc: trans= @ietf.org
Subject: Re: [Trans] Goals and generic mis-issuance fgr= amework

 

Steve and Rick:





=

1. Certific= ate Transparency Goals and Mechanisms

 

The goals of Certificate Trans= parency (CT) are threefold: detection, deterrence, and enabling remediation= of mis-issuance of certificates. The initial focus of CT is the Web PKI co= ntext, (The Web PKI context refers to the use of a set of Certification Aut= horities (CAs) that issue X.509 certificates to web servers to enable TLS-p= rotected access by clients [cite WPKOPS?].) In the future, it is anticipate= d 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.

 

<= div style=3D'margin-left:.5in'>

CT supports detection o= f 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 elem= ents of the CT system that check certificates for syntactic and semantic mi= s-issuance, on behalf of Subjects. A Monitor may be operated by a third par= ty 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 op= tionally perform syntactic checks for some classes of certificates, but a l= og 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̵= 7;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 b= y the CAs that issue them, by the Subjects of certificates, or by anyone wi= th knowledge of the entire certificate chain.”.

 

Can't anyone bu= ild the certificate chain?  Since the logs are posting the supported t= rust anchors, anyone can build a chain for the end entity certificate.=

 

[Rick] In most cases, yes. If someone has acc= ess to the server configured with that certificate, they can do a TLS hands= hake and get the chain in nearly all cases. We see some web servers that ar= e missing the intermediate CA cert, and some browsers (IE, for example) wil= l follow the AIA extension (if it’s in the cert) and fetch the interm= ediate. Any client can do that too. But if the CA didn’t put an AIA e= xtension in the cert and you can’t find a server with that cert, it m= ight not be possible to find the intermediate CA cert. And without the inte= rmediate (or intermediates!) the log won’t accept it.

<= o:p>

&nb= sp;

To enable Monitors (and, optionally, logs) to perform an appropriate se= t of checks, the (pre-)<= /s> a CCID MUST be provided= to a log when a certificate is submitted by a CA or Subject. This CCID MUS= T 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 perf= orm 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) se= nds 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, wit= h different CCIDs. I’m not sure if 6962-bis imposes any uniqueness co= nstraint 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. &= nbsp;I seem to recall reading this idea at some point, buy I admit I did no= t look into the current I-D to see if that was where i read it.<= /p>

[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 cas= es it would always log the entry with CCID =3D1 that indicates “This = log does not perform syntax checks”, or CCID=3D2 that indicates ̶= 0;This log does not support syntax checks for the asserted CCID”.



 

A log MUST generate a Syntax Verification Value (SVV) for th= e certificate, and include the SVV in the log entry and in the SCT.<= span style=3D'font-family:"Calibri","sans-serif";color:black'>

The LVV=  *S= VV* is <= span style=3D'font-family:Courier;color:#1F497D'>*a* value specified by this document (see Section Z) that indicate= s 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 synta= x checking appears to be well-defined and thus need not be represented in a= n IANA registry. Each SCT issued by a log MUST include an SVV.  =

 = ;

 

<= /div>

Value Interpretat= ion

0      &nb= sp;          The CCID value was 0, so&nbs= p;not = *no* checks were performed

1 =             &nb= sp;   This log does not perform synta= x checks

2     &nbs= p;           This log does not support syntax checks for the asserted = CCID<= o:p>

3      &n= bsp;          This log performed the syntax checks for the asserted CCID, and= the certificate passed

4   &= nbsp;           &nbs= p; This log performed the syntax checks for the= asserted CCID, and the certificate failed

 

No other SVV values are d= efined by this RFC.

 

If the log performs some validation checks, are = you suggesting that a relying party can leverage the work already done by t= he log?  If so, it puts the log checking at a different place in the c= ertificate 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 agai= nst this, since they have been pretty consistent in saying that CT doesn= 217;t require you to trust anyone including the log server.

&nbs= p;

 

 

= --_000_544B0DD62A64C1448B2DA253C011414607D375BE52TUS1XCHEVSPIN_-- From nobody Mon Oct 27 19:09:54 2014 Return-Path: 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 E6F5F1A871D for ; Mon, 27 Oct 2014 19:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 O2ily-QrZhp8 for ; Mon, 27 Oct 2014 19:09:44 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7B91A6FBC for ; Mon, 27 Oct 2014 19:09:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,800,1406606400"; d="scan'208,217";a="2493658" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge2.cygnacom.com with ESMTP; 27 Oct 2014 22:09:40 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 22:09:40 -0400 From: Santosh Chokhani To: Rick Andrews , Russ Housley , Steve Kent Thread-Topic: [Trans] Goals and generic mis-issuance fgramework Thread-Index: AQHP5Ab2FAjCsOwr9kS2LsAemu1e1pw51z8AgAeOSQCAA4FJgP//90vg Date: Tue, 28 Oct 2014 02:09:39 +0000 Message-ID: <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> In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D375BE52@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.24.66] Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E81139243728scygexch10cygnaco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5B23rTBLSj358-kLmx-favBDZyQ Cc: "trans@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 02:09:50 -0000 --_000_4262AC0DB9856847A2D00EF817E81139243728scygexch10cygnaco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 a= re 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] 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, deterr= ence, 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?].) I= n the future, it is anticipated that addition *additional*operational conte= xts may be supported. As a result, mis-issuance is defined in an fashion th= at accommodates a range of types of certificates used in a range of context= s. CT supports detection of mis-issuance using logs of certificates, populated= by the CAs that issue them or by the Subjects of certificates. Monitors (d= escribed in Section X) are the primary elements of the CT system that check= certificates for syntactic and semantic mis-issuance, on behalf of Subject= s. 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 c= lasses of certificates, but a log is not required to offer certificate chec= king. 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 sugge= st "CT supports detection of mis-issuance using logs of certificates, popul= ated by the CAs that issue them, by the Subjects of certificates, or by any= one with knowledge of the entire certificate chain.". Can't anyone build the certificate chain? Since the logs are posting the s= upported trust anchors, anyone can build a chain for the end entity certifi= cate. [Rick] In most cases, yes. If someone has access to the server configured w= ith that certificate, they can do a TLS handshake and get the chain in near= ly 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 accep= t 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 t= he certificate class asserted by the CA or Subject. Hmm... Since anyone can send a cert to a log, the first sentence must refle= ct that. But that makes me wonder what should happen if the "Reporter" (I d= on'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 t= he cert.) Or sends the cert multiple times with different CCIDs? I guess Mo= nitors would have to expect multiple entries for a given certificate in a g= iven log, with different CCIDs. I'm not sure if 6962-bis imposes any unique= ness constraint that this might violate. Alternatively, a log could check to see if the reported certificate is alre= ady present, and if so, return the older entry to the party that reports th= e certificate. I seem to recall reading this idea at some point, buy I adm= it 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 certific= ate, 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 co= mplex, since the log server may not support the CCID or any checking, in wh= ich cases it would always log the entry with CCID =3D1 that indicates "This= log does not perform syntax checks", or CCID=3D2 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 se= t 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 CCI= D, and the certificate passed 4 This log performed the syntax checks for the asserted CCI= D, 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 relyi= ng 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, s= ince they have been pretty consistent in saying that CT doesn't require you= to trust anyone including the log server. --_000_4262AC0DB9856847A2D00EF817E81139243728scygexch10cygnaco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Relying parties relying on the checks= made by log server may be problematic if both do not have the same trust s= tore if the initialization variables are different.

 

My primary motivation in log doing ch= ecks is nip the problem in the bud and reduce the probability of relying pa= rties having to decide on exceptions.  The relying parties still should validate the certification path.

 

From: Trans [mailto:trans-bounces@ie= tf.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<= /o:p>

 

Russ, comments inline.

 

-Rick

 

 

Steve and Rick:

 

 

1. Certificate Transparency Goals and Mechanisms<= o:p>

 

The goals of Certificate Transparency (CT) are three= fold: detection, deterrence, and enabling remediation of mis-issuance of ce= rtificates. The initial focus of CT is the Web PKI context, (The Web PKI context refers to the use of a set of Ce= rtification Authorities (CAs) that issue X.509 certificates to web servers = to enable TLS-protected access by clients [cite WPKOPS?].) In the future, i= t is anticipated that = addition *additional*operational contexts may be supported. As a result, mis-issuance is defined in an fash= ion that accommodates a range of types of certificates used in a range of c= ontexts.

 

CT supports detection of mis-issuance using logs of = certificates, populated by the CAs that issue them or by the Subjects of ce= rtificates. Monitors (described in Section X) are the primary elements of the CT system that check certificates for synt= actic and semantic mis-issuance, on behalf of Subjects. A Monitor may be op= erated by a third party on behalf of Subjects, or may be operated by a Subj= ect on its own behalf. (The latter is referred to as “self-monitoring”.) Logs may optionally perf= orm syntactic checks for some classes of certificates, but a log is not req= uired 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.&= #8221;.

 

Can't anyone build the ce= rtificate chain?  Since the logs are posting the supported trust ancho= rs, anyone can build a chain for the end entity certificate.

 

[Rick]= In most cases, yes. If someone has access to the server configured with th= at certificate, they can do a TLS handshake and get the chain in nearly all cases. We see some web servers that are missin= g 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 perfor= m 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 tha= t. 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 send= s 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 di= fferent CCIDs. I’m not sure if 6962-bis imposes any uniqueness constr= aint that this might violate.<= span style=3D"font-family:Courier;color:#1F497D">  

 

Alternatively, a log coul= d check to see if the reported certificate is already present, and if so, r= eturn the older entry to the party that reports the certificate.  I se= em 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 b= it more complex, since the log server may not support the CCID or any check= ing, in which cases it would always log the entry with CCID =3D1 that indicates “This log does not perform syntax chec= ks”, or CCID=3D2 that indicates “This log does not support synt= ax 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 t= he log performed applicable syntactic checks, and whether the (pre-) certif= icate passed of *or* fai= led the checks. Although it is anticipated that new certificate classes will a= rise over time, the set of log actions with respect to syntax checking appe= ars 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  &= nbsp;           &nbs= p;  The CCID value was 0, so = not *no* checks were performed

1  &= nbsp;           &nbs= p;  This log does not perform syntax checks

2  &= nbsp;           &nbs= p;  This log does not support syntax checks for the asserted CCID

3  &= nbsp;           &nbs= p;  This log performed the syntax checks for the asserted CCID, and the certificate= passed

4  &= nbsp;           &nbs= p;  This log performed the syntax checks for the asserted CCID, and the certificate= failed

 

No other SVV values are defined by this RFC.<= span style=3D"font-family:"Calibri",sans-serif;color:black">=

 

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 d= ifferent place in the certificate validation than I was imagining.

[Rick] Yes, a relying party could lev= erage 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.

 

 

 

--_000_4262AC0DB9856847A2D00EF817E81139243728scygexch10cygnaco_-- From nobody Tue Oct 28 06:44:07 2014 Return-Path: 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 1B6241A88E0 for ; Tue, 28 Oct 2014 06:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.41 X-Spam-Level: * X-Spam-Status: No, score=1.41 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] 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 yq12qHux_Dx6 for ; Tue, 28 Oct 2014 06:43:53 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C346B1A88D8 for ; Tue, 28 Oct 2014 06:43:45 -0700 (PDT) Received: (qmail 16743 invoked by uid 1000); 28 Oct 2014 13:43:42 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 28 Oct 2014 13:43:42 +0000 Message-ID: <544F9D8D.9040502@comodo.com> Date: Tue, 28 Oct 2014 13:43:41 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Russ Housley , "trans@ietf.org" References: <64F4A6B5-83B3-4C95-B163-15F2980F3425@vigilsec.com> In-Reply-To: <64F4A6B5-83B3-4C95-B163-15F2980F3425@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/w0-yTdHabQzJAFHHBMg2Z-8UaYU Subject: Re: [Trans] Precertificate format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 13:44:05 -0000 On 25/10/14 17:51, Russ Housley wrote: > I think you are suggesting the format used in a .p7c file. If I understand correctly, I fully support this idea. Hi Russ. It's similar to .p7c in that it uses the SignedData structure. From RFC5652... SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } A .p7c is a SignedData structure that contains one or more "certificates", but nothing useful in "encapContentInfo" or "signerInfos". What we're proposing is a SignedData structure that contains zero or more "certificates" (CA certificates only), the TBSCertificate in "encapContentInfo" and a signature from the CA in "signerInfos". We'll need to define a new ContentType OID that means "TBSCertificate". > Russ > >> We (the 6962-bis editors) would like to propose that we replace the existing precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays to rest, we think, any possible confusion with X509v3 certs, whilst allowing a simple mapping between the final cert and the pre-cert. >> >> Obviously there are details to be nailed down, but before we do so, we'd like to hear any discussion on the general idea. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Tue Oct 28 09:51:05 2014 Return-Path: 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 ; 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 ; 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 ; Tue, 28 Oct 2014 09:45:57 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wp4so845623obc.25 for ; 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: From: Eran Messeri To: Santosh Chokhani Content-Type: multipart/alternative; boundary=089e01182b729d70fd05067e613d Archived-At: http://mailarchive.ietf.org/arch/msg/trans/dj9al2RfRQezbBMCIagzt0ZWglU Cc: "trans@ietf.org" , Russ Housley , Steve Kent , Rick Andrews 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:50:53 -0000 --089e01182b729d70fd05067e613d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 initializatio= n > 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 ] *O= n > 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 t= o > the use of a set of Certification Authorities (CAs) that issue X.509 > certificates to web servers to enable TLS-protected access by clients [ci= te > WPKOPS?].) In the future, it is anticipated that addition **additional**o= perational > 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 rang= e > 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, o= n > 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 =E2=80=9Cself-monitoring=E2=80=9D.) Logs may optionally pe= rform syntactic > checks for some classes of certificates, but a log is not required to off= er > certificate checking. > > The first sentence needs to be more broad, since anyone can send a cert t= o > a log. But it=E2=80=99s most likely to be the CAs or the Subjects, so I w= ould > suggest =E2=80=9CCT supports detection of mis-issuance using logs of cert= ificates, > populated by the CAs that issue them, by the Subjects of certificates, or > by anyone with knowledge of the entire certificate chain.=E2=80=9D. > > > > 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 intermedia= te > CA cert, and some browsers (IE, for example) will follow the AIA extensio= n > (if it=E2=80=99s in the cert) and fetch the intermediate. Any client can = do that > too. But if the CA didn=E2=80=99t put an AIA extension in the cert and yo= u can=E2=80=99t > find a server with that cert, it might not be possible to find the > intermediate CA cert. And without the intermediate (or intermediates!) th= e > log won=E2=80=99t 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 a= nd > 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 base= d > on the certificate class asserted by the CA or Subject. > > Hmm=E2=80=A6 Since anyone can send a cert to a log, the first sentence mu= st > reflect that. But that makes me wonder what should happen if the =E2=80= =9CReporter=E2=80=9D > (I don=E2=80=99t want to introduce a new role) sends the wrong CCID? (By = =E2=80=9Cwrong=E2=80=9D I > mean it=E2=80=99s a valid CCID, but it=E2=80=99s 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=E2=80=99m 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 poin= t, > 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 =E2=80=9CIf the log has previously seen th= e > certificate, it MAY return the same SCT as it returned before.=E2=80=9D B= ut this > would have to be expanded to say =E2=80=9CIf the log has previously seen = the > certificate *and CCID*, it MAY return the same SCT as it returned > before.=E2=80=9D It=E2=80=99s a bit more complex, since the log server ma= y not support the > CCID or any checking, in which cases it would always log the entry with > CCID =3D1 that indicates =E2=80=9CThis log does not perform syntax checks= =E2=80=9D, or CCID=3D2 > that indicates =E2=80=9CThis log does not support syntax checks for the a= sserted > CCID=E2=80=9D. > > > > > > 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 aris= e > 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=E2= =80=99t > require you to trust anyone including the log server. > > > > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --089e01182b729d70fd05067e613d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 in= dicate it failed syntactic checks.
Are you suggesting that TLS cl= ients will reject an otherwise-valid certificate chain which has a=C2=A0CCI= D that matches the TLS client's desired use of the certificate, because= the log indicated it failed syntactic checks?

It&= #39;s not a bad thing, it does place additional burden on logs though. Moni= tors will have to verify the log's honest behaviour on this aspect as w= ell.

The other question is - aren't certificat= e classes different enough to merit running different logs, where the log&#= 39;s identity (or some other metadata) indicates which CCID it's good f= or?
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@cygnaco= m.com> wrote:

Relying parties relying on the checks= made by log server may be problematic if both do not have the same trust s= tore if the initialization variables are different.

=C2=A0

My primary motivation in log doing ch= ecks is nip the problem in the bud and reduce the probability of relying pa= rties having to decide on exceptions.=C2=A0 The relying parties still should validate the certification path.=

=C2=A0

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.o= rg
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

=C2=A0

Russ, comments inline.<= /span>

=C2=A0

-Rick

=C2=A0

From: Trans= [mailto: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.o= rg
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

=C2=A0

Steve and Rick:=

=C2=A0

=C2=A0=

1. Certificate Transparency Goals and Mechanisms<= u>

=C2=A0

The goals of Certificate Transparency (CT) are three= fold: detection, deterrence, and enabling remediation of mis-issuance of ce= rtificates. The initial focus of CT is the Web PKI context, (The Web PKI context refers to the use of a set of Ce= rtification Authorities (CAs) that issue X.509 certificates to web servers = to enable TLS-protected access by clients [cite WPKOPS?].) In the future, i= t is anticipated that=C2=A0addition=C2=A0<= /span>*additional*= operational contexts may be supported. As a result, mis-issuance is defined in an fash= ion that accommodates a range of types of certificates used in a range of c= ontexts.

=C2=A0

CT supports detection of mis-issuance using logs of = certificates, populated by the CAs that issue them or by the Subjects of ce= rtificates. Monitors (described in Section=C2=A0X) are the primary elements of the CT system that check certificates for synt= actic and semantic mis-issuance, on behalf of Subjects. A Monitor may be op= erated by a third party on behalf of Subjects, or may be operated by a Subj= ect on its own behalf. (The latter is referred to as =E2=80=9Cself-monitoring=E2=80=9D.) 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=E2=80=99s most likely to be the CAs or the Subjects, so I would suggest =E2=80=9CCT supports detection of mis-issuance using lo= gs of certificates, populated by the CAs that issue them, by the Subjects o= f certificates, or by anyone with knowledge of the entire certificate chain= .=E2=80=9D.

=C2=A0

Can't anyone build th= e certificate chain?=C2=A0 Since the logs are posting the supported trust a= nchors, anyone can build a chain for the end entity certificate.<= /u>

=C2=A0

[Rick]= In most cases, yes. If someone has access to the server configured with th= at certificate, they can do a TLS handshake and get the chain in nearly all cases. We see some web servers that are missin= g the intermediate CA cert, and some browsers (IE, for example) will follow= the AIA extension (if it=E2=80=99s in the cert) and fetch the intermediate= . Any client can do that too. But if the CA didn=E2=80=99t put an AIA extension in the cert and you can=E2=80=99t f= ind a server with that cert, it might not be possible to find the intermedi= ate CA cert. And without the intermediate (or intermediates!) the log won= =E2=80=99t accept it.

=C2=A0

To enable Monitors (and, optionally, logs) to perfor= m an appropriate set of checks,=C2=A0the (pre-)= =C2=A0a 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=E2=80= =A6 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 =E2=80=9CReporter=E2=80=9D (I don=E2=80=99t want to introduce a new role) = sends the wrong CCID? (By =E2=80=9Cwrong=E2=80=9D I mean it=E2=80=99s a val= id CCID, but it=E2=80=99s not the one that the CA would associate with the = cert.) Or sends the cert multiple times with different CCIDs? I guess Monit= ors would have to expect multiple entries for a given certificate in a given log, with di= fferent CCIDs. I=E2=80=99m not sure if 6962-bis imposes any uniqueness cons= traint that this might violate.=C2=A0=C2=A0

=C2=A0

Alternatively, a log coul= d check to see if the reported certificate is already present, and if so, r= eturn the older entry to the party that reports the certificate.=C2=A0 I se= em 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 =E2=80= =9CIf the log has previously seen the certificate, it MAY return the same S= CT as it returned before.=E2=80=9D But this would have to be expanded to say =E2=80=9CIf the log has previously seen the certificate and CCID= , it MAY return the same SCT as it returned before.=E2=80=9D It=E2=80= =99s a bit more complex, since the log server may not support the CCID or a= ny checking, in which cases it would always log the entry with CCID =3D1 that indicates =E2=80=9CThis log does not perform syntax ch= ecks=E2=80=9D, or CCID=3D2 that indicates =E2=80=9CThis log does not suppor= t syntax checks for the asserted CCID=E2=80=9D.

=C2=A0

=C2=A0

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=C2=A0LVV=C2=A0*SVV*=C2=A0is=C2=A0*a*=C2=A0value specified by this document (see Section Z) that indicates whether or not t= he log performed applicable syntactic checks, and whether the (pre-) certif= icate passed=C2=A0of=C2=A0*or*=C2=A0failed the checks. Although it is anticipated that new certificate classes will a= rise over time, the set of log actions with respect to syntax checking appe= ars to be well-defined and thus need not be represented in an IANA registry= . Each SCT issued by a log MUST include an SVV. =C2=A0

=C2=A0

=C2=A0

Value Interpretation

0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0The CCID value was 0, so=C2=A0not=C2=A0*no*=C2=A0<= /span>checks were performed

1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0This log does not perform syntax checks

2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0This log does not support syntax checks for the asserted CCID<= /span>

3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0This log performed the syntax checks for the asserted CCID, and the certificate= passed

4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0This log performed the syntax checks for the asserted CCID, and the certificate= failed

=C2=A0

No other SVV values are defined by this RFC.<= span style=3D"font-family:"Calibri",sans-serif;color:black">

=C2=A0

If the log performs some = validation checks, are you suggesting that a relying party can leverage the= work already done by the log?=C2=A0 If so, it puts the log checking at a d= ifferent place in the certificate validation than I was imagining.

[Rick] Yes, a relying party could lev= erage 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=E2=80=99t require you = to trust anyone including the log server.

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans


--089e01182b729d70fd05067e613d-- From nobody Tue Oct 28 10:22:05 2014 Return-Path: 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 4A8711A90C7 for ; Tue, 28 Oct 2014 10:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Rmfo6RCCgefw for ; Tue, 28 Oct 2014 10:21:47 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C321A90CC for ; Tue, 28 Oct 2014 10:21:46 -0700 (PDT) X-AuditID: d80ac3f3-f790d6d00000101f-84-544fd0a98c4a Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 95.70.04127.9A0DF445; Tue, 28 Oct 2014 17:21:45 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1XjASk-0001UX-3G; Tue, 28 Oct 2014 17:21:42 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 28 Oct 2014 10:21:48 -0700 From: Rick Andrews To: Eran Messeri , Santosh Chokhani Date: Tue, 28 Oct 2014 10:21:28 -0700 Thread-Topic: [Trans] Goals and generic mis-issuance fgramework Thread-Index: Ac/yzy2ei+Fp+fyzTqa4lXlVHnDpqwABC5aQ Message-ID: <544B0DD62A64C1448B2DA253C011414607D375C38D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607D375C38DTUS1XCHEVSPIN_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRmVeSWpSXmKPExsVyg+vQT91VF/xDDFavYbT4/H07m8WrFzfZ LTbOZrSYeZ3bYu3jiywOrB5Tz4d6tG7/xeqxYFOpx5IlP5k8Vt35whrAGsVlk5Kak1mWWqRv l8CVMXn+ItaCTw+ZKj4c3sLYwHjlBlMXIweHhICJxIaLgV2MnECmmMSFe+vZuhi5OIQE3jFK vN80nxHCecUo8eT7XRYIZxWjxMJLbYwgLWwCehJbHl9hB7FFBPwkdl5dzQxiMwukSxyf85AF xGYRUJWYPv8NG4gtLGAn0fvyHjNEvb3E2a3rmCBsI4mFsxaD1fAKREmcureIGWJZB7PEvCWL wBKcAoESL/efAFvMCHTr91NrmCCWiUvcejKfCeIHAYkle84zQ9iiEi8f/2OFqBeVuNO+nhGi Pl9idcccJohlghInZz5hgaiXlDi44gbLBEbxWUjGzkLSMgtJyyxg6DELaEqs36UPUaIoMaX7 ITuErSHROmcuO7L4Akb2VYwyJaXFhsW5JfmlJQWpFQbGesWVuYnAGE/WS87P3cQIjvPDn3cw /t7jeIhRgINRiYf33Un/ECHWxDKgykOMEhzMSiK8YbuBQrwpiZVVqUX58UWlOanFhxilOViU xHn/VNiFCAmkJ5akZqemFqQWwWSZODilGhh5D/4SXfTJmmWt06vZXA720SerfFpTvI4npJzb M63pbtf6W/9uMldpfGZSmuuaE1Rwxebqjk28heV+tm3nl/NtUq5zmjh/2WKPhC0mca6fXt3I 70132G0kdszB6IdE54naFSWl6RJrYxk0m9yK3ohrNbUHNjzXCSzaYP9g75qdL1tTEy6v9FZi Kc5INNRiLipOBAC6hY1D7wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/trans/aUWDbFMCXqCXucsspS8lvWtrJ3c Cc: "trans@ietf.org" , Russ Housley , Steve Kent 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:21:58 -0000 --_000_544B0DD62A64C1448B2DA253C011414607D375C38DTUS1XCHEVSPIN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJhbiwgdGhlcmUgbWF5IGJlIG5vIGRpcmVjdCBiZW5lZml0cyB0byB0aGUgVExTIGNsaWVudCwg YnV0IGluZGlyZWN0IGJlbmVmaXRzIGNvdWxkIGFjY3J1ZSBpZiBDQXMgZG9u4oCZdCBpc3N1ZSBj ZXJ0IHRoYXQgZmFpbCBhIGxvZ+KAmXMgc3ludGFjdGljIGNoZWNrcy4NCg0KLVJpY2sNCg0KRnJv bTogRXJhbiBNZXNzZXJpIFttYWlsdG86ZXJhbm1AZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXks IE9jdG9iZXIgMjgsIDIwMTQgOTo0NiBBTQ0KVG86IFNhbnRvc2ggQ2hva2hhbmkNCkNjOiBSaWNr IEFuZHJld3M7IFJ1c3MgSG91c2xleTsgU3RldmUgS2VudDsgdHJhbnNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbVHJhbnNdIEdvYWxzIGFuZCBnZW5lcmljIG1pcy1pc3N1YW5jZSBmZ3JhbWV3b3Jr DQoNCk92ZXJhbGwgdGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgc2VlbXMgcmVhc29uYWJsZS4gQ2Fu IHlvdSBoZWxwIG1lIHVuZGVyc3RhbmQgdGhlIGJlbmVmaXRzIGZyb20gdGhlIFRMUyBjbGllbnQn cyBwZXJzcGVjdGl2ZT8NCklJVUMsIHRoZSBsb2cgd2lsbCBuZXZlciByZWZ1c2UgdG8gaW5jbHVk ZSBhIGNlcnRpZmljYXRlLCBpdCB3aWxsIG1lcmVseSBpbmRpY2F0ZSBpdCBmYWlsZWQgc3ludGFj dGljIGNoZWNrcy4NCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IFRMUyBjbGllbnRzIHdpbGwgcmVq ZWN0IGFuIG90aGVyd2lzZS12YWxpZCBjZXJ0aWZpY2F0ZSBjaGFpbiB3aGljaCBoYXMgYSBDQ0lE IHRoYXQgbWF0Y2hlcyB0aGUgVExTIGNsaWVudCdzIGRlc2lyZWQgdXNlIG9mIHRoZSBjZXJ0aWZp Y2F0ZSwgYmVjYXVzZSB0aGUgbG9nIGluZGljYXRlZCBpdCBmYWlsZWQgc3ludGFjdGljIGNoZWNr cz8NCg0KSXQncyBub3QgYSBiYWQgdGhpbmcsIGl0IGRvZXMgcGxhY2UgYWRkaXRpb25hbCBidXJk ZW4gb24gbG9ncyB0aG91Z2guIE1vbml0b3JzIHdpbGwgaGF2ZSB0byB2ZXJpZnkgdGhlIGxvZydz IGhvbmVzdCBiZWhhdmlvdXIgb24gdGhpcyBhc3BlY3QgYXMgd2VsbC4NCg0KVGhlIG90aGVyIHF1 ZXN0aW9uIGlzIC0gYXJlbid0IGNlcnRpZmljYXRlIGNsYXNzZXMgZGlmZmVyZW50IGVub3VnaCB0 byBtZXJpdCBydW5uaW5nIGRpZmZlcmVudCBsb2dzLCB3aGVyZSB0aGUgbG9nJ3MgaWRlbnRpdHkg KG9yIHNvbWUgb3RoZXIgbWV0YWRhdGEpIGluZGljYXRlcyB3aGljaCBDQ0lEIGl0J3MgZ29vZCBm b3I/DQpJJ20gYSBiaXQgd2Vhcnkgb2Ygc3BlY2lmeWluZyBhIGJlaGF2aW91ciBmb3IgdGhlIGdl bmVyYWwgY2FzZSB3aGVyZSBJIGRvbid0IGhhdmUgY29uY3JldGUgZXhhbXBsZXMgZm9yIG1vcmUg dGhhbiBvbmUgcGFydGljdWxhciBjYXNlLg0KDQpPbiBUdWUsIE9jdCAyOCwgMjAxNCBhdCAyOjA5 IEFNLCBTYW50b3NoIENob2toYW5pIDxzY2hva2hhbmlAY3lnbmFjb20uY29tPG1haWx0bzpzY2hv a2hhbmlAY3lnbmFjb20uY29tPj4gd3JvdGU6DQpSZWx5aW5nIHBhcnRpZXMgcmVseWluZyBvbiB0 aGUgY2hlY2tzIG1hZGUgYnkgbG9nIHNlcnZlciBtYXkgYmUgcHJvYmxlbWF0aWMgaWYgYm90aCBk byBub3QgaGF2ZSB0aGUgc2FtZSB0cnVzdCBzdG9yZSBpZiB0aGUgaW5pdGlhbGl6YXRpb24gdmFy aWFibGVzIGFyZSBkaWZmZXJlbnQuDQoNCk15IHByaW1hcnkgbW90aXZhdGlvbiBpbiBsb2cgZG9p bmcgY2hlY2tzIGlzIG5pcCB0aGUgcHJvYmxlbSBpbiB0aGUgYnVkIGFuZCByZWR1Y2UgdGhlIHBy b2JhYmlsaXR5IG9mIHJlbHlpbmcgcGFydGllcyBoYXZpbmcgdG8gZGVjaWRlIG9uIGV4Y2VwdGlv bnMuICBUaGUgcmVseWluZyBwYXJ0aWVzIHN0aWxsIHNob3VsZCB2YWxpZGF0ZSB0aGUgY2VydGlm aWNhdGlvbiBwYXRoLg0KDQpGcm9tOiBUcmFucyBbbWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUmljayBBbmRy ZXdzDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjcsIDIwMTQgNjozMyBQTQ0KVG86IFJ1c3MgSG91 c2xleTsgU3RldmUgS2VudA0KDQpDYzogdHJhbnNAaWV0Zi5vcmc8bWFpbHRvOnRyYW5zQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNl IGZncmFtZXdvcmsNCg0KUnVzcywgY29tbWVudHMgaW5saW5lLg0KDQotUmljaw0KDQpGcm9tOiBU cmFucyBbbWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSdXNzIEhv dXNsZXkNClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDI1LCAyMDE0IDEwOjAxIEFNDQpUbzogUmlj ayBBbmRyZXdzOyBTdGV2ZSBLZW50DQpDYzogdHJhbnNAaWV0Zi5vcmc8bWFpbHRvOnRyYW5zQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3Vh bmNlIGZncmFtZXdvcmsNCg0KU3RldmUgYW5kIFJpY2s6DQoNCg0KMS4gQ2VydGlmaWNhdGUgVHJh bnNwYXJlbmN5IEdvYWxzIGFuZCBNZWNoYW5pc21zDQoNClRoZSBnb2FscyBvZiBDZXJ0aWZpY2F0 ZSBUcmFuc3BhcmVuY3kgKENUKSBhcmUgdGhyZWVmb2xkOiBkZXRlY3Rpb24sIGRldGVycmVuY2Us IGFuZCBlbmFibGluZyByZW1lZGlhdGlvbiBvZiBtaXMtaXNzdWFuY2Ugb2YgY2VydGlmaWNhdGVz LiBUaGUgaW5pdGlhbCBmb2N1cyBvZiBDVCBpcyB0aGUgV2ViIFBLSSBjb250ZXh0LCAoVGhlIFdl YiBQS0kgY29udGV4dCByZWZlcnMgdG8gdGhlIHVzZSBvZiBhIHNldCBvZiBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0aWVzIChDQXMpIHRoYXQgaXNzdWUgWC41MDkgY2VydGlmaWNhdGVzIHRvIHdlYiBz ZXJ2ZXJzIHRvIGVuYWJsZSBUTFMtcHJvdGVjdGVkIGFjY2VzcyBieSBjbGllbnRzIFtjaXRlIFdQ S09QUz9dLikgSW4gdGhlIGZ1dHVyZSwgaXQgaXMgYW50aWNpcGF0ZWQgdGhhdCBhZGRpdGlvbiAq YWRkaXRpb25hbCpvcGVyYXRpb25hbCBjb250ZXh0cyBtYXkgYmUgc3VwcG9ydGVkLiBBcyBhIHJl c3VsdCwgbWlzLWlzc3VhbmNlIGlzIGRlZmluZWQgaW4gYW4gZmFzaGlvbiB0aGF0IGFjY29tbW9k YXRlcyBhIHJhbmdlIG9mIHR5cGVzIG9mIGNlcnRpZmljYXRlcyB1c2VkIGluIGEgcmFuZ2Ugb2Yg Y29udGV4dHMuDQoNCkNUIHN1cHBvcnRzIGRldGVjdGlvbiBvZiBtaXMtaXNzdWFuY2UgdXNpbmcg bG9ncyBvZiBjZXJ0aWZpY2F0ZXMsIHBvcHVsYXRlZCBieSB0aGUgQ0FzIHRoYXQgaXNzdWUgdGhl bSBvciBieSB0aGUgU3ViamVjdHMgb2YgY2VydGlmaWNhdGVzLiBNb25pdG9ycyAoZGVzY3JpYmVk IGluIFNlY3Rpb24gWCkgYXJlIHRoZSBwcmltYXJ5IGVsZW1lbnRzIG9mIHRoZSBDVCBzeXN0ZW0g dGhhdCBjaGVjayBjZXJ0aWZpY2F0ZXMgZm9yIHN5bnRhY3RpYyBhbmQgc2VtYW50aWMgbWlzLWlz c3VhbmNlLCBvbiBiZWhhbGYgb2YgU3ViamVjdHMuIEEgTW9uaXRvciBtYXkgYmUgb3BlcmF0ZWQg YnkgYSB0aGlyZCBwYXJ0eSBvbiBiZWhhbGYgb2YgU3ViamVjdHMsIG9yIG1heSBiZSBvcGVyYXRl ZCBieSBhIFN1YmplY3Qgb24gaXRzIG93biBiZWhhbGYuIChUaGUgbGF0dGVyIGlzIHJlZmVycmVk IHRvIGFzIOKAnHNlbGYtbW9uaXRvcmluZ+KAnS4pIExvZ3MgbWF5IG9wdGlvbmFsbHkgcGVyZm9y bSBzeW50YWN0aWMgY2hlY2tzIGZvciBzb21lIGNsYXNzZXMgb2YgY2VydGlmaWNhdGVzLCBidXQg YSBsb2cgaXMgbm90IHJlcXVpcmVkIHRvIG9mZmVyIGNlcnRpZmljYXRlIGNoZWNraW5nLg0KVGhl IGZpcnN0IHNlbnRlbmNlIG5lZWRzIHRvIGJlIG1vcmUgYnJvYWQsIHNpbmNlIGFueW9uZSBjYW4g c2VuZCBhIGNlcnQgdG8gYSBsb2cuIEJ1dCBpdOKAmXMgbW9zdCBsaWtlbHkgdG8gYmUgdGhlIENB cyBvciB0aGUgU3ViamVjdHMsIHNvIEkgd291bGQgc3VnZ2VzdCDigJxDVCBzdXBwb3J0cyBkZXRl Y3Rpb24gb2YgbWlzLWlzc3VhbmNlIHVzaW5nIGxvZ3Mgb2YgY2VydGlmaWNhdGVzLCBwb3B1bGF0 ZWQgYnkgdGhlIENBcyB0aGF0IGlzc3VlIHRoZW0sIGJ5IHRoZSBTdWJqZWN0cyBvZiBjZXJ0aWZp Y2F0ZXMsIG9yIGJ5IGFueW9uZSB3aXRoIGtub3dsZWRnZSBvZiB0aGUgZW50aXJlIGNlcnRpZmlj YXRlIGNoYWluLuKAnS4NCg0KQ2FuJ3QgYW55b25lIGJ1aWxkIHRoZSBjZXJ0aWZpY2F0ZSBjaGFp bj8gIFNpbmNlIHRoZSBsb2dzIGFyZSBwb3N0aW5nIHRoZSBzdXBwb3J0ZWQgdHJ1c3QgYW5jaG9y cywgYW55b25lIGNhbiBidWlsZCBhIGNoYWluIGZvciB0aGUgZW5kIGVudGl0eSBjZXJ0aWZpY2F0 ZS4NCg0KW1JpY2tdIEluIG1vc3QgY2FzZXMsIHllcy4gSWYgc29tZW9uZSBoYXMgYWNjZXNzIHRv IHRoZSBzZXJ2ZXIgY29uZmlndXJlZCB3aXRoIHRoYXQgY2VydGlmaWNhdGUsIHRoZXkgY2FuIGRv IGEgVExTIGhhbmRzaGFrZSBhbmQgZ2V0IHRoZSBjaGFpbiBpbiBuZWFybHkgYWxsIGNhc2VzLiBX ZSBzZWUgc29tZSB3ZWIgc2VydmVycyB0aGF0IGFyZSBtaXNzaW5nIHRoZSBpbnRlcm1lZGlhdGUg Q0EgY2VydCwgYW5kIHNvbWUgYnJvd3NlcnMgKElFLCBmb3IgZXhhbXBsZSkgd2lsbCBmb2xsb3cg dGhlIEFJQSBleHRlbnNpb24gKGlmIGl04oCZcyBpbiB0aGUgY2VydCkgYW5kIGZldGNoIHRoZSBp bnRlcm1lZGlhdGUuIEFueSBjbGllbnQgY2FuIGRvIHRoYXQgdG9vLiBCdXQgaWYgdGhlIENBIGRp ZG7igJl0IHB1dCBhbiBBSUEgZXh0ZW5zaW9uIGluIHRoZSBjZXJ0IGFuZCB5b3UgY2Fu4oCZdCBm aW5kIGEgc2VydmVyIHdpdGggdGhhdCBjZXJ0LCBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgdG8g ZmluZCB0aGUgaW50ZXJtZWRpYXRlIENBIGNlcnQuIEFuZCB3aXRob3V0IHRoZSBpbnRlcm1lZGlh dGUgKG9yIGludGVybWVkaWF0ZXMhKSB0aGUgbG9nIHdvbuKAmXQgYWNjZXB0IGl0Lg0KDQpUbyBl bmFibGUgTW9uaXRvcnMgKGFuZCwgb3B0aW9uYWxseSwgbG9ncykgdG8gcGVyZm9ybSBhbiBhcHBy b3ByaWF0ZSBzZXQgb2YgY2hlY2tzLCB0aGUgKHByZS0pIGEgQ0NJRCBNVVNUIGJlIHByb3ZpZGVk IHRvIGEgbG9nIHdoZW4gYSBjZXJ0aWZpY2F0ZSBpcyBzdWJtaXR0ZWQgYnkgYSBDQSBvciBTdWJq ZWN0LiBUaGlzIENDSUQgTVVTVCBhcHBlYXIgaW4gdGhlIGxvZyBlbnRyeSBhbmQgaW4gdGhlIFND VCBnZW5lcmF0ZWQgYnkgdGhlIGxvZy4gQnkgcHJvdmlkaW5nIHRoZSBDQ0lEIGluIGxvZ3MgYW5k IFNDVHMsIGJvdGggTW9uaXRvcnMgYW5kIGNsaWVudHMgYXJlIGVtcG93ZXJlZCB0byBwZXJmb3Jt IGFwcGxpY2FibGUgY2hlY2tzIGJhc2VkIG9uIHRoZSBjZXJ0aWZpY2F0ZSBjbGFzcyBhc3NlcnRl ZCBieSB0aGUgQ0Egb3IgU3ViamVjdC4NCkhtbeKApiBTaW5jZSBhbnlvbmUgY2FuIHNlbmQgYSBj ZXJ0IHRvIGEgbG9nLCB0aGUgZmlyc3Qgc2VudGVuY2UgbXVzdCByZWZsZWN0IHRoYXQuIEJ1dCB0 aGF0IG1ha2VzIG1lIHdvbmRlciB3aGF0IHNob3VsZCBoYXBwZW4gaWYgdGhlIOKAnFJlcG9ydGVy 4oCdIChJIGRvbuKAmXQgd2FudCB0byBpbnRyb2R1Y2UgYSBuZXcgcm9sZSkgc2VuZHMgdGhlIHdy b25nIENDSUQ/IChCeSDigJx3cm9uZ+KAnSBJIG1lYW4gaXTigJlzIGEgdmFsaWQgQ0NJRCwgYnV0 IGl04oCZcyBub3QgdGhlIG9uZSB0aGF0IHRoZSBDQSB3b3VsZCBhc3NvY2lhdGUgd2l0aCB0aGUg Y2VydC4pIE9yIHNlbmRzIHRoZSBjZXJ0IG11bHRpcGxlIHRpbWVzIHdpdGggZGlmZmVyZW50IEND SURzPyBJIGd1ZXNzIE1vbml0b3JzIHdvdWxkIGhhdmUgdG8gZXhwZWN0IG11bHRpcGxlIGVudHJp ZXMgZm9yIGEgZ2l2ZW4gY2VydGlmaWNhdGUgaW4gYSBnaXZlbiBsb2csIHdpdGggZGlmZmVyZW50 IENDSURzLiBJ4oCZbSBub3Qgc3VyZSBpZiA2OTYyLWJpcyBpbXBvc2VzIGFueSB1bmlxdWVuZXNz IGNvbnN0cmFpbnQgdGhhdCB0aGlzIG1pZ2h0IHZpb2xhdGUuDQoNCkFsdGVybmF0aXZlbHksIGEg bG9nIGNvdWxkIGNoZWNrIHRvIHNlZSBpZiB0aGUgcmVwb3J0ZWQgY2VydGlmaWNhdGUgaXMgYWxy ZWFkeSBwcmVzZW50LCBhbmQgaWYgc28sIHJldHVybiB0aGUgb2xkZXIgZW50cnkgdG8gdGhlIHBh cnR5IHRoYXQgcmVwb3J0cyB0aGUgY2VydGlmaWNhdGUuICBJIHNlZW0gdG8gcmVjYWxsIHJlYWRp bmcgdGhpcyBpZGVhIGF0IHNvbWUgcG9pbnQsIGJ1eSBJIGFkbWl0IEkgZGlkIG5vdCBsb29rIGlu dG8gdGhlIGN1cnJlbnQgSS1EIHRvIHNlZSBpZiB0aGF0IHdhcyB3aGVyZSBpIHJlYWQgaXQuDQpb Umlja10gUkZDIDY5NjIgYW5kIGJpcy0wNCBzYXkg4oCcSWYgdGhlIGxvZyBoYXMgcHJldmlvdXNs eSBzZWVuIHRoZSBjZXJ0aWZpY2F0ZSwgaXQgTUFZIHJldHVybiB0aGUgc2FtZSBTQ1QgYXMgaXQg cmV0dXJuZWQgYmVmb3JlLuKAnSBCdXQgdGhpcyB3b3VsZCBoYXZlIHRvIGJlIGV4cGFuZGVkIHRv IHNheSDigJxJZiB0aGUgbG9nIGhhcyBwcmV2aW91c2x5IHNlZW4gdGhlIGNlcnRpZmljYXRlIGFu ZCBDQ0lELCBpdCBNQVkgcmV0dXJuIHRoZSBzYW1lIFNDVCBhcyBpdCByZXR1cm5lZCBiZWZvcmUu 4oCdIEl04oCZcyBhIGJpdCBtb3JlIGNvbXBsZXgsIHNpbmNlIHRoZSBsb2cgc2VydmVyIG1heSBu b3Qgc3VwcG9ydCB0aGUgQ0NJRCBvciBhbnkgY2hlY2tpbmcsIGluIHdoaWNoIGNhc2VzIGl0IHdv dWxkIGFsd2F5cyBsb2cgdGhlIGVudHJ5IHdpdGggQ0NJRCA9MSB0aGF0IGluZGljYXRlcyDigJxU aGlzIGxvZyBkb2VzIG5vdCBwZXJmb3JtIHN5bnRheCBjaGVja3PigJ0sIG9yIENDSUQ9MiB0aGF0 IGluZGljYXRlcyDigJxUaGlzIGxvZyBkb2VzIG5vdCBzdXBwb3J0IHN5bnRheCBjaGVja3MgZm9y IHRoZSBhc3NlcnRlZCBDQ0lE4oCdLg0KDQoNCkEgbG9nIE1VU1QgZ2VuZXJhdGUgYSBTeW50YXgg VmVyaWZpY2F0aW9uIFZhbHVlIChTVlYpIGZvciB0aGUgY2VydGlmaWNhdGUsIGFuZCBpbmNsdWRl IHRoZSBTVlYgaW4gdGhlIGxvZyBlbnRyeSBhbmQgaW4gdGhlIFNDVC4NClRoZSBMVlYgKlNWViog aXMgKmEqIHZhbHVlIHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50IChzZWUgU2VjdGlvbiBaKSB0 aGF0IGluZGljYXRlcyB3aGV0aGVyIG9yIG5vdCB0aGUgbG9nIHBlcmZvcm1lZCBhcHBsaWNhYmxl IHN5bnRhY3RpYyBjaGVja3MsIGFuZCB3aGV0aGVyIHRoZSAocHJlLSkgY2VydGlmaWNhdGUgcGFz c2VkIG9mICpvciogZmFpbGVkIHRoZSBjaGVja3MuIEFsdGhvdWdoIGl0IGlzIGFudGljaXBhdGVk IHRoYXQgbmV3IGNlcnRpZmljYXRlIGNsYXNzZXMgd2lsbCBhcmlzZSBvdmVyIHRpbWUsIHRoZSBz ZXQgb2YgbG9nIGFjdGlvbnMgd2l0aCByZXNwZWN0IHRvIHN5bnRheCBjaGVja2luZyBhcHBlYXJz IHRvIGJlIHdlbGwtZGVmaW5lZCBhbmQgdGh1cyBuZWVkIG5vdCBiZSByZXByZXNlbnRlZCBpbiBh biBJQU5BIHJlZ2lzdHJ5LiBFYWNoIFNDVCBpc3N1ZWQgYnkgYSBsb2cgTVVTVCBpbmNsdWRlIGFu IFNWVi4NCg0KDQpWYWx1ZSBJbnRlcnByZXRhdGlvbg0KMCAgICAgICAgICAgICAgICAgVGhlIEND SUQgdmFsdWUgd2FzIDAsIHNvIG5vdCAqbm8qIGNoZWNrcyB3ZXJlIHBlcmZvcm1lZA0KMSAgICAg ICAgICAgICAgICAgVGhpcyBsb2cgZG9lcyBub3QgcGVyZm9ybSBzeW50YXggY2hlY2tzDQoyICAg ICAgICAgICAgICAgICBUaGlzIGxvZyBkb2VzIG5vdCBzdXBwb3J0IHN5bnRheCBjaGVja3MgZm9y IHRoZSBhc3NlcnRlZCBDQ0lEDQozICAgICAgICAgICAgICAgICBUaGlzIGxvZyBwZXJmb3JtZWQg dGhlIHN5bnRheCBjaGVja3MgZm9yIHRoZSBhc3NlcnRlZCBDQ0lELCBhbmQgdGhlIGNlcnRpZmlj YXRlIHBhc3NlZA0KNCAgICAgICAgICAgICAgICAgVGhpcyBsb2cgcGVyZm9ybWVkIHRoZSBzeW50 YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQgQ0NJRCwgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBmYWls ZWQNCg0KTm8gb3RoZXIgU1ZWIHZhbHVlcyBhcmUgZGVmaW5lZCBieSB0aGlzIFJGQy4NCg0KSWYg dGhlIGxvZyBwZXJmb3JtcyBzb21lIHZhbGlkYXRpb24gY2hlY2tzLCBhcmUgeW91IHN1Z2dlc3Rp bmcgdGhhdCBhIHJlbHlpbmcgcGFydHkgY2FuIGxldmVyYWdlIHRoZSB3b3JrIGFscmVhZHkgZG9u ZSBieSB0aGUgbG9nPyAgSWYgc28sIGl0IHB1dHMgdGhlIGxvZyBjaGVja2luZyBhdCBhIGRpZmZl cmVudCBwbGFjZSBpbiB0aGUgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiB0aGFuIEkgd2FzIGltYWdp bmluZy4NCltSaWNrXSBZZXMsIGEgcmVseWluZyBwYXJ0eSBjb3VsZCBsZXZlcmFnZSB0aGUgd29y ayBhbHJlYWR5IGRvbmUgYnkgdGhlIGxvZyBzZXJ2ZXIsIGlmIHRoZSBSUCB0cnVzdGVkIGl0LiBH b29nbGUgd291bGQgcHJvYmFibHkgYWR2aXNlIGFnYWluc3QgdGhpcywgc2luY2UgdGhleSBoYXZl IGJlZW4gcHJldHR5IGNvbnNpc3RlbnQgaW4gc2F5aW5nIHRoYXQgQ1QgZG9lc27igJl0IHJlcXVp cmUgeW91IHRvIHRydXN0IGFueW9uZSBpbmNsdWRpbmcgdGhlIGxvZyBzZXJ2ZXIuDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUcmFucyBt YWlsaW5nIGxpc3QNClRyYW5zQGlldGYub3JnPG1haWx0bzpUcmFuc0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMNCg0K --_000_544B0DD62A64C1448B2DA253C011414607D375C38DTUS1XCHEVSPIN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglw YW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9 RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FcmFuLCB0aGVyZSBtYXkgYmUg bm8gZGlyZWN0IGJlbmVmaXRzIHRvIHRoZSBUTFMgY2xpZW50LCBidXQgaW5kaXJlY3QgYmVuZWZp dHMgY291bGQgYWNjcnVlIGlmIENBcyBkb27igJl0IGlzc3VlIGNlcnQgdGhhdCBmYWlsIGEgbG9n 4oCZcyBzeW50YWN0aWMgY2hlY2tzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LVJpY2s8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gRXJhbiBNZXNz ZXJpIFttYWlsdG86ZXJhbm1AZ29vZ2xlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBP Y3RvYmVyIDI4LCAyMDE0IDk6NDYgQU08YnI+PGI+VG86PC9iPiBTYW50b3NoIENob2toYW5pPGJy PjxiPkNjOjwvYj4gUmljayBBbmRyZXdzOyBSdXNzIEhvdXNsZXk7IFN0ZXZlIEtlbnQ7IHRyYW5z QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW1RyYW5zXSBHb2FscyBhbmQgZ2VuZXJp YyBtaXMtaXNzdWFuY2UgZmdyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5PdmVyYWxsIHRo ZSBtZWNoYW5pc20gZGVzY3JpYmVkIHNlZW1zIHJlYXNvbmFibGUuIENhbiB5b3UgaGVscCBtZSB1 bmRlcnN0YW5kIHRoZSBiZW5lZml0cyBmcm9tIHRoZSBUTFMgY2xpZW50J3MgcGVyc3BlY3RpdmU/ PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPklJVUMsIHRoZSBsb2cgd2lsbCBuZXZlciByZWZ1c2UgdG8gaW5jbHVkZSBhIGNlcnRp ZmljYXRlLCBpdCB3aWxsIG1lcmVseSBpbmRpY2F0ZSBpdCBmYWlsZWQgc3ludGFjdGljIGNoZWNr cy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbic+QXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgVExTIGNsaWVudHMgd2lsbCBy ZWplY3QgYW4gb3RoZXJ3aXNlLXZhbGlkIGNlcnRpZmljYXRlIGNoYWluIHdoaWNoIGhhcyBhJm5i c3A7Q0NJRCB0aGF0IG1hdGNoZXMgdGhlIFRMUyBjbGllbnQncyBkZXNpcmVkIHVzZSBvZiB0aGUg Y2VydGlmaWNhdGUsIGJlY2F1c2UgdGhlIGxvZyBpbmRpY2F0ZWQgaXQgZmFpbGVkIHN5bnRhY3Rp YyBjaGVja3M/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5JdCdzIG5vdCBhIGJhZCB0 aGluZywgaXQgZG9lcyBwbGFjZSBhZGRpdGlvbmFsIGJ1cmRlbiBvbiBsb2dzIHRob3VnaC4gTW9u aXRvcnMgd2lsbCBoYXZlIHRvIHZlcmlmeSB0aGUgbG9nJ3MgaG9uZXN0IGJlaGF2aW91ciBvbiB0 aGlzIGFzcGVjdCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+VGhlIG90 aGVyIHF1ZXN0aW9uIGlzIC0gYXJlbid0IGNlcnRpZmljYXRlIGNsYXNzZXMgZGlmZmVyZW50IGVu b3VnaCB0byBtZXJpdCBydW5uaW5nIGRpZmZlcmVudCBsb2dzLCB3aGVyZSB0aGUgbG9nJ3MgaWRl bnRpdHkgKG9yIHNvbWUgb3RoZXIgbWV0YWRhdGEpIGluZGljYXRlcyB3aGljaCBDQ0lEIGl0J3Mg Z29vZCBmb3I/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPkknbSBhIGJpdCB3ZWFyeSBvZiBzcGVjaWZ5aW5nIGEgYmVo YXZpb3VyIGZvciB0aGUgZ2VuZXJhbCBjYXNlIHdoZXJlIEkgZG9uJ3QgaGF2ZSBjb25jcmV0ZSBl eGFtcGxlcyBmb3IgbW9yZSB0aGFuIG9uZSBwYXJ0aWN1bGFyIGNhc2UuPG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDouNWluJz5PbiBUdWUsIE9jdCAyOCwgMjAxNCBhdCAyOjA5IEFNLCBTYW50b3No IENob2toYW5pICZsdDs8YSBocmVmPSJtYWlsdG86c2Nob2toYW5pQGN5Z25hY29tLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnNjaG9raGFuaUBjeWduYWNvbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJlbHlpbmcgcGFydGllcyByZWx5aW5nIG9uIHRoZSBjaGVj a3MgbWFkZSBieSBsb2cgc2VydmVyIG1heSBiZSBwcm9ibGVtYXRpYyBpZiBib3RoIGRvIG5vdCBo YXZlIHRoZSBzYW1lIHRydXN0IHN0b3JlIGlmIHRoZSBpbml0aWFsaXphdGlvbiB2YXJpYWJsZXMg YXJlIGRpZmZlcmVudC48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+TXkgcHJpbWFyeSBtb3RpdmF0aW9uIGluIGxvZyBkb2luZyBjaGVja3Mg aXMgbmlwIHRoZSBwcm9ibGVtIGluIHRoZSBidWQgYW5kIHJlZHVjZSB0aGUgcHJvYmFiaWxpdHkg b2YgcmVseWluZyBwYXJ0aWVzIGhhdmluZyB0byBkZWNpZGUgb24gZXhjZXB0aW9ucy4mbmJzcDsg VGhlIHJlbHlpbmcgcGFydGllcyBzdGlsbCBzaG91bGQgdmFsaWRhdGUgdGhlIGNlcnRpZmljYXRp b24gcGF0aC48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4gVHJh bnMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHJhbnMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9i PlJpY2sgQW5kcmV3czxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDI3LCAyMDE0IDY6 MzMgUE08YnI+PGI+VG86PC9iPiBSdXNzIEhvdXNsZXk7IFN0ZXZlIEtlbnQ8L3NwYW4+PG86cD48 L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRyYW5zQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dHJhbnNAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW1Ry YW5zXSBHb2FscyBhbmQgZ2VuZXJpYyBtaXMtaXNzdWFuY2UgZmdyYW1ld29yazxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SdXNzLCBjb21tZW50 cyBpbmxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPi1SaWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gVHJhbnMgWzxhIGhyZWY9Im1haWx0bzp0cmFucy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYg T2YgPC9iPlJ1c3MgSG91c2xleTxicj48Yj5TZW50OjwvYj4gU2F0dXJkYXksIE9jdG9iZXIgMjUs IDIwMTQgMTA6MDEgQU08YnI+PGI+VG86PC9iPiBSaWNrIEFuZHJld3M7IFN0ZXZlIEtlbnQ8YnI+ PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50cmFuc0BpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbVHJhbnNdIEdvYWxz IGFuZCBnZW5lcmljIG1pcy1pc3N1YW5jZSBmZ3JhbWV3b3JrPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4nPiZuYnNw OzxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjEuMGluJz5TdGV2ZSBhbmQgUmljazo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0OjEuMGluJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MS4waW4nPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OkNvdXJpZXI7Y29sb3I6YmxhY2snPjEuIENlcnRpZmljYXRlIFRyYW5zcGFyZW5jeSBHb2FscyBh bmQgTWVjaGFuaXNtczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluJz48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrJz5UaGUgZ29hbHMgb2YgQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5 IChDVCkgYXJlIHRocmVlZm9sZDogZGV0ZWN0aW9uLCBkZXRlcnJlbmNlLCBhbmQgZW5hYmxpbmcg cmVtZWRpYXRpb24gb2YgbWlzLWlzc3VhbmNlIG9mIGNlcnRpZmljYXRlcy4gVGhlIGluaXRpYWwg Zm9jdXMgb2YgQ1QgaXMgdGhlIFdlYiBQS0kgY29udGV4dCwgKFRoZSBXZWIgUEtJIGNvbnRleHQg cmVmZXJzIHRvIHRoZSB1c2Ugb2YgYSBzZXQgb2YgQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllcyAo Q0FzKSB0aGF0IGlzc3VlIFguNTA5IGNlcnRpZmljYXRlcyB0byB3ZWIgc2VydmVycyB0byBlbmFi bGUgVExTLXByb3RlY3RlZCBhY2Nlc3MgYnkgY2xpZW50cyBbY2l0ZSBXUEtPUFM/XS4pIEluIHRo ZSBmdXR1cmUsIGl0IGlzIGFudGljaXBhdGVkIHRoYXQmbmJzcDs8cz5hZGRpdGlvbjwvcz4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6IzFGNDk3RCc+ KjxiPmFkZGl0aW9uYWw8L2I+Kjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayc+b3BlcmF0aW9uYWwgY29udGV4dHMgbWF5IGJlIHN1cHBvcnRlZC4gQXMg YSByZXN1bHQsIG1pcy1pc3N1YW5jZSBpcyBkZWZpbmVkIGluIGFuIGZhc2hpb24gdGhhdCBhY2Nv bW1vZGF0ZXMgYSByYW5nZSBvZiB0eXBlcyBvZiBjZXJ0aWZpY2F0ZXMgdXNlZCBpbiBhIHJhbmdl IG9mIGNvbnRleHRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluJz48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrJz5DVCBzdXBwb3J0cyBkZXRlY3Rpb24gb2YgbWlzLWlzc3VhbmNl IHVzaW5nIGxvZ3Mgb2YgY2VydGlmaWNhdGVzLCBwb3B1bGF0ZWQgYnkgdGhlIENBcyB0aGF0IGlz c3VlIHRoZW0gb3IgYnkgdGhlIFN1YmplY3RzIG9mIGNlcnRpZmljYXRlcy4gTW9uaXRvcnMgKGRl c2NyaWJlZCBpbiBTZWN0aW9uJm5ic3A7PGI+WDwvYj4pIGFyZSB0aGUgcHJpbWFyeSBlbGVtZW50 cyBvZiB0aGUgQ1Qgc3lzdGVtIHRoYXQgY2hlY2sgY2VydGlmaWNhdGVzIGZvciBzeW50YWN0aWMg YW5kIHNlbWFudGljIG1pcy1pc3N1YW5jZSwgb24gYmVoYWxmIG9mIFN1YmplY3RzLiBBIE1vbml0 b3IgbWF5IGJlIG9wZXJhdGVkIGJ5IGEgdGhpcmQgcGFydHkgb24gYmVoYWxmIG9mIFN1YmplY3Rz LCBvciBtYXkgYmUgb3BlcmF0ZWQgYnkgYSBTdWJqZWN0IG9uIGl0cyBvd24gYmVoYWxmLiAoVGhl IGxhdHRlciBpcyByZWZlcnJlZCB0byBhcyDigJxzZWxmLW1vbml0b3JpbmfigJ0uKSBMb2dzIG1h eSBvcHRpb25hbGx5IHBlcmZvcm0gc3ludGFjdGljIGNoZWNrcyBmb3Igc29tZSBjbGFzc2VzIG9m IGNlcnRpZmljYXRlcywgYnV0IGEgbG9nIGlzIG5vdCByZXF1aXJlZCB0byBvZmZlciBjZXJ0aWZp Y2F0ZSBjaGVja2luZy48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBm aXJzdCBzZW50ZW5jZSBuZWVkcyB0byBiZSBtb3JlIGJyb2FkLCBzaW5jZSBhbnlvbmUgY2FuIHNl bmQgYSBjZXJ0IHRvIGEgbG9nLiBCdXQgaXTigJlzIG1vc3QgbGlrZWx5IHRvIGJlIHRoZSBDQXMg b3IgdGhlIFN1YmplY3RzLCBzbyBJIHdvdWxkIHN1Z2dlc3Qg4oCcQ1Qgc3VwcG9ydHMgZGV0ZWN0 aW9uIG9mIG1pcy1pc3N1YW5jZSB1c2luZyBsb2dzIG9mIGNlcnRpZmljYXRlcywgcG9wdWxhdGVk IGJ5IHRoZSBDQXMgdGhhdCBpc3N1ZSB0aGVtLCBieSB0aGUgU3ViamVjdHMgb2YgY2VydGlmaWNh dGVzLCBvciBieSBhbnlvbmUgd2l0aCBrbm93bGVkZ2Ugb2YgdGhlIGVudGlyZSBjZXJ0aWZpY2F0 ZSBjaGFpbi7igJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+Jm5ic3A7PG86cD48L286cD48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+Q2FuJ3QgYW55b25lIGJ1 aWxkIHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbj8mbmJzcDsgU2luY2UgdGhlIGxvZ3MgYXJlIHBvc3Rp bmcgdGhlIHN1cHBvcnRlZCB0cnVzdCBhbmNob3JzLCBhbnlvbmUgY2FuIGJ1aWxkIGEgY2hhaW4g Zm9yIHRoZSBlbmQgZW50aXR5IGNlcnRpZmljYXRlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+W1JpY2tdIEluIG1vc3QgY2FzZXMsIHllcy4g SWYgc29tZW9uZSBoYXMgYWNjZXNzIHRvIHRoZSBzZXJ2ZXIgY29uZmlndXJlZCB3aXRoIHRoYXQg Y2VydGlmaWNhdGUsIHRoZXkgY2FuIGRvIGEgVExTIGhhbmRzaGFrZSBhbmQgZ2V0IHRoZSBjaGFp biBpbiBuZWFybHkgYWxsIGNhc2VzLiBXZSBzZWUgc29tZSB3ZWIgc2VydmVycyB0aGF0IGFyZSBt aXNzaW5nIHRoZSBpbnRlcm1lZGlhdGUgQ0EgY2VydCwgYW5kIHNvbWUgYnJvd3NlcnMgKElFLCBm b3IgZXhhbXBsZSkgd2lsbCBmb2xsb3cgdGhlIEFJQSBleHRlbnNpb24gKGlmIGl04oCZcyBpbiB0 aGUgY2VydCkgYW5kIGZldGNoIHRoZSBpbnRlcm1lZGlhdGUuIEFueSBjbGllbnQgY2FuIGRvIHRo YXQgdG9vLiBCdXQgaWYgdGhlIENBIGRpZG7igJl0IHB1dCBhbiBBSUEgZXh0ZW5zaW9uIGluIHRo ZSBjZXJ0IGFuZCB5b3UgY2Fu4oCZdCBmaW5kIGEgc2VydmVyIHdpdGggdGhhdCBjZXJ0LCBpdCBt aWdodCBub3QgYmUgcG9zc2libGUgdG8gZmluZCB0aGUgaW50ZXJtZWRpYXRlIENBIGNlcnQuIEFu ZCB3aXRob3V0IHRoZSBpbnRlcm1lZGlhdGUgKG9yIGludGVybWVkaWF0ZXMhKSB0aGUgbG9nIHdv buKAmXQgYWNjZXB0IGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4nPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OkNvdXJpZXI7Y29sb3I6YmxhY2snPlRvIGVuYWJsZSBNb25pdG9ycyAoYW5kLCBvcHRpb25hbGx5 LCBsb2dzKSB0byBwZXJmb3JtIGFuIGFwcHJvcHJpYXRlIHNldCBvZiBjaGVja3MsJm5ic3A7PHM+ dGhlIChwcmUtKTwvcz4mbmJzcDthIENDSUQgTVVTVCBiZSBwcm92aWRlZCB0byBhIGxvZyB3aGVu IGEgY2VydGlmaWNhdGUgaXMgc3VibWl0dGVkIGJ5IGEgQ0Egb3IgU3ViamVjdC4gVGhpcyBDQ0lE IE1VU1QgYXBwZWFyIGluIHRoZSBsb2cgZW50cnkgYW5kIGluIHRoZSBTQ1QgZ2VuZXJhdGVkIGJ5 IHRoZSBsb2cuIEJ5IHByb3ZpZGluZyB0aGUgQ0NJRCBpbiBsb2dzIGFuZCBTQ1RzLCBib3RoIE1v bml0b3JzIGFuZCBjbGllbnRzIGFyZSBlbXBvd2VyZWQgdG8gcGVyZm9ybSBhcHBsaWNhYmxlIGNo ZWNrcyBiYXNlZCBvbiB0aGUgY2VydGlmaWNhdGUgY2xhc3MgYXNzZXJ0ZWQgYnkgdGhlIENBIG9y IFN1YmplY3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IbW3igKYgU2lu Y2UgYW55b25lIGNhbiBzZW5kIGEgY2VydCB0byBhIGxvZywgdGhlIGZpcnN0IHNlbnRlbmNlIG11 c3QgcmVmbGVjdCB0aGF0LiBCdXQgdGhhdCBtYWtlcyBtZSB3b25kZXIgd2hhdCBzaG91bGQgaGFw cGVuIGlmIHRoZSDigJxSZXBvcnRlcuKAnSAoSSBkb27igJl0IHdhbnQgdG8gaW50cm9kdWNlIGEg bmV3IHJvbGUpIHNlbmRzIHRoZSB3cm9uZyBDQ0lEPyAoQnkg4oCcd3JvbmfigJ0gSSBtZWFuIGl0 4oCZcyBhIHZhbGlkIENDSUQsIGJ1dCBpdOKAmXMgbm90IHRoZSBvbmUgdGhhdCB0aGUgQ0Egd291 bGQgYXNzb2NpYXRlIHdpdGggdGhlIGNlcnQuKSBPciBzZW5kcyB0aGUgY2VydCBtdWx0aXBsZSB0 aW1lcyB3aXRoIGRpZmZlcmVudCBDQ0lEcz8gSSBndWVzcyBNb25pdG9ycyB3b3VsZCBoYXZlIHRv IGV4cGVjdCBtdWx0aXBsZSBlbnRyaWVzIGZvciBhIGdpdmVuIGNlcnRpZmljYXRlIGluIGEgZ2l2 ZW4gbG9nLCB3aXRoIGRpZmZlcmVudCBDQ0lEcy4gSeKAmW0gbm90IHN1cmUgaWYgNjk2Mi1iaXMg aW1wb3NlcyBhbnkgdW5pcXVlbmVzcyBjb25zdHJhaW50IHRoYXQgdGhpcyBtaWdodCB2aW9sYXRl Ljwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjojMUY0OTdEJz4m bmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluJz5BbHRlcm5hdGl2ZWx5LCBh IGxvZyBjb3VsZCBjaGVjayB0byBzZWUgaWYgdGhlIHJlcG9ydGVkIGNlcnRpZmljYXRlIGlzIGFs cmVhZHkgcHJlc2VudCwgYW5kIGlmIHNvLCByZXR1cm4gdGhlIG9sZGVyIGVudHJ5IHRvIHRoZSBw YXJ0eSB0aGF0IHJlcG9ydHMgdGhlIGNlcnRpZmljYXRlLiZuYnNwOyBJIHNlZW0gdG8gcmVjYWxs IHJlYWRpbmcgdGhpcyBpZGVhIGF0IHNvbWUgcG9pbnQsIGJ1eSBJIGFkbWl0IEkgZGlkIG5vdCBs b29rIGludG8gdGhlIGN1cnJlbnQgSS1EIHRvIHNlZSBpZiB0aGF0IHdhcyB3aGVyZSBpIHJlYWQg aXQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltSaWNrXSBSRkMgNjk2MiBhbmQgYmlzLTA0IHNheSDigJxJ ZiB0aGUgbG9nIGhhcyBwcmV2aW91c2x5IHNlZW4gdGhlIGNlcnRpZmljYXRlLCBpdCBNQVkgcmV0 dXJuIHRoZSBzYW1lIFNDVCBhcyBpdCByZXR1cm5lZCBiZWZvcmUu4oCdIEJ1dCB0aGlzIHdvdWxk IGhhdmUgdG8gYmUgZXhwYW5kZWQgdG8gc2F5IOKAnElmIHRoZSBsb2cgaGFzIHByZXZpb3VzbHkg c2VlbiB0aGUgY2VydGlmaWNhdGUgPGI+YW5kIENDSUQ8L2I+LCBpdCBNQVkgcmV0dXJuIHRoZSBz YW1lIFNDVCBhcyBpdCByZXR1cm5lZCBiZWZvcmUu4oCdIEl04oCZcyBhIGJpdCBtb3JlIGNvbXBs ZXgsIHNpbmNlIHRoZSBsb2cgc2VydmVyIG1heSBub3Qgc3VwcG9ydCB0aGUgQ0NJRCBvciBhbnkg Y2hlY2tpbmcsIGluIHdoaWNoIGNhc2VzIGl0IHdvdWxkIGFsd2F5cyBsb2cgdGhlIGVudHJ5IHdp dGggQ0NJRCA9MSB0aGF0IGluZGljYXRlcyDigJxUaGlzIGxvZyBkb2VzIG5vdCBwZXJmb3JtIHN5 bnRheCBjaGVja3PigJ0sIG9yIENDSUQ9MiB0aGF0IGluZGljYXRlcyDigJxUaGlzIGxvZyBkb2Vz IG5vdCBzdXBwb3J0IHN5bnRheCBjaGVja3MgZm9yIHRoZSBhc3NlcnRlZCBDQ0lE4oCdLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MS4w aW4nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjEuMGluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xv cjpibGFjayc+QSBsb2cgTVVTVCBnZW5lcmF0ZSBhIFN5bnRheCBWZXJpZmljYXRpb24gVmFsdWUg KFNWVikgZm9yIHRoZSBjZXJ0aWZpY2F0ZSwgYW5kIGluY2x1ZGUgdGhlIFNWViBpbiB0aGUgbG9n IGVudHJ5IGFuZCBpbiB0aGUgU0NULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2IHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEu MGluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+VGhlJm5i c3A7PHM+TFZWPC9zPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xv cjojMUY0OTdEJz4mbmJzcDsqPGI+U1ZWPC9iPio8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OkNvdXJpZXI7Y29sb3I6YmxhY2snPiZuYnNwO2lzJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiMxRjQ5N0QnPio8Yj5hPC9iPiombmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2snPnZhbHVlIHNw ZWNpZmllZCBieSB0aGlzIGRvY3VtZW50IChzZWUgU2VjdGlvbiBaKSB0aGF0IGluZGljYXRlcyB3 aGV0aGVyIG9yIG5vdCB0aGUgbG9nIHBlcmZvcm1lZCBhcHBsaWNhYmxlIHN5bnRhY3RpYyBjaGVj a3MsIGFuZCB3aGV0aGVyIHRoZSAocHJlLSkgY2VydGlmaWNhdGUgcGFzc2VkJm5ic3A7PHM+b2Y8 L3M+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiMx RjQ5N0QnPio8Yj5vcjwvYj4qJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrJz5mYWlsZWQgdGhlIGNoZWNrcy4gQWx0aG91Z2ggaXQgaXMgYW50 aWNpcGF0ZWQgdGhhdCBuZXcgY2VydGlmaWNhdGUgY2xhc3NlcyB3aWxsIGFyaXNlIG92ZXIgdGlt ZSwgdGhlIHNldCBvZiBsb2cgYWN0aW9ucyB3aXRoIHJlc3BlY3QgdG8gc3ludGF4IGNoZWNraW5n IGFwcGVhcnMgdG8gYmUgd2VsbC1kZWZpbmVkIGFuZCB0aHVzIG5lZWQgbm90IGJlIHJlcHJlc2Vu dGVkIGluIGFuIElBTkEgcmVnaXN0cnkuIEVhY2ggU0NUIGlzc3VlZCBieSBhIGxvZyBNVVNUIGlu Y2x1ZGUgYW4gU1ZWLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHls ZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBp bic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2snPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MS4waW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNr Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2snPlZhbHVlIEludGVycHJldGF0aW9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0OjEuNWlu Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluJz48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+MDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+VGhlIENDSUQgdmFsdWUg d2FzIDAsIHNvJm5ic3A7PHM+bm90PC9zPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6Q291cmllcjtjb2xvcjojMUY0OTdEJz4qPGI+bm88L2I+KiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+Y2hlY2tzIHdlcmUgcGVy Zm9ybWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0 OjEuNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluJz48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+MTwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+VGhpcyBsb2cg ZG9lcyBub3QgcGVyZm9ybSBzeW50YXggY2hlY2tzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0OjEuNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFj ayc+Mjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayc+VGhpcyBsb2cgZG9lcyBub3Qgc3VwcG9ydCBzeW50YXggY2hlY2tzIGZv ciB0aGUgYXNzZXJ0ZWQgQ0NJRDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2IHN0eWxl PSdtYXJnaW4tbGVmdDoxLjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBp bic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2snPjM8L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6Ymxh Y2snPlRoaXMgbG9nIHBlcmZvcm1lZCB0aGUgc3ludGF4IGNoZWNrcyBmb3IgdGhlIGFzc2VydGVk IENDSUQsIGFuZCB0aGUgY2VydGlmaWNhdGUgcGFzc2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0OjEuNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpi bGFjayc+NDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291 cmllcjtjb2xvcjpibGFjayc+VGhpcyBsb2cgcGVyZm9ybWVkIHRoZSBzeW50YXggY2hlY2tzIGZv ciB0aGUgYXNzZXJ0ZWQgQ0NJRCwgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBmYWlsZWQ8L3NwYW4+PG86 cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNv dXJpZXI7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjEuMGluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayc+Tm8g b3RoZXIgU1ZWIHZhbHVlcyBhcmUgZGVmaW5lZCBieSB0aGlzIFJGQy48L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbic+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluJz5JZiB0aGUgbG9nIHBlcmZvcm1zIHNvbWUgdmFsaWRhdGlvbiBjaGVja3Ms IGFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IGEgcmVseWluZyBwYXJ0eSBjYW4gbGV2ZXJhZ2UgdGhl IHdvcmsgYWxyZWFkeSBkb25lIGJ5IHRoZSBsb2c/Jm5ic3A7IElmIHNvLCBpdCBwdXRzIHRoZSBs b2cgY2hlY2tpbmcgYXQgYSBkaWZmZXJlbnQgcGxhY2UgaW4gdGhlIGNlcnRpZmljYXRlIHZhbGlk YXRpb24gdGhhbiBJIHdhcyBpbWFnaW5pbmcuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltSaWNrXSBZZXMs IGEgcmVseWluZyBwYXJ0eSBjb3VsZCBsZXZlcmFnZSB0aGUgd29yayBhbHJlYWR5IGRvbmUgYnkg dGhlIGxvZyBzZXJ2ZXIsIGlmIHRoZSBSUCB0cnVzdGVkIGl0LiBHb29nbGUgd291bGQgcHJvYmFi bHkgYWR2aXNlIGFnYWluc3QgdGhpcywgc2luY2UgdGhleSBoYXZlIGJlZW4gcHJldHR5IGNvbnNp c3RlbnQgaW4gc2F5aW5nIHRoYXQgQ1QgZG9lc27igJl0IHJlcXVpcmUgeW91IHRvIHRydXN0IGFu eW9uZSBpbmNsdWRpbmcgdGhlIGxvZyBzZXJ2ZXIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4nPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MS4waW4nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4n Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5U cmFucyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOlRyYW5zQGlldGYub3JnIj5UcmFu c0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmFucyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJhbnM8L2E+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_544B0DD62A64C1448B2DA253C011414607D375C38DTUS1XCHEVSPIN_-- From nobody Tue Oct 28 12:28:06 2014 Return-Path: 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 4BE721AC82C for ; Tue, 28 Oct 2014 12:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rp09j5nCwGc5 for ; Tue, 28 Oct 2014 12:27:55 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932E61AC3FC for ; Tue, 28 Oct 2014 12:27:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,804,1406606400"; d="scan'208,217";a="2504618" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge2.cygnacom.com with ESMTP; 28 Oct 2014 15:27:53 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 15:27:53 -0400 From: Santosh Chokhani To: Eran Messeri Thread-Topic: [Trans] Goals and generic mis-issuance fgramework Thread-Index: AQHP5Ab2FAjCsOwr9kS2LsAemu1e1pw51z8AgAeOSQCAA4FJgP//90vggAE6LQD//+QFgA== Date: Tue, 28 Oct 2014 19:27:52 +0000 Message-ID: <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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.7] Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E81139243DF5scygexch10cygnaco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/a0VmkEqg2WXE0m2w4kmES3__65Y Cc: "trans@ietf.org" , Russ Housley , Steve Kent , Rick Andrews 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:28:00 -0000 --_000_4262AC0DB9856847A2D00EF817E81139243DF5scygexch10cygnaco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJhbiwNCg0KU2VlIGluLWxpbmUgYmVsb3cuDQoNCkZyb206IEVyYW4gTWVzc2VyaSBbbWFpbHRv OmVyYW5tQGdvb2dsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI4LCAyMDE0IDEyOjQ2 IFBNDQpUbzogU2FudG9zaCBDaG9raGFuaQ0KQ2M6IFJpY2sgQW5kcmV3czsgUnVzcyBIb3VzbGV5 OyBTdGV2ZSBLZW50OyB0cmFuc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUcmFuc10gR29hbHMg YW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZncmFtZXdvcmsNCg0KT3ZlcmFsbCB0aGUgbWVjaGFu aXNtIGRlc2NyaWJlZCBzZWVtcyByZWFzb25hYmxlLiBDYW4geW91IGhlbHAgbWUgdW5kZXJzdGFu ZCB0aGUgYmVuZWZpdHMgZnJvbSB0aGUgVExTIGNsaWVudCdzIHBlcnNwZWN0aXZlPw0KW1NhbnRv c2hdIFRoZSBwcmltYXJ5IGJlbmVmaXQgd291bGQgaGF2ZSBjb21lIGlmIHRoZSBsb2cgaGFkIGVu Zm9yY2VkIGFuZCBub3QgcmVnaXN0ZXJlZCBhIG1hbC1mb3JtZWQgY2VydGlmaWNhdGUuICBMb2cg YWNjZXB0YW5jZSBvZiBjZXJ0aWZpY2F0ZSBzZWVtcyB0byB3aGF0IHRoZSBXRyBwcmVmZXJzLiAg SW4gdGhhdCBjYXNlLCBiZW5lZml0cyB0byB0aGUgY2xpZW50IGFyZSByZWR1Y2VkLg0KDQpJSVVD LCB0aGUgbG9nIHdpbGwgbmV2ZXIgcmVmdXNlIHRvIGluY2x1ZGUgYSBjZXJ0aWZpY2F0ZSwgaXQg d2lsbCBtZXJlbHkgaW5kaWNhdGUgaXQgZmFpbGVkIHN5bnRhY3RpYyBjaGVja3MuDQpBcmUgeW91 IHN1Z2dlc3RpbmcgdGhhdCBUTFMgY2xpZW50cyB3aWxsIHJlamVjdCBhbiBvdGhlcndpc2UtdmFs aWQgY2VydGlmaWNhdGUgY2hhaW4gd2hpY2ggaGFzIGEgQ0NJRCB0aGF0IG1hdGNoZXMgdGhlIFRM UyBjbGllbnQncyBkZXNpcmVkIHVzZSBvZiB0aGUgY2VydGlmaWNhdGUsIGJlY2F1c2UgdGhlIGxv ZyBpbmRpY2F0ZWQgaXQgZmFpbGVkIHN5bnRhY3RpYyBjaGVja3M/DQpbU2FudG9zaF0gVGhhdCBj b3VsZCBiZSBvbmUgdGhpbmcuICBXaGF0IEkgd2FzIHNheWluZyBpbiB0aGUgdGhyZWFkIGlzIHRo YXQgZXZlbiBpZiB0aGUgTG9nIHNhaWQgdGhhdCB0aGUgY2VydGlmaWNhdGUgcGFzc2VkIHRoZSBj aGVja3MsIGNsaWVudCBtdXN0IGRvIGl0cyBvd24gcGF0aCB2YWxpZGF0aW9uIHVubGVzcyB0aGUg Y2xpZW50IGFuZCBsb2cgYXJlIHVzaW5nIHRoZSBzYW1lIGNoYWluIGFuZCBzYW1lIDUyODAgcGF0 aCB2YWxpZGF0aW9uIGluaXRpYWxpemF0aW9uIHZhcmlhYmxlcy4NCg0KT25lIGFkdmFudGFnZSBv ZiBsb2dzIGRvaW5nIGNoZWNraW5nIGFuZCByZWplY3RpbmcgdGhlIGNlcnRpZmljYXRlcyBpcyB0 aGF0IHRoZSBodW1hbiB1c2VyIHdpbGwgbm90IGdvIHRocm91Z2ggdGhlIGVycm9yLXByb25lIGRl Y2lzaW9uIG1ha2luZyBhYm91dCB0aGUgc2VjdXJpdHkgcmFtaWZpY2F0aW9uIG9mIGZhaWxlZCBw YXRoIHZhbGlkYXRpb24uDQoNCkl0J3Mgbm90IGEgYmFkIHRoaW5nLCBpdCBkb2VzIHBsYWNlIGFk ZGl0aW9uYWwgYnVyZGVuIG9uIGxvZ3MgdGhvdWdoLiBNb25pdG9ycyB3aWxsIGhhdmUgdG8gdmVy aWZ5IHRoZSBsb2cncyBob25lc3QgYmVoYXZpb3VyIG9uIHRoaXMgYXNwZWN0IGFzIHdlbGwuDQoN ClRoZSBvdGhlciBxdWVzdGlvbiBpcyAtIGFyZW4ndCBjZXJ0aWZpY2F0ZSBjbGFzc2VzIGRpZmZl cmVudCBlbm91Z2ggdG8gbWVyaXQgcnVubmluZyBkaWZmZXJlbnQgbG9ncywgd2hlcmUgdGhlIGxv ZydzIGlkZW50aXR5IChvciBzb21lIG90aGVyIG1ldGFkYXRhKSBpbmRpY2F0ZXMgd2hpY2ggQ0NJ RCBpdCdzIGdvb2QgZm9yPw0KSSdtIGEgYml0IHdlYXJ5IG9mIHNwZWNpZnlpbmcgYSBiZWhhdmlv dXIgZm9yIHRoZSBnZW5lcmFsIGNhc2Ugd2hlcmUgSSBkb24ndCBoYXZlIGNvbmNyZXRlIGV4YW1w bGVzIGZvciBtb3JlIHRoYW4gb25lIHBhcnRpY3VsYXIgY2FzZS4NCltTYW50b3NoXSBUbyBteSBr bm93bGVkZ2UsIGxvdCBvZiBwYXRoIGNoZWNrcyBhcmUgdGhlIHNhbWUuICBEaWZmZXJlbnQgY2xh c3NlcyBvZiBjZXJ0aWZpY2F0ZXMgbWF5IHdhcnJhbnQgY2hlY2tpbmcgS1UsIEVLVSBhbmQgZXh0 cmFjdGluZyBhbmQgbWF0Y2hpbmcgbmFtZXMgZnJvbSBkaWZmZXJlbnQgZmllbGRzIChzYXkgU3Vi amVjdCBETiBvciBTQU4pLg0KDQpPbiBUdWUsIE9jdCAyOCwgMjAxNCBhdCAyOjA5IEFNLCBTYW50 b3NoIENob2toYW5pIDxzY2hva2hhbmlAY3lnbmFjb20uY29tPG1haWx0bzpzY2hva2hhbmlAY3ln bmFjb20uY29tPj4gd3JvdGU6DQpSZWx5aW5nIHBhcnRpZXMgcmVseWluZyBvbiB0aGUgY2hlY2tz IG1hZGUgYnkgbG9nIHNlcnZlciBtYXkgYmUgcHJvYmxlbWF0aWMgaWYgYm90aCBkbyBub3QgaGF2 ZSB0aGUgc2FtZSB0cnVzdCBzdG9yZSBpZiB0aGUgaW5pdGlhbGl6YXRpb24gdmFyaWFibGVzIGFy ZSBkaWZmZXJlbnQuDQoNCk15IHByaW1hcnkgbW90aXZhdGlvbiBpbiBsb2cgZG9pbmcgY2hlY2tz IGlzIG5pcCB0aGUgcHJvYmxlbSBpbiB0aGUgYnVkIGFuZCByZWR1Y2UgdGhlIHByb2JhYmlsaXR5 IG9mIHJlbHlpbmcgcGFydGllcyBoYXZpbmcgdG8gZGVjaWRlIG9uIGV4Y2VwdGlvbnMuICBUaGUg cmVseWluZyBwYXJ0aWVzIHN0aWxsIHNob3VsZCB2YWxpZGF0ZSB0aGUgY2VydGlmaWNhdGlvbiBw YXRoLg0KDQpGcm9tOiBUcmFucyBbbWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUmljayBBbmRyZXdzDQpTZW50 OiBNb25kYXksIE9jdG9iZXIgMjcsIDIwMTQgNjozMyBQTQ0KVG86IFJ1c3MgSG91c2xleTsgU3Rl dmUgS2VudA0KDQpDYzogdHJhbnNAaWV0Zi5vcmc8bWFpbHRvOnRyYW5zQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZncmFtZXdv cmsNCg0KUnVzcywgY29tbWVudHMgaW5saW5lLg0KDQotUmljaw0KDQpGcm9tOiBUcmFucyBbbWFp bHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSdXNzIEhvdXNsZXkNClNl bnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDI1LCAyMDE0IDEwOjAxIEFNDQpUbzogUmljayBBbmRyZXdz OyBTdGV2ZSBLZW50DQpDYzogdHJhbnNAaWV0Zi5vcmc8bWFpbHRvOnRyYW5zQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZncmFt ZXdvcmsNCg0KU3RldmUgYW5kIFJpY2s6DQoNCg0KMS4gQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5 IEdvYWxzIGFuZCBNZWNoYW5pc21zDQoNClRoZSBnb2FscyBvZiBDZXJ0aWZpY2F0ZSBUcmFuc3Bh cmVuY3kgKENUKSBhcmUgdGhyZWVmb2xkOiBkZXRlY3Rpb24sIGRldGVycmVuY2UsIGFuZCBlbmFi bGluZyByZW1lZGlhdGlvbiBvZiBtaXMtaXNzdWFuY2Ugb2YgY2VydGlmaWNhdGVzLiBUaGUgaW5p dGlhbCBmb2N1cyBvZiBDVCBpcyB0aGUgV2ViIFBLSSBjb250ZXh0LCAoVGhlIFdlYiBQS0kgY29u dGV4dCByZWZlcnMgdG8gdGhlIHVzZSBvZiBhIHNldCBvZiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 aWVzIChDQXMpIHRoYXQgaXNzdWUgWC41MDkgY2VydGlmaWNhdGVzIHRvIHdlYiBzZXJ2ZXJzIHRv IGVuYWJsZSBUTFMtcHJvdGVjdGVkIGFjY2VzcyBieSBjbGllbnRzIFtjaXRlIFdQS09QUz9dLikg SW4gdGhlIGZ1dHVyZSwgaXQgaXMgYW50aWNpcGF0ZWQgdGhhdCBhZGRpdGlvbiAqYWRkaXRpb25h bCpvcGVyYXRpb25hbCBjb250ZXh0cyBtYXkgYmUgc3VwcG9ydGVkLiBBcyBhIHJlc3VsdCwgbWlz LWlzc3VhbmNlIGlzIGRlZmluZWQgaW4gYW4gZmFzaGlvbiB0aGF0IGFjY29tbW9kYXRlcyBhIHJh bmdlIG9mIHR5cGVzIG9mIGNlcnRpZmljYXRlcyB1c2VkIGluIGEgcmFuZ2Ugb2YgY29udGV4dHMu DQoNCkNUIHN1cHBvcnRzIGRldGVjdGlvbiBvZiBtaXMtaXNzdWFuY2UgdXNpbmcgbG9ncyBvZiBj ZXJ0aWZpY2F0ZXMsIHBvcHVsYXRlZCBieSB0aGUgQ0FzIHRoYXQgaXNzdWUgdGhlbSBvciBieSB0 aGUgU3ViamVjdHMgb2YgY2VydGlmaWNhdGVzLiBNb25pdG9ycyAoZGVzY3JpYmVkIGluIFNlY3Rp b24gWCkgYXJlIHRoZSBwcmltYXJ5IGVsZW1lbnRzIG9mIHRoZSBDVCBzeXN0ZW0gdGhhdCBjaGVj ayBjZXJ0aWZpY2F0ZXMgZm9yIHN5bnRhY3RpYyBhbmQgc2VtYW50aWMgbWlzLWlzc3VhbmNlLCBv biBiZWhhbGYgb2YgU3ViamVjdHMuIEEgTW9uaXRvciBtYXkgYmUgb3BlcmF0ZWQgYnkgYSB0aGly ZCBwYXJ0eSBvbiBiZWhhbGYgb2YgU3ViamVjdHMsIG9yIG1heSBiZSBvcGVyYXRlZCBieSBhIFN1 YmplY3Qgb24gaXRzIG93biBiZWhhbGYuIChUaGUgbGF0dGVyIGlzIHJlZmVycmVkIHRvIGFzIOKA nHNlbGYtbW9uaXRvcmluZ+KAnS4pIExvZ3MgbWF5IG9wdGlvbmFsbHkgcGVyZm9ybSBzeW50YWN0 aWMgY2hlY2tzIGZvciBzb21lIGNsYXNzZXMgb2YgY2VydGlmaWNhdGVzLCBidXQgYSBsb2cgaXMg bm90IHJlcXVpcmVkIHRvIG9mZmVyIGNlcnRpZmljYXRlIGNoZWNraW5nLg0KVGhlIGZpcnN0IHNl bnRlbmNlIG5lZWRzIHRvIGJlIG1vcmUgYnJvYWQsIHNpbmNlIGFueW9uZSBjYW4gc2VuZCBhIGNl cnQgdG8gYSBsb2cuIEJ1dCBpdOKAmXMgbW9zdCBsaWtlbHkgdG8gYmUgdGhlIENBcyBvciB0aGUg U3ViamVjdHMsIHNvIEkgd291bGQgc3VnZ2VzdCDigJxDVCBzdXBwb3J0cyBkZXRlY3Rpb24gb2Yg bWlzLWlzc3VhbmNlIHVzaW5nIGxvZ3Mgb2YgY2VydGlmaWNhdGVzLCBwb3B1bGF0ZWQgYnkgdGhl IENBcyB0aGF0IGlzc3VlIHRoZW0sIGJ5IHRoZSBTdWJqZWN0cyBvZiBjZXJ0aWZpY2F0ZXMsIG9y IGJ5IGFueW9uZSB3aXRoIGtub3dsZWRnZSBvZiB0aGUgZW50aXJlIGNlcnRpZmljYXRlIGNoYWlu LuKAnS4NCg0KQ2FuJ3QgYW55b25lIGJ1aWxkIHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbj8gIFNpbmNl IHRoZSBsb2dzIGFyZSBwb3N0aW5nIHRoZSBzdXBwb3J0ZWQgdHJ1c3QgYW5jaG9ycywgYW55b25l IGNhbiBidWlsZCBhIGNoYWluIGZvciB0aGUgZW5kIGVudGl0eSBjZXJ0aWZpY2F0ZS4NCg0KW1Jp Y2tdIEluIG1vc3QgY2FzZXMsIHllcy4gSWYgc29tZW9uZSBoYXMgYWNjZXNzIHRvIHRoZSBzZXJ2 ZXIgY29uZmlndXJlZCB3aXRoIHRoYXQgY2VydGlmaWNhdGUsIHRoZXkgY2FuIGRvIGEgVExTIGhh bmRzaGFrZSBhbmQgZ2V0IHRoZSBjaGFpbiBpbiBuZWFybHkgYWxsIGNhc2VzLiBXZSBzZWUgc29t ZSB3ZWIgc2VydmVycyB0aGF0IGFyZSBtaXNzaW5nIHRoZSBpbnRlcm1lZGlhdGUgQ0EgY2VydCwg YW5kIHNvbWUgYnJvd3NlcnMgKElFLCBmb3IgZXhhbXBsZSkgd2lsbCBmb2xsb3cgdGhlIEFJQSBl eHRlbnNpb24gKGlmIGl04oCZcyBpbiB0aGUgY2VydCkgYW5kIGZldGNoIHRoZSBpbnRlcm1lZGlh dGUuIEFueSBjbGllbnQgY2FuIGRvIHRoYXQgdG9vLiBCdXQgaWYgdGhlIENBIGRpZG7igJl0IHB1 dCBhbiBBSUEgZXh0ZW5zaW9uIGluIHRoZSBjZXJ0IGFuZCB5b3UgY2Fu4oCZdCBmaW5kIGEgc2Vy dmVyIHdpdGggdGhhdCBjZXJ0LCBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgdG8gZmluZCB0aGUg aW50ZXJtZWRpYXRlIENBIGNlcnQuIEFuZCB3aXRob3V0IHRoZSBpbnRlcm1lZGlhdGUgKG9yIGlu dGVybWVkaWF0ZXMhKSB0aGUgbG9nIHdvbuKAmXQgYWNjZXB0IGl0Lg0KDQpUbyBlbmFibGUgTW9u aXRvcnMgKGFuZCwgb3B0aW9uYWxseSwgbG9ncykgdG8gcGVyZm9ybSBhbiBhcHByb3ByaWF0ZSBz ZXQgb2YgY2hlY2tzLCB0aGUgKHByZS0pIGEgQ0NJRCBNVVNUIGJlIHByb3ZpZGVkIHRvIGEgbG9n IHdoZW4gYSBjZXJ0aWZpY2F0ZSBpcyBzdWJtaXR0ZWQgYnkgYSBDQSBvciBTdWJqZWN0LiBUaGlz IENDSUQgTVVTVCBhcHBlYXIgaW4gdGhlIGxvZyBlbnRyeSBhbmQgaW4gdGhlIFNDVCBnZW5lcmF0 ZWQgYnkgdGhlIGxvZy4gQnkgcHJvdmlkaW5nIHRoZSBDQ0lEIGluIGxvZ3MgYW5kIFNDVHMsIGJv dGggTW9uaXRvcnMgYW5kIGNsaWVudHMgYXJlIGVtcG93ZXJlZCB0byBwZXJmb3JtIGFwcGxpY2Fi bGUgY2hlY2tzIGJhc2VkIG9uIHRoZSBjZXJ0aWZpY2F0ZSBjbGFzcyBhc3NlcnRlZCBieSB0aGUg Q0Egb3IgU3ViamVjdC4NCkhtbeKApiBTaW5jZSBhbnlvbmUgY2FuIHNlbmQgYSBjZXJ0IHRvIGEg bG9nLCB0aGUgZmlyc3Qgc2VudGVuY2UgbXVzdCByZWZsZWN0IHRoYXQuIEJ1dCB0aGF0IG1ha2Vz IG1lIHdvbmRlciB3aGF0IHNob3VsZCBoYXBwZW4gaWYgdGhlIOKAnFJlcG9ydGVy4oCdIChJIGRv buKAmXQgd2FudCB0byBpbnRyb2R1Y2UgYSBuZXcgcm9sZSkgc2VuZHMgdGhlIHdyb25nIENDSUQ/ IChCeSDigJx3cm9uZ+KAnSBJIG1lYW4gaXTigJlzIGEgdmFsaWQgQ0NJRCwgYnV0IGl04oCZcyBu b3QgdGhlIG9uZSB0aGF0IHRoZSBDQSB3b3VsZCBhc3NvY2lhdGUgd2l0aCB0aGUgY2VydC4pIE9y IHNlbmRzIHRoZSBjZXJ0IG11bHRpcGxlIHRpbWVzIHdpdGggZGlmZmVyZW50IENDSURzPyBJIGd1 ZXNzIE1vbml0b3JzIHdvdWxkIGhhdmUgdG8gZXhwZWN0IG11bHRpcGxlIGVudHJpZXMgZm9yIGEg Z2l2ZW4gY2VydGlmaWNhdGUgaW4gYSBnaXZlbiBsb2csIHdpdGggZGlmZmVyZW50IENDSURzLiBJ 4oCZbSBub3Qgc3VyZSBpZiA2OTYyLWJpcyBpbXBvc2VzIGFueSB1bmlxdWVuZXNzIGNvbnN0cmFp bnQgdGhhdCB0aGlzIG1pZ2h0IHZpb2xhdGUuDQoNCkFsdGVybmF0aXZlbHksIGEgbG9nIGNvdWxk IGNoZWNrIHRvIHNlZSBpZiB0aGUgcmVwb3J0ZWQgY2VydGlmaWNhdGUgaXMgYWxyZWFkeSBwcmVz ZW50LCBhbmQgaWYgc28sIHJldHVybiB0aGUgb2xkZXIgZW50cnkgdG8gdGhlIHBhcnR5IHRoYXQg cmVwb3J0cyB0aGUgY2VydGlmaWNhdGUuICBJIHNlZW0gdG8gcmVjYWxsIHJlYWRpbmcgdGhpcyBp ZGVhIGF0IHNvbWUgcG9pbnQsIGJ1eSBJIGFkbWl0IEkgZGlkIG5vdCBsb29rIGludG8gdGhlIGN1 cnJlbnQgSS1EIHRvIHNlZSBpZiB0aGF0IHdhcyB3aGVyZSBpIHJlYWQgaXQuDQpbUmlja10gUkZD IDY5NjIgYW5kIGJpcy0wNCBzYXkg4oCcSWYgdGhlIGxvZyBoYXMgcHJldmlvdXNseSBzZWVuIHRo ZSBjZXJ0aWZpY2F0ZSwgaXQgTUFZIHJldHVybiB0aGUgc2FtZSBTQ1QgYXMgaXQgcmV0dXJuZWQg YmVmb3JlLuKAnSBCdXQgdGhpcyB3b3VsZCBoYXZlIHRvIGJlIGV4cGFuZGVkIHRvIHNheSDigJxJ ZiB0aGUgbG9nIGhhcyBwcmV2aW91c2x5IHNlZW4gdGhlIGNlcnRpZmljYXRlIGFuZCBDQ0lELCBp dCBNQVkgcmV0dXJuIHRoZSBzYW1lIFNDVCBhcyBpdCByZXR1cm5lZCBiZWZvcmUu4oCdIEl04oCZ cyBhIGJpdCBtb3JlIGNvbXBsZXgsIHNpbmNlIHRoZSBsb2cgc2VydmVyIG1heSBub3Qgc3VwcG9y dCB0aGUgQ0NJRCBvciBhbnkgY2hlY2tpbmcsIGluIHdoaWNoIGNhc2VzIGl0IHdvdWxkIGFsd2F5 cyBsb2cgdGhlIGVudHJ5IHdpdGggQ0NJRCA9MSB0aGF0IGluZGljYXRlcyDigJxUaGlzIGxvZyBk b2VzIG5vdCBwZXJmb3JtIHN5bnRheCBjaGVja3PigJ0sIG9yIENDSUQ9MiB0aGF0IGluZGljYXRl cyDigJxUaGlzIGxvZyBkb2VzIG5vdCBzdXBwb3J0IHN5bnRheCBjaGVja3MgZm9yIHRoZSBhc3Nl cnRlZCBDQ0lE4oCdLg0KDQoNCkEgbG9nIE1VU1QgZ2VuZXJhdGUgYSBTeW50YXggVmVyaWZpY2F0 aW9uIFZhbHVlIChTVlYpIGZvciB0aGUgY2VydGlmaWNhdGUsIGFuZCBpbmNsdWRlIHRoZSBTVlYg aW4gdGhlIGxvZyBlbnRyeSBhbmQgaW4gdGhlIFNDVC4NClRoZSBMVlYgKlNWViogaXMgKmEqIHZh bHVlIHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50IChzZWUgU2VjdGlvbiBaKSB0aGF0IGluZGlj YXRlcyB3aGV0aGVyIG9yIG5vdCB0aGUgbG9nIHBlcmZvcm1lZCBhcHBsaWNhYmxlIHN5bnRhY3Rp YyBjaGVja3MsIGFuZCB3aGV0aGVyIHRoZSAocHJlLSkgY2VydGlmaWNhdGUgcGFzc2VkIG9mICpv ciogZmFpbGVkIHRoZSBjaGVja3MuIEFsdGhvdWdoIGl0IGlzIGFudGljaXBhdGVkIHRoYXQgbmV3 IGNlcnRpZmljYXRlIGNsYXNzZXMgd2lsbCBhcmlzZSBvdmVyIHRpbWUsIHRoZSBzZXQgb2YgbG9n IGFjdGlvbnMgd2l0aCByZXNwZWN0IHRvIHN5bnRheCBjaGVja2luZyBhcHBlYXJzIHRvIGJlIHdl bGwtZGVmaW5lZCBhbmQgdGh1cyBuZWVkIG5vdCBiZSByZXByZXNlbnRlZCBpbiBhbiBJQU5BIHJl Z2lzdHJ5LiBFYWNoIFNDVCBpc3N1ZWQgYnkgYSBsb2cgTVVTVCBpbmNsdWRlIGFuIFNWVi4NCg0K DQpWYWx1ZSBJbnRlcnByZXRhdGlvbg0KMCAgICAgICAgICAgICAgICAgVGhlIENDSUQgdmFsdWUg d2FzIDAsIHNvIG5vdCAqbm8qIGNoZWNrcyB3ZXJlIHBlcmZvcm1lZA0KMSAgICAgICAgICAgICAg ICAgVGhpcyBsb2cgZG9lcyBub3QgcGVyZm9ybSBzeW50YXggY2hlY2tzDQoyICAgICAgICAgICAg ICAgICBUaGlzIGxvZyBkb2VzIG5vdCBzdXBwb3J0IHN5bnRheCBjaGVja3MgZm9yIHRoZSBhc3Nl cnRlZCBDQ0lEDQozICAgICAgICAgICAgICAgICBUaGlzIGxvZyBwZXJmb3JtZWQgdGhlIHN5bnRh eCBjaGVja3MgZm9yIHRoZSBhc3NlcnRlZCBDQ0lELCBhbmQgdGhlIGNlcnRpZmljYXRlIHBhc3Nl ZA0KNCAgICAgICAgICAgICAgICAgVGhpcyBsb2cgcGVyZm9ybWVkIHRoZSBzeW50YXggY2hlY2tz IGZvciB0aGUgYXNzZXJ0ZWQgQ0NJRCwgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBmYWlsZWQNCg0KTm8g b3RoZXIgU1ZWIHZhbHVlcyBhcmUgZGVmaW5lZCBieSB0aGlzIFJGQy4NCg0KSWYgdGhlIGxvZyBw ZXJmb3JtcyBzb21lIHZhbGlkYXRpb24gY2hlY2tzLCBhcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCBh IHJlbHlpbmcgcGFydHkgY2FuIGxldmVyYWdlIHRoZSB3b3JrIGFscmVhZHkgZG9uZSBieSB0aGUg bG9nPyAgSWYgc28sIGl0IHB1dHMgdGhlIGxvZyBjaGVja2luZyBhdCBhIGRpZmZlcmVudCBwbGFj ZSBpbiB0aGUgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiB0aGFuIEkgd2FzIGltYWdpbmluZy4NCltS aWNrXSBZZXMsIGEgcmVseWluZyBwYXJ0eSBjb3VsZCBsZXZlcmFnZSB0aGUgd29yayBhbHJlYWR5 IGRvbmUgYnkgdGhlIGxvZyBzZXJ2ZXIsIGlmIHRoZSBSUCB0cnVzdGVkIGl0LiBHb29nbGUgd291 bGQgcHJvYmFibHkgYWR2aXNlIGFnYWluc3QgdGhpcywgc2luY2UgdGhleSBoYXZlIGJlZW4gcHJl dHR5IGNvbnNpc3RlbnQgaW4gc2F5aW5nIHRoYXQgQ1QgZG9lc27igJl0IHJlcXVpcmUgeW91IHRv IHRydXN0IGFueW9uZSBpbmNsdWRpbmcgdGhlIGxvZyBzZXJ2ZXIuDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUcmFucyBtYWlsaW5nIGxp c3QNClRyYW5zQGlldGYub3JnPG1haWx0bzpUcmFuc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMNCg0K --_000_4262AC0DB9856847A2D00EF817E81139243DF5scygexch10cygnaco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+RXJhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlNlZSBpbi1saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmFuIE1lc3NlcmkgW21haWx0bzplcmFu bUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjgsIDIw MTQgMTI6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IFNhbnRvc2ggQ2hva2hhbmk8YnI+DQo8Yj5DYzo8 L2I+IFJpY2sgQW5kcmV3czsgUnVzcyBIb3VzbGV5OyBTdGV2ZSBLZW50OyB0cmFuc0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RyYW5zXSBHb2FscyBhbmQgZ2VuZXJpYyBtaXMt aXNzdWFuY2UgZmdyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk92ZXJhbGwgdGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgc2VlbXMgcmVhc29uYWJsZS4gQ2FuIHlv dSBoZWxwIG1lIHVuZGVyc3RhbmQgdGhlIGJlbmVmaXRzIGZyb20gdGhlIFRMUyBjbGllbnQncyBw ZXJzcGVjdGl2ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bU2FudG9zaF0gVGhlIHByaW1hcnkgYmVuZWZp dCB3b3VsZCBoYXZlIGNvbWUgaWYgdGhlIGxvZyBoYWQgZW5mb3JjZWQgYW5kIG5vdCByZWdpc3Rl cmVkIGEgbWFsLWZvcm1lZCBjZXJ0aWZpY2F0ZS4mbmJzcDsgTG9nIGFjY2VwdGFuY2Ugb2YgY2Vy dGlmaWNhdGUgc2VlbXMNCiB0byB3aGF0IHRoZSBXRyBwcmVmZXJzLiZuYnNwOyBJbiB0aGF0IGNh c2UsIGJlbmVmaXRzIHRvIHRoZSBjbGllbnQgYXJlIHJlZHVjZWQuJm5ic3A7IDxvOnA+DQo8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklJVUMsIHRoZSBsb2cgd2lsbCBuZXZlciByZWZ1c2UgdG8gaW5j bHVkZSBhIGNlcnRpZmljYXRlLCBpdCB3aWxsIG1lcmVseSBpbmRpY2F0ZSBpdCBmYWlsZWQgc3lu dGFjdGljIGNoZWNrcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IFRMUyBjbGllbnRzIHdpbGwgcmVqZWN0 IGFuIG90aGVyd2lzZS12YWxpZCBjZXJ0aWZpY2F0ZSBjaGFpbiB3aGljaCBoYXMgYSZuYnNwO0ND SUQgdGhhdCBtYXRjaGVzIHRoZSBUTFMgY2xpZW50J3MgZGVzaXJlZCB1c2Ugb2YgdGhlIGNlcnRp ZmljYXRlLCBiZWNhdXNlIHRoZSBsb2cgaW5kaWNhdGVkIGl0IGZhaWxlZCBzeW50YWN0aWMgY2hl Y2tzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltTYW50b3NoXSBUaGF0IGNvdWxkIGJlIG9uZSB0aGluZy4m bmJzcDsgV2hhdCBJIHdhcyBzYXlpbmcgaW4gdGhlIHRocmVhZCBpcyB0aGF0IGV2ZW4gaWYgdGhl IExvZyBzYWlkIHRoYXQgdGhlIGNlcnRpZmljYXRlIHBhc3NlZCB0aGUgY2hlY2tzLCBjbGllbnQg bXVzdCBkbw0KIGl0cyBvd24gcGF0aCB2YWxpZGF0aW9uIHVubGVzcyB0aGUgY2xpZW50IGFuZCBs b2cgYXJlIHVzaW5nIHRoZSBzYW1lIGNoYWluIGFuZCBzYW1lIDUyODAgcGF0aCB2YWxpZGF0aW9u IGluaXRpYWxpemF0aW9uIHZhcmlhYmxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmUgYWR2YW50YWdlIG9m IGxvZ3MgZG9pbmcgY2hlY2tpbmcgYW5kIHJlamVjdGluZyB0aGUgY2VydGlmaWNhdGVzIGlzIHRo YXQgdGhlIGh1bWFuIHVzZXIgd2lsbCBub3QgZ28gdGhyb3VnaCB0aGUgZXJyb3ItcHJvbmUgZGVj aXNpb24gbWFraW5nIGFib3V0IHRoZQ0KIHNlY3VyaXR5IHJhbWlmaWNhdGlvbiBvZiBmYWlsZWQg cGF0aCB2YWxpZGF0aW9uLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl0J3Mgbm90IGEgYmFkIHRoaW5nLCBpdCBkb2VzIHBsYWNlIGFkZGl0aW9uYWwg YnVyZGVuIG9uIGxvZ3MgdGhvdWdoLiBNb25pdG9ycyB3aWxsIGhhdmUgdG8gdmVyaWZ5IHRoZSBs b2cncyBob25lc3QgYmVoYXZpb3VyIG9uIHRoaXMgYXNwZWN0IGFzIHdlbGwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvdGhlciBxdWVz dGlvbiBpcyAtIGFyZW4ndCBjZXJ0aWZpY2F0ZSBjbGFzc2VzIGRpZmZlcmVudCBlbm91Z2ggdG8g bWVyaXQgcnVubmluZyBkaWZmZXJlbnQgbG9ncywgd2hlcmUgdGhlIGxvZydzIGlkZW50aXR5IChv ciBzb21lIG90aGVyIG1ldGFkYXRhKSBpbmRpY2F0ZXMgd2hpY2ggQ0NJRCBpdCdzIGdvb2QgZm9y PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdt IGEgYml0IHdlYXJ5IG9mIHNwZWNpZnlpbmcgYSBiZWhhdmlvdXIgZm9yIHRoZSBnZW5lcmFsIGNh c2Ugd2hlcmUgSSBkb24ndCBoYXZlIGNvbmNyZXRlIGV4YW1wbGVzIGZvciBtb3JlIHRoYW4gb25l IHBhcnRpY3VsYXIgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bU2FudG9zaF0gVG8gbXkga25vd2xl ZGdlLCBsb3Qgb2YgcGF0aCBjaGVja3MgYXJlIHRoZSBzYW1lLiZuYnNwOyBEaWZmZXJlbnQgY2xh c3NlcyBvZiBjZXJ0aWZpY2F0ZXMgbWF5IHdhcnJhbnQgY2hlY2tpbmcgS1UsIEVLVSBhbmQgZXh0 cmFjdGluZyBhbmQgbWF0Y2hpbmcNCiBuYW1lcyBmcm9tIGRpZmZlcmVudCBmaWVsZHMgKHNheSBT dWJqZWN0IEROIG9yIFNBTikuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMjgsIDIwMTQgYXQgMjowOSBBTSwgU2FudG9zaCBDaG9r aGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjaG9raGFuaUBjeWduYWNvbS5jb20iIHRhcmdldD0i X2JsYW5rIj5zY2hva2hhbmlAY3lnbmFjb20uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWx5aW5nIHBhcnRpZXMgcmVseWluZyBvbiB0 aGUgY2hlY2tzIG1hZGUgYnkgbG9nIHNlcnZlciBtYXkgYmUgcHJvYmxlbWF0aWMgaWYgYm90aCBk byBub3QgaGF2ZSB0aGUNCiBzYW1lIHRydXN0IHN0b3JlIGlmIHRoZSBpbml0aWFsaXphdGlvbiB2 YXJpYWJsZXMgYXJlIGRpZmZlcmVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5NeSBwcmltYXJ5IG1vdGl2YXRpb24gaW4gbG9nIGRvaW5nIGNoZWNrcyBp cyBuaXAgdGhlIHByb2JsZW0gaW4gdGhlIGJ1ZCBhbmQgcmVkdWNlIHRoZSBwcm9iYWJpbGl0eQ0K IG9mIHJlbHlpbmcgcGFydGllcyBoYXZpbmcgdG8gZGVjaWRlIG9uIGV4Y2VwdGlvbnMuJm5ic3A7 IFRoZSByZWx5aW5nIHBhcnRpZXMgc3RpbGwgc2hvdWxkIHZhbGlkYXRlIHRoZSBjZXJ0aWZpY2F0 aW9uIHBhdGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g VHJhbnMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHJhbnMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5SaWNrIEFuZHJld3M8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDI3LCAy MDE0IDY6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IFJ1c3MgSG91c2xleTsgU3RldmUgS2VudDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbnNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj50cmFuc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUcmFuc10g R29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZncmFtZXdvcms8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UnVzcywgY29tbWVudHMgaW5saW5lLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi1SaWNrPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi PiBUcmFucyBbPGEgaHJlZj0ibWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86dHJhbnMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlJ1c3MgSG91c2xleTxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciAy NSwgMjAxNCAxMDowMSBBTTxicj4NCjxiPlRvOjwvYj4gUmljayBBbmRyZXdzOyBTdGV2ZSBLZW50 PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbnNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50cmFuc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUcmFu c10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZncmFtZXdvcms8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClN0ZXZlIGFuZCBSaWNrOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q291cmllcjtjb2xvcjpibGFjayI+MS4gQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5IEdvYWxz IGFuZCBNZWNoYW5pc21zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPlRoZSBnb2FscyBvZiBDZXJ0 aWZpY2F0ZSBUcmFuc3BhcmVuY3kgKENUKSBhcmUgdGhyZWVmb2xkOiBkZXRlY3Rpb24sIGRldGVy cmVuY2UsIGFuZCBlbmFibGluZyByZW1lZGlhdGlvbiBvZiBtaXMtaXNzdWFuY2Ugb2YgY2VydGlm aWNhdGVzLiBUaGUgaW5pdGlhbCBmb2N1cyBvZiBDVCBpcyB0aGUgV2ViIFBLSSBjb250ZXh0LCAo VGhlIFdlYiBQS0kgY29udGV4dCByZWZlcnMNCiB0byB0aGUgdXNlIG9mIGEgc2V0IG9mIENlcnRp ZmljYXRpb24gQXV0aG9yaXRpZXMgKENBcykgdGhhdCBpc3N1ZSBYLjUwOSBjZXJ0aWZpY2F0ZXMg dG8gd2ViIHNlcnZlcnMgdG8gZW5hYmxlIFRMUy1wcm90ZWN0ZWQgYWNjZXNzIGJ5IGNsaWVudHMg W2NpdGUgV1BLT1BTP10uKSBJbiB0aGUgZnV0dXJlLCBpdCBpcyBhbnRpY2lwYXRlZCB0aGF0Jm5i c3A7PHM+YWRkaXRpb248L3M+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOiMxRjQ5N0QiPio8Yj5hZGRpdGlvbmFsPC9iPio8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPm9wZXJhdGlvbmFsDQogY29udGV4 dHMgbWF5IGJlIHN1cHBvcnRlZC4gQXMgYSByZXN1bHQsIG1pcy1pc3N1YW5jZSBpcyBkZWZpbmVk IGluIGFuIGZhc2hpb24gdGhhdCBhY2NvbW1vZGF0ZXMgYSByYW5nZSBvZiB0eXBlcyBvZiBjZXJ0 aWZpY2F0ZXMgdXNlZCBpbiBhIHJhbmdlIG9mIGNvbnRleHRzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291 cmllcjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJs YWNrIj5DVCBzdXBwb3J0cyBkZXRlY3Rpb24gb2YgbWlzLWlzc3VhbmNlIHVzaW5nIGxvZ3Mgb2Yg Y2VydGlmaWNhdGVzLCBwb3B1bGF0ZWQgYnkgdGhlIENBcyB0aGF0IGlzc3VlIHRoZW0gb3IgYnkg dGhlIFN1YmplY3RzIG9mIGNlcnRpZmljYXRlcy4gTW9uaXRvcnMgKGRlc2NyaWJlZCBpbiBTZWN0 aW9uJm5ic3A7PGI+WDwvYj4pIGFyZSB0aGUgcHJpbWFyeSBlbGVtZW50cyBvZiB0aGUNCiBDVCBz eXN0ZW0gdGhhdCBjaGVjayBjZXJ0aWZpY2F0ZXMgZm9yIHN5bnRhY3RpYyBhbmQgc2VtYW50aWMg bWlzLWlzc3VhbmNlLCBvbiBiZWhhbGYgb2YgU3ViamVjdHMuIEEgTW9uaXRvciBtYXkgYmUgb3Bl cmF0ZWQgYnkgYSB0aGlyZCBwYXJ0eSBvbiBiZWhhbGYgb2YgU3ViamVjdHMsIG9yIG1heSBiZSBv cGVyYXRlZCBieSBhIFN1YmplY3Qgb24gaXRzIG93biBiZWhhbGYuIChUaGUgbGF0dGVyIGlzIHJl ZmVycmVkIHRvIGFzIOKAnHNlbGYtbW9uaXRvcmluZ+KAnS4pDQogTG9ncyBtYXkgb3B0aW9uYWxs eSBwZXJmb3JtIHN5bnRhY3RpYyBjaGVja3MgZm9yIHNvbWUgY2xhc3NlcyBvZiBjZXJ0aWZpY2F0 ZXMsIGJ1dCBhIGxvZyBpcyBub3QgcmVxdWlyZWQgdG8gb2ZmZXIgY2VydGlmaWNhdGUgY2hlY2tp bmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoZSBmaXJzdCBzZW50ZW5jZSBuZWVkcyB0byBiZSBtb3JlIGJyb2FkLCBzaW5jZSBhbnlvbmUg Y2FuIHNlbmQgYSBjZXJ0IHRvIGEgbG9nLiBCdXQgaXTigJlzIG1vc3QgbGlrZWx5IHRvIGJlIHRo ZSBDQXMgb3IgdGhlIFN1YmplY3RzLCBzbyBJIHdvdWxkIHN1Z2dlc3Qg4oCcQ1Qgc3VwcG9ydHMg ZGV0ZWN0aW9uIG9mDQogbWlzLWlzc3VhbmNlIHVzaW5nIGxvZ3Mgb2YgY2VydGlmaWNhdGVzLCBw b3B1bGF0ZWQgYnkgdGhlIENBcyB0aGF0IGlzc3VlIHRoZW0sIGJ5IHRoZSBTdWJqZWN0cyBvZiBj ZXJ0aWZpY2F0ZXMsIG9yIGJ5IGFueW9uZSB3aXRoIGtub3dsZWRnZSBvZiB0aGUgZW50aXJlIGNl cnRpZmljYXRlIGNoYWluLuKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQpDYW4ndCBhbnlvbmUgYnVpbGQgdGhlIGNlcnRpZmljYXRlIGNoYWluPyZuYnNw OyBTaW5jZSB0aGUgbG9ncyBhcmUgcG9zdGluZyB0aGUgc3VwcG9ydGVkIHRydXN0IGFuY2hvcnMs IGFueW9uZSBjYW4gYnVpbGQgYSBjaGFpbiBmb3IgdGhlIGVuZCBlbnRpdHkgY2VydGlmaWNhdGUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUmlja10g SW4gbW9zdCBjYXNlcywgeWVzLiBJZiBzb21lb25lIGhhcyBhY2Nlc3MgdG8gdGhlIHNlcnZlciBj b25maWd1cmVkIHdpdGggdGhhdCBjZXJ0aWZpY2F0ZSwgdGhleSBjYW4NCiBkbyBhIFRMUyBoYW5k c2hha2UgYW5kIGdldCB0aGUgY2hhaW4gaW4gbmVhcmx5IGFsbCBjYXNlcy4gV2Ugc2VlIHNvbWUg d2ViIHNlcnZlcnMgdGhhdCBhcmUgbWlzc2luZyB0aGUgaW50ZXJtZWRpYXRlIENBIGNlcnQsIGFu ZCBzb21lIGJyb3dzZXJzIChJRSwgZm9yIGV4YW1wbGUpIHdpbGwgZm9sbG93IHRoZSBBSUEgZXh0 ZW5zaW9uIChpZiBpdOKAmXMgaW4gdGhlIGNlcnQpIGFuZCBmZXRjaCB0aGUgaW50ZXJtZWRpYXRl LiBBbnkgY2xpZW50IGNhbg0KIGRvIHRoYXQgdG9vLiBCdXQgaWYgdGhlIENBIGRpZG7igJl0IHB1 dCBhbiBBSUEgZXh0ZW5zaW9uIGluIHRoZSBjZXJ0IGFuZCB5b3UgY2Fu4oCZdCBmaW5kIGEgc2Vy dmVyIHdpdGggdGhhdCBjZXJ0LCBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgdG8gZmluZCB0aGUg aW50ZXJtZWRpYXRlIENBIGNlcnQuIEFuZCB3aXRob3V0IHRoZSBpbnRlcm1lZGlhdGUgKG9yIGlu dGVybWVkaWF0ZXMhKSB0aGUgbG9nIHdvbuKAmXQgYWNjZXB0IGl0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6 YmxhY2siPlRvIGVuYWJsZSBNb25pdG9ycyAoYW5kLCBvcHRpb25hbGx5LCBsb2dzKSB0byBwZXJm b3JtIGFuIGFwcHJvcHJpYXRlIHNldCBvZiBjaGVja3MsJm5ic3A7PHM+dGhlIChwcmUtKTwvcz4m bmJzcDthIENDSUQgTVVTVCBiZSBwcm92aWRlZCB0byBhIGxvZyB3aGVuIGEgY2VydGlmaWNhdGUg aXMgc3VibWl0dGVkIGJ5IGEgQ0Egb3IgU3ViamVjdC4gVGhpcyBDQ0lEIE1VU1QgYXBwZWFyIGlu DQogdGhlIGxvZyBlbnRyeSBhbmQgaW4gdGhlIFNDVCBnZW5lcmF0ZWQgYnkgdGhlIGxvZy4gQnkg cHJvdmlkaW5nIHRoZSBDQ0lEIGluIGxvZ3MgYW5kIFNDVHMsIGJvdGggTW9uaXRvcnMgYW5kIGNs aWVudHMgYXJlIGVtcG93ZXJlZCB0byBwZXJmb3JtIGFwcGxpY2FibGUgY2hlY2tzIGJhc2VkIG9u IHRoZSBjZXJ0aWZpY2F0ZSBjbGFzcyBhc3NlcnRlZCBieSB0aGUgQ0Egb3IgU3ViamVjdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG1t4oCm IFNpbmNlIGFueW9uZSBjYW4gc2VuZCBhIGNlcnQgdG8gYSBsb2csIHRoZSBmaXJzdCBzZW50ZW5j ZSBtdXN0IHJlZmxlY3QgdGhhdC4gQnV0IHRoYXQgbWFrZXMgbWUgd29uZGVyIHdoYXQgc2hvdWxk IGhhcHBlbiBpZiB0aGUg4oCcUmVwb3J0ZXLigJ0gKEkgZG9u4oCZdCB3YW50IHRvIGludHJvZHVj ZSBhIG5ldyByb2xlKQ0KIHNlbmRzIHRoZSB3cm9uZyBDQ0lEPyAoQnkg4oCcd3JvbmfigJ0gSSBt ZWFuIGl04oCZcyBhIHZhbGlkIENDSUQsIGJ1dCBpdOKAmXMgbm90IHRoZSBvbmUgdGhhdCB0aGUg Q0Egd291bGQgYXNzb2NpYXRlIHdpdGggdGhlIGNlcnQuKSBPciBzZW5kcyB0aGUgY2VydCBtdWx0 aXBsZSB0aW1lcyB3aXRoIGRpZmZlcmVudCBDQ0lEcz8gSSBndWVzcyBNb25pdG9ycyB3b3VsZCBo YXZlIHRvIGV4cGVjdCBtdWx0aXBsZSBlbnRyaWVzIGZvciBhIGdpdmVuIGNlcnRpZmljYXRlDQog aW4gYSBnaXZlbiBsb2csIHdpdGggZGlmZmVyZW50IENDSURzLiBJ4oCZbSBub3Qgc3VyZSBpZiA2 OTYyLWJpcyBpbXBvc2VzIGFueSB1bmlxdWVuZXNzIGNvbnN0cmFpbnQgdGhhdCB0aGlzIG1pZ2h0 IHZpb2xhdGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCkFsdGVybmF0aXZlbHksIGEgbG9nIGNvdWxkIGNoZWNrIHRvIHNlZSBpZiB0aGUg cmVwb3J0ZWQgY2VydGlmaWNhdGUgaXMgYWxyZWFkeSBwcmVzZW50LCBhbmQgaWYgc28sIHJldHVy biB0aGUgb2xkZXIgZW50cnkgdG8gdGhlIHBhcnR5IHRoYXQgcmVwb3J0cyB0aGUgY2VydGlmaWNh dGUuJm5ic3A7IEkgc2VlbSB0byByZWNhbGwgcmVhZGluZyB0aGlzIGlkZWEgYXQgc29tZSBwb2lu dCwgYnV5IEkgYWRtaXQgSSBkaWQgbm90IGxvb2sgaW50byB0aGUgY3VycmVudA0KIEktRCB0byBz ZWUgaWYgdGhhdCB3YXMgd2hlcmUgaSByZWFkIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1JpY2tdIFJGQyA2 OTYyIGFuZCBiaXMtMDQgc2F5IOKAnElmIHRoZSBsb2cgaGFzIHByZXZpb3VzbHkgc2VlbiB0aGUg Y2VydGlmaWNhdGUsIGl0IE1BWSByZXR1cm4gdGhlIHNhbWUNCiBTQ1QgYXMgaXQgcmV0dXJuZWQg YmVmb3JlLuKAnSBCdXQgdGhpcyB3b3VsZCBoYXZlIHRvIGJlIGV4cGFuZGVkIHRvIHNheSDigJxJ ZiB0aGUgbG9nIGhhcyBwcmV2aW91c2x5IHNlZW4gdGhlIGNlcnRpZmljYXRlDQo8Yj5hbmQgQ0NJ RDwvYj4sIGl0IE1BWSByZXR1cm4gdGhlIHNhbWUgU0NUIGFzIGl0IHJldHVybmVkIGJlZm9yZS7i gJ0gSXTigJlzIGEgYml0IG1vcmUgY29tcGxleCwgc2luY2UgdGhlIGxvZyBzZXJ2ZXIgbWF5IG5v dCBzdXBwb3J0IHRoZSBDQ0lEIG9yIGFueSBjaGVja2luZywgaW4gd2hpY2ggY2FzZXMgaXQgd291 bGQgYWx3YXlzIGxvZyB0aGUgZW50cnkgd2l0aCBDQ0lEID0xIHRoYXQgaW5kaWNhdGVzIOKAnFRo aXMgbG9nIGRvZXMgbm90IHBlcmZvcm0gc3ludGF4DQogY2hlY2tz4oCdLCBvciBDQ0lEPTIgdGhh dCBpbmRpY2F0ZXMg4oCcVGhpcyBsb2cgZG9lcyBub3Qgc3VwcG9ydCBzeW50YXggY2hlY2tzIGZv ciB0aGUgYXNzZXJ0ZWQgQ0NJROKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6 YmxhY2siPkEgbG9nIE1VU1QgZ2VuZXJhdGUgYSBTeW50YXggVmVyaWZpY2F0aW9uIFZhbHVlIChT VlYpIGZvciB0aGUgY2VydGlmaWNhdGUsIGFuZCBpbmNsdWRlIHRoZSBTVlYgaW4gdGhlIGxvZyBl bnRyeSBhbmQgaW4gdGhlIFNDVC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si PlRoZSZuYnNwOzxzPkxWVjwvcz48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJp ZXI7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7KjxiPlNWVjwvYj4qPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDtpcyZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjojMUY0OTdEIj4qPGI+YTwvYj4qJm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj52 YWx1ZQ0KIHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50IChzZWUgU2VjdGlvbiBaKSB0aGF0IGlu ZGljYXRlcyB3aGV0aGVyIG9yIG5vdCB0aGUgbG9nIHBlcmZvcm1lZCBhcHBsaWNhYmxlIHN5bnRh Y3RpYyBjaGVja3MsIGFuZCB3aGV0aGVyIHRoZSAocHJlLSkgY2VydGlmaWNhdGUgcGFzc2VkJm5i c3A7PHM+b2Y8L3M+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVy O2NvbG9yOiMxRjQ5N0QiPio8Yj5vcjwvYj4qJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5mYWlsZWQNCiB0aGUgY2hlY2tzLiBBbHRob3Vn aCBpdCBpcyBhbnRpY2lwYXRlZCB0aGF0IG5ldyBjZXJ0aWZpY2F0ZSBjbGFzc2VzIHdpbGwgYXJp c2Ugb3ZlciB0aW1lLCB0aGUgc2V0IG9mIGxvZyBhY3Rpb25zIHdpdGggcmVzcGVjdCB0byBzeW50 YXggY2hlY2tpbmcgYXBwZWFycyB0byBiZSB3ZWxsLWRlZmluZWQgYW5kIHRodXMgbmVlZCBub3Qg YmUgcmVwcmVzZW50ZWQgaW4gYW4gSUFOQSByZWdpc3RyeS4gRWFjaCBTQ1QgaXNzdWVkIGJ5IGEg bG9nIE1VU1QNCiBpbmNsdWRlIGFuIFNWVi4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVy O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrIj5WYWx1ZSBJbnRlcnByZXRhdGlvbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXI7Y29sb3I6YmxhY2siPjA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+VGhlIENDSUQgdmFsdWUg d2FzIDAsIHNvJm5ic3A7PHM+bm90PC9zPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q291cmllcjtjb2xvcjojMUY0OTdEIj4qPGI+bm88L2I+KiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Y2hlY2tzDQogd2VyZSBw ZXJmb3JtZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4xPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29s b3I6YmxhY2siPlRoaXMgbG9nIGRvZXMgbm90IHBlcmZvcm0gc3ludGF4IGNoZWNrczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+VGhpcyBs b2cgZG9lcyBub3Qgc3VwcG9ydCBzeW50YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQgQ0NJRDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjM8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ VGhpcyBsb2cgcGVyZm9ybWVkIHRoZSBzeW50YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQgQ0NJ RCwNCiBhbmQgdGhlIGNlcnRpZmljYXRlIHBhc3NlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7 Y29sb3I6YmxhY2siPjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+VGhpcyBsb2cgcGVyZm9ybWVkIHRoZSBz eW50YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQgQ0NJRCwNCiBhbmQgdGhlIGNlcnRpZmljYXRl IGZhaWxlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5ObyBvdGhlciBTVlYgdmFsdWVzIGFyZSBk ZWZpbmVkIGJ5IHRoaXMgUkZDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCklmIHRoZSBsb2cgcGVyZm9ybXMgc29tZSB2YWxpZGF0aW9uIGNoZWNrcywgYXJl IHlvdSBzdWdnZXN0aW5nIHRoYXQgYSByZWx5aW5nIHBhcnR5IGNhbiBsZXZlcmFnZSB0aGUgd29y ayBhbHJlYWR5IGRvbmUgYnkgdGhlIGxvZz8mbmJzcDsgSWYgc28sIGl0IHB1dHMgdGhlIGxvZyBj aGVja2luZyBhdCBhIGRpZmZlcmVudCBwbGFjZSBpbiB0aGUgY2VydGlmaWNhdGUgdmFsaWRhdGlv biB0aGFuIEkgd2FzIGltYWdpbmluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSaWNrXSBZZXMsIGEgcmVseWlu ZyBwYXJ0eSBjb3VsZCBsZXZlcmFnZSB0aGUgd29yayBhbHJlYWR5IGRvbmUgYnkgdGhlIGxvZyBz ZXJ2ZXIsIGlmIHRoZSBSUCB0cnVzdGVkDQogaXQuIEdvb2dsZSB3b3VsZCBwcm9iYWJseSBhZHZp c2UgYWdhaW5zdCB0aGlzLCBzaW5jZSB0aGV5IGhhdmUgYmVlbiBwcmV0dHkgY29uc2lzdGVudCBp biBzYXlpbmcgdGhhdCBDVCBkb2VzbuKAmXQgcmVxdWlyZSB5b3UgdG8gdHJ1c3QgYW55b25lIGlu Y2x1ZGluZyB0aGUgbG9nIHNlcnZlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpUcmFucyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86VHJhbnNAaWV0Zi5vcmciPlRyYW5zQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW5zPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4262AC0DB9856847A2D00EF817E81139243DF5scygexch10cygnaco_-- From nobody Wed Oct 29 04:32:19 2014 Return-Path: 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 ; 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 ; 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 ; Wed, 29 Oct 2014 04:32:13 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id m8so2171840obr.24 for ; 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> <4262AC0DB9856847A2D00EF817E81139243DF5@scygexch10.cygnacom.com> Date: Wed, 29 Oct 2014 11:32:12 +0000 Message-ID: From: Eran Messeri To: Santosh Chokhani Content-Type: multipart/alternative; boundary=001a113d5d127663c505068e1dbb Archived-At: http://mailarchive.ietf.org/arch/msg/trans/LETqb7ag_hfnHyW5d9HrKmzEtPM Cc: "trans@ietf.org" , Russ Housley , Steve Kent , Rick Andrews 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 11:32:18 -0000 --001a113d5d127663c505068e1dbb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 an= d > 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 > 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 initializatio= n > 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 ] *O= n > 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 t= o > the use of a set of Certification Authorities (CAs) that issue X.509 > certificates to web servers to enable TLS-protected access by clients [ci= te > WPKOPS?].) In the future, it is anticipated that addition **additional**o= perational > 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 rang= e > 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, o= n > 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 =E2=80=9Cself-monitoring=E2=80=9D.) Logs may optionally pe= rform syntactic > checks for some classes of certificates, but a log is not required to off= er > certificate checking. > > The first sentence needs to be more broad, since anyone can send a cert t= o > a log. But it=E2=80=99s most likely to be the CAs or the Subjects, so I w= ould > suggest =E2=80=9CCT supports detection of mis-issuance using logs of cert= ificates, > populated by the CAs that issue them, by the Subjects of certificates, or > by anyone with knowledge of the entire certificate chain.=E2=80=9D. > > > > 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 intermedia= te > CA cert, and some browsers (IE, for example) will follow the AIA extensio= n > (if it=E2=80=99s in the cert) and fetch the intermediate. Any client can = do that > too. But if the CA didn=E2=80=99t put an AIA extension in the cert and yo= u can=E2=80=99t > find a server with that cert, it might not be possible to find the > intermediate CA cert. And without the intermediate (or intermediates!) th= e > log won=E2=80=99t 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 a= nd > 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 base= d > on the certificate class asserted by the CA or Subject. > > Hmm=E2=80=A6 Since anyone can send a cert to a log, the first sentence mu= st > reflect that. But that makes me wonder what should happen if the =E2=80= =9CReporter=E2=80=9D > (I don=E2=80=99t want to introduce a new role) sends the wrong CCID? (By = =E2=80=9Cwrong=E2=80=9D I > mean it=E2=80=99s a valid CCID, but it=E2=80=99s 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=E2=80=99m 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 poin= t, > 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 =E2=80=9CIf the log has previously seen th= e > certificate, it MAY return the same SCT as it returned before.=E2=80=9D B= ut this > would have to be expanded to say =E2=80=9CIf the log has previously seen = the > certificate *and CCID*, it MAY return the same SCT as it returned > before.=E2=80=9D It=E2=80=99s a bit more complex, since the log server ma= y not support the > CCID or any checking, in which cases it would always log the entry with > CCID =3D1 that indicates =E2=80=9CThis log does not perform syntax checks= =E2=80=9D, or CCID=3D2 > that indicates =E2=80=9CThis log does not support syntax checks for the a= sserted > CCID=E2=80=9D. > > > > > > 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 aris= e > 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=E2= =80=99t > require you to trust anyone including the log server. > > > > > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > --001a113d5d127663c505068e1dbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 SC= T 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 fie= ld in the SCT there's no immediate use for.

As I sai= d, I see the value in getting an "independent opinion" on the val= idity of a chain submitted to the log (both in syntactic and semantic compl= iance perspectives) and is much more useful than the current error handling= approach (where the log returns a vague error). I just like to exclude thi= s 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 <schokhan= i@cygnacom.com> wrote:

Eran,

=C2=A0

See in-line below.

=C2=A0

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

=C2=A0

Overall the mechanism described seems reasonable. Ca= n you help me understand the benefits from the TLS client's perspective= ?

[Santosh] The primary benefit w= ould have come if the log had enforced and not registered a mal-formed cert= ificate.=C2=A0 Log acceptance of certificate seems to what the WG prefers.=C2=A0 In that case, benefits to the client are red= uced.=C2=A0

=C2=A0

IIUC, the log will never refuse to include a certifi= cate, it will merely indicate it failed syntactic checks.

Are you suggesting that TLS clients will reject an o= therwise-valid certificate chain which has a=C2=A0CCID 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.=C2=A0 What I was saying in the thread is that even if the Log sa= id 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.

=C2=A0=

One advantage of logs doing che= cking and rejecting the certificates is that the human user will not go thr= ough the error-prone decision making about the security ramification of failed path validation.

=C2=A0

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

=C2=A0

The other question is - aren't certificate class= es different enough to merit running different logs, where the log's id= entity (or some other metadata) indicates which CCID it's good for?<= /u>

I'm a bit weary of specifying a behaviour for th= e general case where I don't have concrete examples for more than one p= articular case.

[Santosh] To my knowledg= e, lot of path checks are the same.=C2=A0 Different classes of certificates= may warrant checking KU, EKU and extracting and matching names from different fields (say Subject DN or SAN).

=C2=A0

On Tue, Oct 28, 2014 at 2:09 AM, Santosh Chokhani &l= t;schokhani@cyg= nacom.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.<= /u>

=C2=A0

My primary motivation in log doing ch= ecks is nip the problem in the bud and reduce the probability of relying parties having to decide on exceptions.=C2=A0 The relying parti= es still should validate the certification path.

=C2=A0

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.o= rg
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

=C2=A0

Russ, comments inline.<= u>

=C2=A0

-Rick

=C2=A0

From: Trans [mailto: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.o= rg
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

=C2=A0

Steve and Rick:

=C2=A0

=C2=A0=

1. Certificate Transparency= Goals and Mechanisms

=C2=A0=

The goals of Certificate Tr= ansparency (CT) are threefold: detection, deterrence, and enabling remediat= ion 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 ce= rtificates to web servers to enable TLS-protected access by clients [cite W= PKOPS?].) In the future, it is anticipated that=C2=A0addition=C2=A0<= /span>*additional*= operational contexts may be supported. As a result, mis-issuance is defined in an fash= ion that accommodates a range of types of certificates used in a range of c= ontexts.

=C2=A0=

CT supports detection of mi= s-issuance using logs of certificates, populated by the CAs that issue them= or by the Subjects of certificates. Monitors (described in Section=C2=A0X) 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 behal= f of Subjects, or may be operated by a Subject on its own behalf. (The latt= er is referred to as =E2=80=9Cself-monitoring=E2=80=9D.) Logs may optionally perform syntactic checks for some classes of certifica= tes, 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=E2=80=99s most likely to be the CAs or the Sub= jects, so I would suggest =E2=80=9CCT supports detection of mis-issuance using logs of certificates, populated by the CAs that issue t= hem, by the Subjects of certificates, or by anyone with knowledge of the en= tire certificate chain.=E2=80=9D.

=C2=A0

Can't anyone build the certificate chain?=C2=A0 Since the logs are post= ing the supported trust anchors, anyone can build a chain for the end entit= y certificate.

=C2=A0

[Rick]= In most cases, yes. If someone has access to the server configured with th= at 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, f= or example) will follow the AIA extension (if it=E2=80=99s in the cert) and= fetch the intermediate. Any client can do that too. But if the CA didn=E2=80=99t put an AIA extension in the cert= and you can=E2=80=99t find a server with that cert, it might not be possib= le to find the intermediate CA cert. And without the intermediate (or inter= mediates!) the log won=E2=80=99t accept it.

=C2=A0=

To enable Monitors (and, op= tionally, logs) to perform an appropriate set of checks,=C2=A0the (pre-)= =C2=A0a 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 i= n logs and SCTs, both Monitors and clients are empowered to perform applica= ble checks based on the certificate class asserted by the CA or Subject.

Hmm=E2=80=A6 Since anyone can send a cert to a log, the firs= t sentence must reflect that. But that makes me wonder what should happen i= f the =E2=80=9CReporter=E2=80=9D (I don=E2=80=99t want to introduce a new r= ole) sends the wrong CCID? (By =E2=80=9Cwrong=E2=80=9D I mean it=E2=80=99s a va= lid CCID, but it=E2=80=99s not the one that the CA would associate with the= cert.) Or sends the cert multiple times with different CCIDs? I guess Moni= tors would have to expect multiple entries for a given certificate in a given log, with different CCIDs. I=E2=80=99m not sure if 6962-bis imp= oses any uniqueness constraint that this might violate.=C2=A0=C2=A0

=C2=A0

Alternatively, a log could check to see if the reported certificate is alre= ady present, and if so, return the older entry to the party that reports th= e certificate.=C2=A0 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 =E2=80= =9CIf the log has previously seen the certificate, it MAY return the same SCT as it returned before.=E2=80=9D But this would have to be expanded to = say =E2=80=9CIf the log has previously seen the certificate and CCID, it MAY return the same SCT as it returned before.=E2=80=9D= It=E2=80=99s 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 CCI= D =3D1 that indicates =E2=80=9CThis log does not perform syntax checks=E2=80=9D, or CCID=3D2 that indicates =E2=80=9CThis log does not sup= port syntax checks for the asserted CCID=E2=80=9D.

=C2=A0

=C2=A0=

A log MUST generate a Synta= x Verification Value (SVV) for the certificate, and include the SVV in the = log entry and in the SCT.

The=C2=A0LVV<= span style=3D"font-family:Courier;color:#1f497d">=C2=A0*SVV*<= span style=3D"font-family:Courier;color:black">=C2=A0is=C2=A0*a*=C2=A0value specified by this document (see Section Z) that indicates whether or not t= he log performed applicable syntactic checks, and whether the (pre-) certif= icate passed=C2=A0of=C2=A0*or*=C2=A0failed the checks. Although it is anticipated that new certificate classes will a= rise over time, the set of log actions with respect to syntax checking appe= ars to be well-defined and thus need not be represented in an IANA registry= . Each SCT issued by a log MUST include an SVV. =C2=A0

=C2=A0=

=C2=A0=

Value Interpretation=

0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0The CCID value was 0, so=C2=A0not=C2=A0*no*=C2=A0checks were performed

1=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0This log does not perform syntax checks

2=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0This log does not support syntax checks for the asserted CCID

3=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0This log performed the syntax checks for the asserted CCID, and the certificate passed

4=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0This log performed the syntax checks for the asserted CCID, and the certificate failed

=C2=A0=

No other SVV values are def= ined by this RFC.

=C2=A0

If the log performs some validation checks, are you suggesting that a relyi= ng party can leverage the work already done by the log?=C2=A0 If so, it put= s the log checking at a different place in the certificate validation than = I was imagining.

[Rick] Yes, a relying party could lev= erage 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=E2=80=99t require you to trust anyone i= ncluding the log server.

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans

=C2=A0


--001a113d5d127663c505068e1dbb-- From nobody Wed Oct 29 13:21:21 2014 Return-Path: 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 C1F031A88A0 for ; Wed, 29 Oct 2014 13:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QJ__7JvGbZQs for ; Wed, 29 Oct 2014 13:21:14 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25EA1A88B3 for ; Wed, 29 Oct 2014 13:21:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.07,279,1413259200"; d="scan'208,217";a="2520735" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge2.cygnacom.com with ESMTP; 29 Oct 2014 16:21:11 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 16:21:11 -0400 From: Santosh Chokhani To: Eran Messeri Thread-Topic: [Trans] Goals and generic mis-issuance fgramework Thread-Index: AQHP5Ab2FAjCsOwr9kS2LsAemu1e1pw51z8AgAeOSQCAA4FJgP//90vggAE6LQD//+QFgIABVqgAgABPRkA= Date: Wed, 29 Oct 2014 20:21:10 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E81139244489@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> <4262AC0DB9856847A2D00EF817E81139243DF5@scygexch10.cygnacom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.7] Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E81139244489scygexch10cygnaco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/yR3x4uG4VeUHDpKo8ro7BhgOBRE Cc: "trans@ietf.org" , Russ Housley , Steve Kent , Rick Andrews 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:21:19 -0000 --_000_4262AC0DB9856847A2D00EF817E81139244489scygexch10cygnaco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSBvZiB0aGUgb3RoZXIgdXNhZ2VzIG9mIHRoZSBsb2cgY2hlY2tzIGFyZSB0aGF0IHN1Ympl Y3RzIGFuZCBDQXMgY2FuIGFsc28gc2VlIHRoaXMgYW5kIHRha2UgY29ycmVjdGl2ZSBhY3Rpb25z Lg0KDQpBbHNvLCBJIGFtIG5vdCBzYXlpbmcgcmVseWluZyBwYXJ0aWVzIGRvIG5vdCB1c2UgdGhl IGNoZWNrcyBtYWRlIGJ5IHRoZSBsb2dzLiBpdCBpcyBqdXN0IHRoYXQgdGhlIHJlbHlpbmcgcGFy dGllcyBtYXkgbmVlZCB0byBwZXJmb3JtIHRoZWlyIG93biBjaGVja3MgYWxzbyBkdWUgdG8gZGlm ZmVyZW5jZXMgaW4gbG9ncyBwZXJjZXB0aW9uIG9mIHBhdGggdmFsaWRhdGlvbiBzdGF0ZSBhbmQg cmVseWluZyBwYXJ0eeKAmXMuDQoNCkZyb206IEVyYW4gTWVzc2VyaSBbbWFpbHRvOmVyYW5tQGdv b2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjksIDIwMTQgNzozMiBBTQ0KVG86 IFNhbnRvc2ggQ2hva2hhbmkNCkNjOiBSaWNrIEFuZHJld3M7IFJ1c3MgSG91c2xleTsgU3RldmUg S2VudDsgdHJhbnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHJhbnNdIEdvYWxzIGFuZCBnZW5l cmljIG1pcy1pc3N1YW5jZSBmZ3JhbWV3b3JrDQoNCkluIHRoYXQgY2FzZSwgaG93IGFib3V0IGlu Y2x1ZGluZyB0aGUgQ0NJRCBhbmQgdGhlIHJlc3VsdHMgb2YgdGhlIGNoZWNrcyB0aGUgbG9nIHBl cmZvcm1lZCBpbiB0aGUgZ2V0LXN0aCByZXNwb25zZSwgYnV0IG5vdCBpbiB0aGUgU0NUIGl0c2Vs Zj8NCg0KVGhlIGxvZyBjb3VsZCBzdGlsbCBzaWduIHRoZSBjb21wbGV0ZSBnZXQtc3RoIHJlcGx5 IHNvIHN1Ym1pdHRlcnMgZ2V0IGEgY29uZmlybWF0aW9uIGl0IGlzIGluZGVlZCB0aGUgbG9nIHdo aWNoIHBlcmZvcm1lZCB0aGUgY2hlY2tzLCBhbmQgVExTIGNsaWVudHMgd2lsbCBub3QgYmUgYnVy ZGVuZWQgd2l0aCBoYW5kbGluZyBhbm90aGVyIGZpZWxkIGluIHRoZSBTQ1QgdGhlcmUncyBubyBp bW1lZGlhdGUgdXNlIGZvci4NCg0KQXMgSSBzYWlkLCBJIHNlZSB0aGUgdmFsdWUgaW4gZ2V0dGlu ZyBhbiAiaW5kZXBlbmRlbnQgb3BpbmlvbiIgb24gdGhlIHZhbGlkaXR5IG9mIGEgY2hhaW4gc3Vi bWl0dGVkIHRvIHRoZSBsb2cgKGJvdGggaW4gc3ludGFjdGljIGFuZCBzZW1hbnRpYyBjb21wbGlh bmNlIHBlcnNwZWN0aXZlcykgYW5kIGlzIG11Y2ggbW9yZSB1c2VmdWwgdGhhbiB0aGUgY3VycmVu dCBlcnJvciBoYW5kbGluZyBhcHByb2FjaCAod2hlcmUgdGhlIGxvZyByZXR1cm5zIGEgdmFndWUg ZXJyb3IpLiBJIGp1c3QgbGlrZSB0byBleGNsdWRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSBiZWlu ZyBlbWJlZGRlZCBpbiB0aGUgU0NUIGlmIGl0J3Mgbm90IHVzZWZ1bCBmb3IgVExTIGNsaWVudHMu DQoNCk9uIFR1ZSwgT2N0IDI4LCAyMDE0IGF0IDc6MjcgUE0sIFNhbnRvc2ggQ2hva2hhbmkgPHNj aG9raGFuaUBjeWduYWNvbS5jb208bWFpbHRvOnNjaG9raGFuaUBjeWduYWNvbS5jb20+PiB3cm90 ZToNCkVyYW4sDQoNClNlZSBpbi1saW5lIGJlbG93Lg0KDQpGcm9tOiBFcmFuIE1lc3NlcmkgW21h aWx0bzplcmFubUBnb29nbGUuY29tPG1haWx0bzplcmFubUBnb29nbGUuY29tPl0NClNlbnQ6IFR1 ZXNkYXksIE9jdG9iZXIgMjgsIDIwMTQgMTI6NDYgUE0NClRvOiBTYW50b3NoIENob2toYW5pDQpD YzogUmljayBBbmRyZXdzOyBSdXNzIEhvdXNsZXk7IFN0ZXZlIEtlbnQ7IHRyYW5zQGlldGYub3Jn PG1haWx0bzp0cmFuc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVHJhbnNdIEdvYWxzIGFuZCBn ZW5lcmljIG1pcy1pc3N1YW5jZSBmZ3JhbWV3b3JrDQoNCk92ZXJhbGwgdGhlIG1lY2hhbmlzbSBk ZXNjcmliZWQgc2VlbXMgcmVhc29uYWJsZS4gQ2FuIHlvdSBoZWxwIG1lIHVuZGVyc3RhbmQgdGhl IGJlbmVmaXRzIGZyb20gdGhlIFRMUyBjbGllbnQncyBwZXJzcGVjdGl2ZT8NCltTYW50b3NoXSBU aGUgcHJpbWFyeSBiZW5lZml0IHdvdWxkIGhhdmUgY29tZSBpZiB0aGUgbG9nIGhhZCBlbmZvcmNl ZCBhbmQgbm90IHJlZ2lzdGVyZWQgYSBtYWwtZm9ybWVkIGNlcnRpZmljYXRlLiAgTG9nIGFjY2Vw dGFuY2Ugb2YgY2VydGlmaWNhdGUgc2VlbXMgdG8gd2hhdCB0aGUgV0cgcHJlZmVycy4gIEluIHRo YXQgY2FzZSwgYmVuZWZpdHMgdG8gdGhlIGNsaWVudCBhcmUgcmVkdWNlZC4NCg0KSUlVQywgdGhl IGxvZyB3aWxsIG5ldmVyIHJlZnVzZSB0byBpbmNsdWRlIGEgY2VydGlmaWNhdGUsIGl0IHdpbGwg bWVyZWx5IGluZGljYXRlIGl0IGZhaWxlZCBzeW50YWN0aWMgY2hlY2tzLg0KQXJlIHlvdSBzdWdn ZXN0aW5nIHRoYXQgVExTIGNsaWVudHMgd2lsbCByZWplY3QgYW4gb3RoZXJ3aXNlLXZhbGlkIGNl cnRpZmljYXRlIGNoYWluIHdoaWNoIGhhcyBhIENDSUQgdGhhdCBtYXRjaGVzIHRoZSBUTFMgY2xp ZW50J3MgZGVzaXJlZCB1c2Ugb2YgdGhlIGNlcnRpZmljYXRlLCBiZWNhdXNlIHRoZSBsb2cgaW5k aWNhdGVkIGl0IGZhaWxlZCBzeW50YWN0aWMgY2hlY2tzPw0KW1NhbnRvc2hdIFRoYXQgY291bGQg YmUgb25lIHRoaW5nLiAgV2hhdCBJIHdhcyBzYXlpbmcgaW4gdGhlIHRocmVhZCBpcyB0aGF0IGV2 ZW4gaWYgdGhlIExvZyBzYWlkIHRoYXQgdGhlIGNlcnRpZmljYXRlIHBhc3NlZCB0aGUgY2hlY2tz LCBjbGllbnQgbXVzdCBkbyBpdHMgb3duIHBhdGggdmFsaWRhdGlvbiB1bmxlc3MgdGhlIGNsaWVu dCBhbmQgbG9nIGFyZSB1c2luZyB0aGUgc2FtZSBjaGFpbiBhbmQgc2FtZSA1MjgwIHBhdGggdmFs aWRhdGlvbiBpbml0aWFsaXphdGlvbiB2YXJpYWJsZXMuDQoNCk9uZSBhZHZhbnRhZ2Ugb2YgbG9n cyBkb2luZyBjaGVja2luZyBhbmQgcmVqZWN0aW5nIHRoZSBjZXJ0aWZpY2F0ZXMgaXMgdGhhdCB0 aGUgaHVtYW4gdXNlciB3aWxsIG5vdCBnbyB0aHJvdWdoIHRoZSBlcnJvci1wcm9uZSBkZWNpc2lv biBtYWtpbmcgYWJvdXQgdGhlIHNlY3VyaXR5IHJhbWlmaWNhdGlvbiBvZiBmYWlsZWQgcGF0aCB2 YWxpZGF0aW9uLg0KDQpJdCdzIG5vdCBhIGJhZCB0aGluZywgaXQgZG9lcyBwbGFjZSBhZGRpdGlv bmFsIGJ1cmRlbiBvbiBsb2dzIHRob3VnaC4gTW9uaXRvcnMgd2lsbCBoYXZlIHRvIHZlcmlmeSB0 aGUgbG9nJ3MgaG9uZXN0IGJlaGF2aW91ciBvbiB0aGlzIGFzcGVjdCBhcyB3ZWxsLg0KDQpUaGUg b3RoZXIgcXVlc3Rpb24gaXMgLSBhcmVuJ3QgY2VydGlmaWNhdGUgY2xhc3NlcyBkaWZmZXJlbnQg ZW5vdWdoIHRvIG1lcml0IHJ1bm5pbmcgZGlmZmVyZW50IGxvZ3MsIHdoZXJlIHRoZSBsb2cncyBp ZGVudGl0eSAob3Igc29tZSBvdGhlciBtZXRhZGF0YSkgaW5kaWNhdGVzIHdoaWNoIENDSUQgaXQn cyBnb29kIGZvcj8NCkknbSBhIGJpdCB3ZWFyeSBvZiBzcGVjaWZ5aW5nIGEgYmVoYXZpb3VyIGZv ciB0aGUgZ2VuZXJhbCBjYXNlIHdoZXJlIEkgZG9uJ3QgaGF2ZSBjb25jcmV0ZSBleGFtcGxlcyBm b3IgbW9yZSB0aGFuIG9uZSBwYXJ0aWN1bGFyIGNhc2UuDQpbU2FudG9zaF0gVG8gbXkga25vd2xl ZGdlLCBsb3Qgb2YgcGF0aCBjaGVja3MgYXJlIHRoZSBzYW1lLiAgRGlmZmVyZW50IGNsYXNzZXMg b2YgY2VydGlmaWNhdGVzIG1heSB3YXJyYW50IGNoZWNraW5nIEtVLCBFS1UgYW5kIGV4dHJhY3Rp bmcgYW5kIG1hdGNoaW5nIG5hbWVzIGZyb20gZGlmZmVyZW50IGZpZWxkcyAoc2F5IFN1YmplY3Qg RE4gb3IgU0FOKS4NCg0KT24gVHVlLCBPY3QgMjgsIDIwMTQgYXQgMjowOSBBTSwgU2FudG9zaCBD aG9raGFuaSA8c2Nob2toYW5pQGN5Z25hY29tLmNvbTxtYWlsdG86c2Nob2toYW5pQGN5Z25hY29t LmNvbT4+IHdyb3RlOg0KUmVseWluZyBwYXJ0aWVzIHJlbHlpbmcgb24gdGhlIGNoZWNrcyBtYWRl IGJ5IGxvZyBzZXJ2ZXIgbWF5IGJlIHByb2JsZW1hdGljIGlmIGJvdGggZG8gbm90IGhhdmUgdGhl IHNhbWUgdHJ1c3Qgc3RvcmUgaWYgdGhlIGluaXRpYWxpemF0aW9uIHZhcmlhYmxlcyBhcmUgZGlm ZmVyZW50Lg0KDQpNeSBwcmltYXJ5IG1vdGl2YXRpb24gaW4gbG9nIGRvaW5nIGNoZWNrcyBpcyBu aXAgdGhlIHByb2JsZW0gaW4gdGhlIGJ1ZCBhbmQgcmVkdWNlIHRoZSBwcm9iYWJpbGl0eSBvZiBy ZWx5aW5nIHBhcnRpZXMgaGF2aW5nIHRvIGRlY2lkZSBvbiBleGNlcHRpb25zLiAgVGhlIHJlbHlp bmcgcGFydGllcyBzdGlsbCBzaG91bGQgdmFsaWRhdGUgdGhlIGNlcnRpZmljYXRpb24gcGF0aC4N Cg0KRnJvbTogVHJhbnMgW21haWx0bzp0cmFucy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFu cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFJpY2sgQW5kcmV3cw0KU2VudDogTW9u ZGF5LCBPY3RvYmVyIDI3LCAyMDE0IDY6MzMgUE0NClRvOiBSdXNzIEhvdXNsZXk7IFN0ZXZlIEtl bnQNCg0KQ2M6IHRyYW5zQGlldGYub3JnPG1haWx0bzp0cmFuc0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbVHJhbnNdIEdvYWxzIGFuZCBnZW5lcmljIG1pcy1pc3N1YW5jZSBmZ3JhbWV3b3JrDQoN ClJ1c3MsIGNvbW1lbnRzIGlubGluZS4NCg0KLVJpY2sNCg0KRnJvbTogVHJhbnMgW21haWx0bzp0 cmFucy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5DQpTZW50OiBT YXR1cmRheSwgT2N0b2JlciAyNSwgMjAxNCAxMDowMSBBTQ0KVG86IFJpY2sgQW5kcmV3czsgU3Rl dmUgS2VudA0KQ2M6IHRyYW5zQGlldGYub3JnPG1haWx0bzp0cmFuc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbVHJhbnNdIEdvYWxzIGFuZCBnZW5lcmljIG1pcy1pc3N1YW5jZSBmZ3JhbWV3b3Jr DQoNClN0ZXZlIGFuZCBSaWNrOg0KDQoNCjEuIENlcnRpZmljYXRlIFRyYW5zcGFyZW5jeSBHb2Fs cyBhbmQgTWVjaGFuaXNtcw0KDQpUaGUgZ29hbHMgb2YgQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5 IChDVCkgYXJlIHRocmVlZm9sZDogZGV0ZWN0aW9uLCBkZXRlcnJlbmNlLCBhbmQgZW5hYmxpbmcg cmVtZWRpYXRpb24gb2YgbWlzLWlzc3VhbmNlIG9mIGNlcnRpZmljYXRlcy4gVGhlIGluaXRpYWwg Zm9jdXMgb2YgQ1QgaXMgdGhlIFdlYiBQS0kgY29udGV4dCwgKFRoZSBXZWIgUEtJIGNvbnRleHQg cmVmZXJzIHRvIHRoZSB1c2Ugb2YgYSBzZXQgb2YgQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllcyAo Q0FzKSB0aGF0IGlzc3VlIFguNTA5IGNlcnRpZmljYXRlcyB0byB3ZWIgc2VydmVycyB0byBlbmFi bGUgVExTLXByb3RlY3RlZCBhY2Nlc3MgYnkgY2xpZW50cyBbY2l0ZSBXUEtPUFM/XS4pIEluIHRo ZSBmdXR1cmUsIGl0IGlzIGFudGljaXBhdGVkIHRoYXQgYWRkaXRpb24gKmFkZGl0aW9uYWwqb3Bl cmF0aW9uYWwgY29udGV4dHMgbWF5IGJlIHN1cHBvcnRlZC4gQXMgYSByZXN1bHQsIG1pcy1pc3N1 YW5jZSBpcyBkZWZpbmVkIGluIGFuIGZhc2hpb24gdGhhdCBhY2NvbW1vZGF0ZXMgYSByYW5nZSBv ZiB0eXBlcyBvZiBjZXJ0aWZpY2F0ZXMgdXNlZCBpbiBhIHJhbmdlIG9mIGNvbnRleHRzLg0KDQpD VCBzdXBwb3J0cyBkZXRlY3Rpb24gb2YgbWlzLWlzc3VhbmNlIHVzaW5nIGxvZ3Mgb2YgY2VydGlm aWNhdGVzLCBwb3B1bGF0ZWQgYnkgdGhlIENBcyB0aGF0IGlzc3VlIHRoZW0gb3IgYnkgdGhlIFN1 YmplY3RzIG9mIGNlcnRpZmljYXRlcy4gTW9uaXRvcnMgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIFgp IGFyZSB0aGUgcHJpbWFyeSBlbGVtZW50cyBvZiB0aGUgQ1Qgc3lzdGVtIHRoYXQgY2hlY2sgY2Vy dGlmaWNhdGVzIGZvciBzeW50YWN0aWMgYW5kIHNlbWFudGljIG1pcy1pc3N1YW5jZSwgb24gYmVo YWxmIG9mIFN1YmplY3RzLiBBIE1vbml0b3IgbWF5IGJlIG9wZXJhdGVkIGJ5IGEgdGhpcmQgcGFy dHkgb24gYmVoYWxmIG9mIFN1YmplY3RzLCBvciBtYXkgYmUgb3BlcmF0ZWQgYnkgYSBTdWJqZWN0 IG9uIGl0cyBvd24gYmVoYWxmLiAoVGhlIGxhdHRlciBpcyByZWZlcnJlZCB0byBhcyDigJxzZWxm LW1vbml0b3JpbmfigJ0uKSBMb2dzIG1heSBvcHRpb25hbGx5IHBlcmZvcm0gc3ludGFjdGljIGNo ZWNrcyBmb3Igc29tZSBjbGFzc2VzIG9mIGNlcnRpZmljYXRlcywgYnV0IGEgbG9nIGlzIG5vdCBy ZXF1aXJlZCB0byBvZmZlciBjZXJ0aWZpY2F0ZSBjaGVja2luZy4NClRoZSBmaXJzdCBzZW50ZW5j ZSBuZWVkcyB0byBiZSBtb3JlIGJyb2FkLCBzaW5jZSBhbnlvbmUgY2FuIHNlbmQgYSBjZXJ0IHRv IGEgbG9nLiBCdXQgaXTigJlzIG1vc3QgbGlrZWx5IHRvIGJlIHRoZSBDQXMgb3IgdGhlIFN1Ympl Y3RzLCBzbyBJIHdvdWxkIHN1Z2dlc3Qg4oCcQ1Qgc3VwcG9ydHMgZGV0ZWN0aW9uIG9mIG1pcy1p c3N1YW5jZSB1c2luZyBsb2dzIG9mIGNlcnRpZmljYXRlcywgcG9wdWxhdGVkIGJ5IHRoZSBDQXMg dGhhdCBpc3N1ZSB0aGVtLCBieSB0aGUgU3ViamVjdHMgb2YgY2VydGlmaWNhdGVzLCBvciBieSBh bnlvbmUgd2l0aCBrbm93bGVkZ2Ugb2YgdGhlIGVudGlyZSBjZXJ0aWZpY2F0ZSBjaGFpbi7igJ0u DQoNCkNhbid0IGFueW9uZSBidWlsZCB0aGUgY2VydGlmaWNhdGUgY2hhaW4/ICBTaW5jZSB0aGUg bG9ncyBhcmUgcG9zdGluZyB0aGUgc3VwcG9ydGVkIHRydXN0IGFuY2hvcnMsIGFueW9uZSBjYW4g YnVpbGQgYSBjaGFpbiBmb3IgdGhlIGVuZCBlbnRpdHkgY2VydGlmaWNhdGUuDQoNCltSaWNrXSBJ biBtb3N0IGNhc2VzLCB5ZXMuIElmIHNvbWVvbmUgaGFzIGFjY2VzcyB0byB0aGUgc2VydmVyIGNv bmZpZ3VyZWQgd2l0aCB0aGF0IGNlcnRpZmljYXRlLCB0aGV5IGNhbiBkbyBhIFRMUyBoYW5kc2hh a2UgYW5kIGdldCB0aGUgY2hhaW4gaW4gbmVhcmx5IGFsbCBjYXNlcy4gV2Ugc2VlIHNvbWUgd2Vi IHNlcnZlcnMgdGhhdCBhcmUgbWlzc2luZyB0aGUgaW50ZXJtZWRpYXRlIENBIGNlcnQsIGFuZCBz b21lIGJyb3dzZXJzIChJRSwgZm9yIGV4YW1wbGUpIHdpbGwgZm9sbG93IHRoZSBBSUEgZXh0ZW5z aW9uIChpZiBpdOKAmXMgaW4gdGhlIGNlcnQpIGFuZCBmZXRjaCB0aGUgaW50ZXJtZWRpYXRlLiBB bnkgY2xpZW50IGNhbiBkbyB0aGF0IHRvby4gQnV0IGlmIHRoZSBDQSBkaWRu4oCZdCBwdXQgYW4g QUlBIGV4dGVuc2lvbiBpbiB0aGUgY2VydCBhbmQgeW91IGNhbuKAmXQgZmluZCBhIHNlcnZlciB3 aXRoIHRoYXQgY2VydCwgaXQgbWlnaHQgbm90IGJlIHBvc3NpYmxlIHRvIGZpbmQgdGhlIGludGVy bWVkaWF0ZSBDQSBjZXJ0LiBBbmQgd2l0aG91dCB0aGUgaW50ZXJtZWRpYXRlIChvciBpbnRlcm1l ZGlhdGVzISkgdGhlIGxvZyB3b27igJl0IGFjY2VwdCBpdC4NCg0KVG8gZW5hYmxlIE1vbml0b3Jz IChhbmQsIG9wdGlvbmFsbHksIGxvZ3MpIHRvIHBlcmZvcm0gYW4gYXBwcm9wcmlhdGUgc2V0IG9m IGNoZWNrcywgdGhlIChwcmUtKSBhIENDSUQgTVVTVCBiZSBwcm92aWRlZCB0byBhIGxvZyB3aGVu IGEgY2VydGlmaWNhdGUgaXMgc3VibWl0dGVkIGJ5IGEgQ0Egb3IgU3ViamVjdC4gVGhpcyBDQ0lE IE1VU1QgYXBwZWFyIGluIHRoZSBsb2cgZW50cnkgYW5kIGluIHRoZSBTQ1QgZ2VuZXJhdGVkIGJ5 IHRoZSBsb2cuIEJ5IHByb3ZpZGluZyB0aGUgQ0NJRCBpbiBsb2dzIGFuZCBTQ1RzLCBib3RoIE1v bml0b3JzIGFuZCBjbGllbnRzIGFyZSBlbXBvd2VyZWQgdG8gcGVyZm9ybSBhcHBsaWNhYmxlIGNo ZWNrcyBiYXNlZCBvbiB0aGUgY2VydGlmaWNhdGUgY2xhc3MgYXNzZXJ0ZWQgYnkgdGhlIENBIG9y IFN1YmplY3QuDQpIbW3igKYgU2luY2UgYW55b25lIGNhbiBzZW5kIGEgY2VydCB0byBhIGxvZywg dGhlIGZpcnN0IHNlbnRlbmNlIG11c3QgcmVmbGVjdCB0aGF0LiBCdXQgdGhhdCBtYWtlcyBtZSB3 b25kZXIgd2hhdCBzaG91bGQgaGFwcGVuIGlmIHRoZSDigJxSZXBvcnRlcuKAnSAoSSBkb27igJl0 IHdhbnQgdG8gaW50cm9kdWNlIGEgbmV3IHJvbGUpIHNlbmRzIHRoZSB3cm9uZyBDQ0lEPyAoQnkg 4oCcd3JvbmfigJ0gSSBtZWFuIGl04oCZcyBhIHZhbGlkIENDSUQsIGJ1dCBpdOKAmXMgbm90IHRo ZSBvbmUgdGhhdCB0aGUgQ0Egd291bGQgYXNzb2NpYXRlIHdpdGggdGhlIGNlcnQuKSBPciBzZW5k cyB0aGUgY2VydCBtdWx0aXBsZSB0aW1lcyB3aXRoIGRpZmZlcmVudCBDQ0lEcz8gSSBndWVzcyBN b25pdG9ycyB3b3VsZCBoYXZlIHRvIGV4cGVjdCBtdWx0aXBsZSBlbnRyaWVzIGZvciBhIGdpdmVu IGNlcnRpZmljYXRlIGluIGEgZ2l2ZW4gbG9nLCB3aXRoIGRpZmZlcmVudCBDQ0lEcy4gSeKAmW0g bm90IHN1cmUgaWYgNjk2Mi1iaXMgaW1wb3NlcyBhbnkgdW5pcXVlbmVzcyBjb25zdHJhaW50IHRo YXQgdGhpcyBtaWdodCB2aW9sYXRlLg0KDQpBbHRlcm5hdGl2ZWx5LCBhIGxvZyBjb3VsZCBjaGVj ayB0byBzZWUgaWYgdGhlIHJlcG9ydGVkIGNlcnRpZmljYXRlIGlzIGFscmVhZHkgcHJlc2VudCwg YW5kIGlmIHNvLCByZXR1cm4gdGhlIG9sZGVyIGVudHJ5IHRvIHRoZSBwYXJ0eSB0aGF0IHJlcG9y dHMgdGhlIGNlcnRpZmljYXRlLiAgSSBzZWVtIHRvIHJlY2FsbCByZWFkaW5nIHRoaXMgaWRlYSBh dCBzb21lIHBvaW50LCBidXkgSSBhZG1pdCBJIGRpZCBub3QgbG9vayBpbnRvIHRoZSBjdXJyZW50 IEktRCB0byBzZWUgaWYgdGhhdCB3YXMgd2hlcmUgaSByZWFkIGl0Lg0KW1JpY2tdIFJGQyA2OTYy IGFuZCBiaXMtMDQgc2F5IOKAnElmIHRoZSBsb2cgaGFzIHByZXZpb3VzbHkgc2VlbiB0aGUgY2Vy dGlmaWNhdGUsIGl0IE1BWSByZXR1cm4gdGhlIHNhbWUgU0NUIGFzIGl0IHJldHVybmVkIGJlZm9y ZS7igJ0gQnV0IHRoaXMgd291bGQgaGF2ZSB0byBiZSBleHBhbmRlZCB0byBzYXkg4oCcSWYgdGhl IGxvZyBoYXMgcHJldmlvdXNseSBzZWVuIHRoZSBjZXJ0aWZpY2F0ZSBhbmQgQ0NJRCwgaXQgTUFZ IHJldHVybiB0aGUgc2FtZSBTQ1QgYXMgaXQgcmV0dXJuZWQgYmVmb3JlLuKAnSBJdOKAmXMgYSBi aXQgbW9yZSBjb21wbGV4LCBzaW5jZSB0aGUgbG9nIHNlcnZlciBtYXkgbm90IHN1cHBvcnQgdGhl IENDSUQgb3IgYW55IGNoZWNraW5nLCBpbiB3aGljaCBjYXNlcyBpdCB3b3VsZCBhbHdheXMgbG9n IHRoZSBlbnRyeSB3aXRoIENDSUQgPTEgdGhhdCBpbmRpY2F0ZXMg4oCcVGhpcyBsb2cgZG9lcyBu b3QgcGVyZm9ybSBzeW50YXggY2hlY2tz4oCdLCBvciBDQ0lEPTIgdGhhdCBpbmRpY2F0ZXMg4oCc VGhpcyBsb2cgZG9lcyBub3Qgc3VwcG9ydCBzeW50YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQg Q0NJROKAnS4NCg0KDQpBIGxvZyBNVVNUIGdlbmVyYXRlIGEgU3ludGF4IFZlcmlmaWNhdGlvbiBW YWx1ZSAoU1ZWKSBmb3IgdGhlIGNlcnRpZmljYXRlLCBhbmQgaW5jbHVkZSB0aGUgU1ZWIGluIHRo ZSBsb2cgZW50cnkgYW5kIGluIHRoZSBTQ1QuDQpUaGUgTFZWICpTVlYqIGlzICphKiB2YWx1ZSBz cGVjaWZpZWQgYnkgdGhpcyBkb2N1bWVudCAoc2VlIFNlY3Rpb24gWikgdGhhdCBpbmRpY2F0ZXMg d2hldGhlciBvciBub3QgdGhlIGxvZyBwZXJmb3JtZWQgYXBwbGljYWJsZSBzeW50YWN0aWMgY2hl Y2tzLCBhbmQgd2hldGhlciB0aGUgKHByZS0pIGNlcnRpZmljYXRlIHBhc3NlZCBvZiAqb3IqIGZh aWxlZCB0aGUgY2hlY2tzLiBBbHRob3VnaCBpdCBpcyBhbnRpY2lwYXRlZCB0aGF0IG5ldyBjZXJ0 aWZpY2F0ZSBjbGFzc2VzIHdpbGwgYXJpc2Ugb3ZlciB0aW1lLCB0aGUgc2V0IG9mIGxvZyBhY3Rp b25zIHdpdGggcmVzcGVjdCB0byBzeW50YXggY2hlY2tpbmcgYXBwZWFycyB0byBiZSB3ZWxsLWRl ZmluZWQgYW5kIHRodXMgbmVlZCBub3QgYmUgcmVwcmVzZW50ZWQgaW4gYW4gSUFOQSByZWdpc3Ry eS4gRWFjaCBTQ1QgaXNzdWVkIGJ5IGEgbG9nIE1VU1QgaW5jbHVkZSBhbiBTVlYuDQoNCg0KVmFs dWUgSW50ZXJwcmV0YXRpb24NCjAgICAgICAgICAgICAgICAgIFRoZSBDQ0lEIHZhbHVlIHdhcyAw LCBzbyBub3QgKm5vKiBjaGVja3Mgd2VyZSBwZXJmb3JtZWQNCjEgICAgICAgICAgICAgICAgIFRo aXMgbG9nIGRvZXMgbm90IHBlcmZvcm0gc3ludGF4IGNoZWNrcw0KMiAgICAgICAgICAgICAgICAg VGhpcyBsb2cgZG9lcyBub3Qgc3VwcG9ydCBzeW50YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQg Q0NJRA0KMyAgICAgICAgICAgICAgICAgVGhpcyBsb2cgcGVyZm9ybWVkIHRoZSBzeW50YXggY2hl Y2tzIGZvciB0aGUgYXNzZXJ0ZWQgQ0NJRCwgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBwYXNzZWQNCjQg ICAgICAgICAgICAgICAgIFRoaXMgbG9nIHBlcmZvcm1lZCB0aGUgc3ludGF4IGNoZWNrcyBmb3Ig dGhlIGFzc2VydGVkIENDSUQsIGFuZCB0aGUgY2VydGlmaWNhdGUgZmFpbGVkDQoNCk5vIG90aGVy IFNWViB2YWx1ZXMgYXJlIGRlZmluZWQgYnkgdGhpcyBSRkMuDQoNCklmIHRoZSBsb2cgcGVyZm9y bXMgc29tZSB2YWxpZGF0aW9uIGNoZWNrcywgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSByZWx5 aW5nIHBhcnR5IGNhbiBsZXZlcmFnZSB0aGUgd29yayBhbHJlYWR5IGRvbmUgYnkgdGhlIGxvZz8g IElmIHNvLCBpdCBwdXRzIHRoZSBsb2cgY2hlY2tpbmcgYXQgYSBkaWZmZXJlbnQgcGxhY2UgaW4g dGhlIGNlcnRpZmljYXRlIHZhbGlkYXRpb24gdGhhbiBJIHdhcyBpbWFnaW5pbmcuDQpbUmlja10g WWVzLCBhIHJlbHlpbmcgcGFydHkgY291bGQgbGV2ZXJhZ2UgdGhlIHdvcmsgYWxyZWFkeSBkb25l IGJ5IHRoZSBsb2cgc2VydmVyLCBpZiB0aGUgUlAgdHJ1c3RlZCBpdC4gR29vZ2xlIHdvdWxkIHBy b2JhYmx5IGFkdmlzZSBhZ2FpbnN0IHRoaXMsIHNpbmNlIHRoZXkgaGF2ZSBiZWVuIHByZXR0eSBj b25zaXN0ZW50IGluIHNheWluZyB0aGF0IENUIGRvZXNu4oCZdCByZXF1aXJlIHlvdSB0byB0cnVz dCBhbnlvbmUgaW5jbHVkaW5nIHRoZSBsb2cgc2VydmVyLg0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVHJhbnMgbWFpbGluZyBsaXN0DQpU cmFuc0BpZXRmLm9yZzxtYWlsdG86VHJhbnNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW5zDQoNCg0K --_000_4262AC0DB9856847A2D00EF817E81139244489scygexch10cygnaco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNv bWUgb2YgdGhlIG90aGVyIHVzYWdlcyBvZiB0aGUgbG9nIGNoZWNrcyBhcmUgdGhhdCBzdWJqZWN0 cyBhbmQgQ0FzIGNhbiBhbHNvIHNlZSB0aGlzIGFuZCB0YWtlIGNvcnJlY3RpdmUgYWN0aW9ucy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFsc28sIEkgYW0gbm90 IHNheWluZyByZWx5aW5nIHBhcnRpZXMgZG8gbm90IHVzZSB0aGUgY2hlY2tzIG1hZGUgYnkgdGhl IGxvZ3MuIGl0IGlzIGp1c3QgdGhhdCB0aGUgcmVseWluZyBwYXJ0aWVzIG1heSBuZWVkIHRvIHBl cmZvcm0gdGhlaXIgb3duIGNoZWNrcyBhbHNvIGR1ZQ0KIHRvIGRpZmZlcmVuY2VzIGluIGxvZ3Mg cGVyY2VwdGlvbiBvZiBwYXRoIHZhbGlkYXRpb24gc3RhdGUgYW5kIHJlbHlpbmcgcGFydHnigJlz LiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBFcmFuIE1lc3NlcmkgW21haWx0bzplcmFubUBnb29nbGUuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAyOSwgMjAxNCA3OjMyIEFNPGJyPg0K PGI+VG86PC9iPiBTYW50b3NoIENob2toYW5pPGJyPg0KPGI+Q2M6PC9iPiBSaWNrIEFuZHJld3M7 IFJ1c3MgSG91c2xleTsgU3RldmUgS2VudDsgdHJhbnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZncmFtZXdv cms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGF0IGNhc2UsIGhv dyBhYm91dCBpbmNsdWRpbmcgdGhlIENDSUQgYW5kIHRoZSByZXN1bHRzIG9mIHRoZSBjaGVja3Mg dGhlIGxvZyBwZXJmb3JtZWQgaW4gdGhlIGdldC1zdGggcmVzcG9uc2UsIGJ1dCBub3QgaW4gdGhl IFNDVCBpdHNlbGY/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgbG9nIGNvdWxkIHN0aWxsIHNpZ24gdGhlIGNvbXBsZXRlIGdldC1zdGggcmVwbHkgc28g c3VibWl0dGVycyBnZXQgYSBjb25maXJtYXRpb24gaXQgaXMgaW5kZWVkIHRoZSBsb2cgd2hpY2gg cGVyZm9ybWVkIHRoZSBjaGVja3MsIGFuZCBUTFMgY2xpZW50cyB3aWxsIG5vdCBiZSBidXJkZW5l ZCB3aXRoIGhhbmRsaW5nIGFub3RoZXIgZmllbGQgaW4gdGhlIFNDVCB0aGVyZSdzIG5vIGltbWVk aWF0ZSB1c2UgZm9yLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXMgSSBzYWlkLCBJIHNlZSB0aGUgdmFsdWUgaW4gZ2V0dGluZyBhbiAmcXVvdDtpbmRlcGVu ZGVudCBvcGluaW9uJnF1b3Q7IG9uIHRoZSB2YWxpZGl0eSBvZiBhIGNoYWluIHN1Ym1pdHRlZCB0 byB0aGUgbG9nIChib3RoIGluIHN5bnRhY3RpYyBhbmQgc2VtYW50aWMgY29tcGxpYW5jZSBwZXJz cGVjdGl2ZXMpIGFuZCBpcyBtdWNoIG1vcmUgdXNlZnVsIHRoYW4gdGhlIGN1cnJlbnQgZXJyb3Ig aGFuZGxpbmcgYXBwcm9hY2ggKHdoZXJlDQogdGhlIGxvZyByZXR1cm5zIGEgdmFndWUgZXJyb3Ip LiBJIGp1c3QgbGlrZSB0byBleGNsdWRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSBiZWluZyBlbWJl ZGRlZCBpbiB0aGUgU0NUIGlmIGl0J3Mgbm90IHVzZWZ1bCBmb3IgVExTIGNsaWVudHMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBPY3QgMjgsIDIwMTQgYXQgNzoyNyBQTSwgU2FudG9zaCBDaG9raGFuaSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNjaG9raGFuaUBjeWduYWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5zY2hv a2hhbmlAY3lnbmFjb20uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5FcmFuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlNlZSBpbi1saW5lIGJlbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJhbiBNZXNzZXJp IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVyYW5tQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5lcmFubUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3Rv YmVyIDI4LCAyMDE0IDEyOjQ2IFBNPGJyPg0KPGI+VG86PC9iPiBTYW50b3NoIENob2toYW5pPGJy Pg0KPGI+Q2M6PC9iPiBSaWNrIEFuZHJld3M7IFJ1c3MgSG91c2xleTsgU3RldmUgS2VudDsgPGEg aHJlZj0ibWFpbHRvOnRyYW5zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0cmFuc0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVy aWMgbWlzLWlzc3VhbmNlIGZncmFtZXdvcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T3ZlcmFsbCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBzZWVtcyByZWFzb25h YmxlLiBDYW4geW91IGhlbHAgbWUgdW5kZXJzdGFuZCB0aGUgYmVuZWZpdHMgZnJvbSB0aGUgVExT IGNsaWVudCdzIHBlcnNwZWN0aXZlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1NhbnRvc2hdIFRoZSBw cmltYXJ5IGJlbmVmaXQgd291bGQgaGF2ZSBjb21lIGlmIHRoZSBsb2cgaGFkIGVuZm9yY2VkIGFu ZCBub3QgcmVnaXN0ZXJlZCBhIG1hbC1mb3JtZWQNCiBjZXJ0aWZpY2F0ZS4mbmJzcDsgTG9nIGFj Y2VwdGFuY2Ugb2YgY2VydGlmaWNhdGUgc2VlbXMgdG8gd2hhdCB0aGUgV0cgcHJlZmVycy4mbmJz cDsgSW4gdGhhdCBjYXNlLCBiZW5lZml0cyB0byB0aGUgY2xpZW50IGFyZSByZWR1Y2VkLiZuYnNw Ow0KPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JSVVDLCB0aGUgbG9nIHdpbGwgbmV2 ZXIgcmVmdXNlIHRvIGluY2x1ZGUgYSBjZXJ0aWZpY2F0ZSwgaXQgd2lsbCBtZXJlbHkgaW5kaWNh dGUgaXQgZmFpbGVkIHN5bnRhY3RpYyBjaGVja3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IFRMUyBj bGllbnRzIHdpbGwgcmVqZWN0IGFuIG90aGVyd2lzZS12YWxpZCBjZXJ0aWZpY2F0ZSBjaGFpbiB3 aGljaCBoYXMgYSZuYnNwO0NDSUQgdGhhdCBtYXRjaGVzIHRoZSBUTFMgY2xpZW50J3MgZGVzaXJl ZCB1c2Ugb2YgdGhlIGNlcnRpZmljYXRlLCBiZWNhdXNlIHRoZSBsb2cNCiBpbmRpY2F0ZWQgaXQg ZmFpbGVkIHN5bnRhY3RpYyBjaGVja3M/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bU2FudG9zaF0gVGhh dCBjb3VsZCBiZSBvbmUgdGhpbmcuJm5ic3A7IFdoYXQgSSB3YXMgc2F5aW5nIGluIHRoZSB0aHJl YWQgaXMgdGhhdCBldmVuIGlmIHRoZSBMb2cgc2FpZA0KIHRoYXQgdGhlIGNlcnRpZmljYXRlIHBh c3NlZCB0aGUgY2hlY2tzLCBjbGllbnQgbXVzdCBkbyBpdHMgb3duIHBhdGggdmFsaWRhdGlvbiB1 bmxlc3MgdGhlIGNsaWVudCBhbmQgbG9nIGFyZSB1c2luZyB0aGUgc2FtZSBjaGFpbiBhbmQgc2Ft ZSA1MjgwIHBhdGggdmFsaWRhdGlvbiBpbml0aWFsaXphdGlvbiB2YXJpYWJsZXMuPC9zcGFuPjwv aT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPk9uZSBhZHZhbnRhZ2Ugb2YgbG9ncyBkb2luZyBjaGVja2luZyBhbmQgcmVqZWN0 aW5nIHRoZSBjZXJ0aWZpY2F0ZXMgaXMgdGhhdCB0aGUgaHVtYW4gdXNlciB3aWxsDQogbm90IGdv IHRocm91Z2ggdGhlIGVycm9yLXByb25lIGRlY2lzaW9uIG1ha2luZyBhYm91dCB0aGUgc2VjdXJp dHkgcmFtaWZpY2F0aW9uIG9mIGZhaWxlZCBwYXRoIHZhbGlkYXRpb24uPC9zcGFuPjwvaT48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JdCdzIG5vdCBhIGJhZCB0aGluZywgaXQgZG9lcyBwbGFjZSBhZGRpdGlvbmFsIGJ1cmRlbiBv biBsb2dzIHRob3VnaC4gTW9uaXRvcnMgd2lsbCBoYXZlIHRvIHZlcmlmeSB0aGUgbG9nJ3MgaG9u ZXN0IGJlaGF2aW91ciBvbiB0aGlzIGFzcGVjdCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG90aGVyIHF1ZXN0aW9u IGlzIC0gYXJlbid0IGNlcnRpZmljYXRlIGNsYXNzZXMgZGlmZmVyZW50IGVub3VnaCB0byBtZXJp dCBydW5uaW5nIGRpZmZlcmVudCBsb2dzLCB3aGVyZSB0aGUgbG9nJ3MgaWRlbnRpdHkgKG9yIHNv bWUgb3RoZXIgbWV0YWRhdGEpIGluZGljYXRlcyB3aGljaCBDQ0lEIGl0J3MNCiBnb29kIGZvcj88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdt IGEgYml0IHdlYXJ5IG9mIHNwZWNpZnlpbmcgYSBiZWhhdmlvdXIgZm9yIHRoZSBnZW5lcmFsIGNh c2Ugd2hlcmUgSSBkb24ndCBoYXZlIGNvbmNyZXRlIGV4YW1wbGVzIGZvciBtb3JlIHRoYW4gb25l IHBhcnRpY3VsYXIgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltTYW50b3NoXSBUbyBteSBrbm93 bGVkZ2UsIGxvdCBvZiBwYXRoIGNoZWNrcyBhcmUgdGhlIHNhbWUuJm5ic3A7IERpZmZlcmVudCBj bGFzc2VzIG9mIGNlcnRpZmljYXRlcw0KIG1heSB3YXJyYW50IGNoZWNraW5nIEtVLCBFS1UgYW5k IGV4dHJhY3RpbmcgYW5kIG1hdGNoaW5nIG5hbWVzIGZyb20gZGlmZmVyZW50IGZpZWxkcyAoc2F5 IFN1YmplY3QgRE4gb3IgU0FOKS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVl LCBPY3QgMjgsIDIwMTQgYXQgMjowOSBBTSwgU2FudG9zaCBDaG9raGFuaSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNjaG9raGFuaUBjeWduYWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5zY2hva2hhbmlA Y3lnbmFjb20uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVseWluZyBw YXJ0aWVzIHJlbHlpbmcgb24gdGhlIGNoZWNrcyBtYWRlIGJ5IGxvZyBzZXJ2ZXIgbWF5IGJlIHBy b2JsZW1hdGljIGlmIGJvdGggZG8gbm90IGhhdmUgdGhlDQogc2FtZSB0cnVzdCBzdG9yZSBpZiB0 aGUgaW5pdGlhbGl6YXRpb24gdmFyaWFibGVzIGFyZSBkaWZmZXJlbnQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgcHJpbWFyeSBtb3RpdmF0aW9uIGlu IGxvZyBkb2luZyBjaGVja3MgaXMgbmlwIHRoZSBwcm9ibGVtIGluIHRoZSBidWQgYW5kIHJlZHVj ZSB0aGUgcHJvYmFiaWxpdHkNCiBvZiByZWx5aW5nIHBhcnRpZXMgaGF2aW5nIHRvIGRlY2lkZSBv biBleGNlcHRpb25zLiZuYnNwOyBUaGUgcmVseWluZyBwYXJ0aWVzIHN0aWxsIHNob3VsZCB2YWxp ZGF0ZSB0aGUgY2VydGlmaWNhdGlvbiBwYXRoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IFRyYW5zIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRyYW5zLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFucy1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmljayBBbmRyZXdzPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgT2N0b2JlciAyNywgMjAxNCA2OjMzIFBNPGJyPg0KPGI+VG86PC9iPiBSdXNzIEhvdXNs ZXk7IFN0ZXZlIEtlbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbnNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFuc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZncmFt ZXdvcms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UnVz cywgY29tbWVudHMgaW5saW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPi1SaWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBUcmFucyBbPGEgaHJlZj0ibWFpbHRvOnRyYW5zLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86dHJhbnMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJ1c3MgSG91c2xleTxicj4NCjxiPlNlbnQ6PC9i PiBTYXR1cmRheSwgT2N0b2JlciAyNSwgMjAxNCAxMDowMSBBTTxicj4NCjxiPlRvOjwvYj4gUmlj ayBBbmRyZXdzOyBTdGV2ZSBLZW50PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJh bnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFuc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtUcmFuc10gR29hbHMgYW5kIGdlbmVyaWMgbWlzLWlzc3VhbmNlIGZn cmFtZXdvcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClN0 ZXZlIGFuZCBSaWNrOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFy Z2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+MS4gQ2VydGlmaWNh dGUgVHJhbnNwYXJlbmN5IEdvYWxzIGFuZCBNZWNoYW5pc21zPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy aWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6Ymxh Y2siPlRoZSBnb2FscyBvZiBDZXJ0aWZpY2F0ZSBUcmFuc3BhcmVuY3kgKENUKSBhcmUgdGhyZWVm b2xkOiBkZXRlY3Rpb24sIGRldGVycmVuY2UsIGFuZCBlbmFibGluZyByZW1lZGlhdGlvbiBvZiBt aXMtaXNzdWFuY2Ugb2YgY2VydGlmaWNhdGVzLiBUaGUgaW5pdGlhbCBmb2N1cyBvZiBDVCBpcyB0 aGUgV2ViIFBLSSBjb250ZXh0LCAoVGhlIFdlYiBQS0kgY29udGV4dCByZWZlcnMNCiB0byB0aGUg dXNlIG9mIGEgc2V0IG9mIENlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMgKENBcykgdGhhdCBpc3N1 ZSBYLjUwOSBjZXJ0aWZpY2F0ZXMgdG8gd2ViIHNlcnZlcnMgdG8gZW5hYmxlIFRMUy1wcm90ZWN0 ZWQgYWNjZXNzIGJ5IGNsaWVudHMgW2NpdGUgV1BLT1BTP10uKSBJbiB0aGUgZnV0dXJlLCBpdCBp cyBhbnRpY2lwYXRlZCB0aGF0Jm5ic3A7PHM+YWRkaXRpb248L3M+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiMxRjQ5N0QiPio8Yj5hZGRpdGlvbmFs PC9iPio8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si Pm9wZXJhdGlvbmFsDQogY29udGV4dHMgbWF5IGJlIHN1cHBvcnRlZC4gQXMgYSByZXN1bHQsIG1p cy1pc3N1YW5jZSBpcyBkZWZpbmVkIGluIGFuIGZhc2hpb24gdGhhdCBhY2NvbW1vZGF0ZXMgYSBy YW5nZSBvZiB0eXBlcyBvZiBjZXJ0aWZpY2F0ZXMgdXNlZCBpbiBhIHJhbmdlIG9mIGNvbnRleHRz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5DVCBzdXBwb3J0cyBkZXRlY3Rpb24gb2YgbWlzLWlz c3VhbmNlIHVzaW5nIGxvZ3Mgb2YgY2VydGlmaWNhdGVzLCBwb3B1bGF0ZWQgYnkgdGhlIENBcyB0 aGF0IGlzc3VlIHRoZW0gb3IgYnkgdGhlIFN1YmplY3RzIG9mIGNlcnRpZmljYXRlcy4gTW9uaXRv cnMgKGRlc2NyaWJlZCBpbiBTZWN0aW9uJm5ic3A7PGI+WDwvYj4pIGFyZSB0aGUgcHJpbWFyeSBl bGVtZW50cyBvZiB0aGUNCiBDVCBzeXN0ZW0gdGhhdCBjaGVjayBjZXJ0aWZpY2F0ZXMgZm9yIHN5 bnRhY3RpYyBhbmQgc2VtYW50aWMgbWlzLWlzc3VhbmNlLCBvbiBiZWhhbGYgb2YgU3ViamVjdHMu IEEgTW9uaXRvciBtYXkgYmUgb3BlcmF0ZWQgYnkgYSB0aGlyZCBwYXJ0eSBvbiBiZWhhbGYgb2Yg U3ViamVjdHMsIG9yIG1heSBiZSBvcGVyYXRlZCBieSBhIFN1YmplY3Qgb24gaXRzIG93biBiZWhh bGYuIChUaGUgbGF0dGVyIGlzIHJlZmVycmVkIHRvIGFzIOKAnHNlbGYtbW9uaXRvcmluZ+KAnS4p DQogTG9ncyBtYXkgb3B0aW9uYWxseSBwZXJmb3JtIHN5bnRhY3RpYyBjaGVja3MgZm9yIHNvbWUg Y2xhc3NlcyBvZiBjZXJ0aWZpY2F0ZXMsIGJ1dCBhIGxvZyBpcyBub3QgcmVxdWlyZWQgdG8gb2Zm ZXIgY2VydGlmaWNhdGUgY2hlY2tpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBmaXJzdCBzZW50ZW5jZSBuZWVkcyB0byBiZSBtb3Jl IGJyb2FkLCBzaW5jZSBhbnlvbmUgY2FuIHNlbmQgYSBjZXJ0IHRvIGEgbG9nLiBCdXQgaXTigJlz IG1vc3QgbGlrZWx5IHRvIGJlIHRoZSBDQXMgb3IgdGhlIFN1YmplY3RzLCBzbyBJIHdvdWxkIHN1 Z2dlc3Qg4oCcQ1Qgc3VwcG9ydHMgZGV0ZWN0aW9uIG9mDQogbWlzLWlzc3VhbmNlIHVzaW5nIGxv Z3Mgb2YgY2VydGlmaWNhdGVzLCBwb3B1bGF0ZWQgYnkgdGhlIENBcyB0aGF0IGlzc3VlIHRoZW0s IGJ5IHRoZSBTdWJqZWN0cyBvZiBjZXJ0aWZpY2F0ZXMsIG9yIGJ5IGFueW9uZSB3aXRoIGtub3ds ZWRnZSBvZiB0aGUgZW50aXJlIGNlcnRpZmljYXRlIGNoYWluLuKAnS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpDYW4ndCBhbnlvbmUgYnVpbGQgdGhlIGNl cnRpZmljYXRlIGNoYWluPyZuYnNwOyBTaW5jZSB0aGUgbG9ncyBhcmUgcG9zdGluZyB0aGUgc3Vw cG9ydGVkIHRydXN0IGFuY2hvcnMsIGFueW9uZSBjYW4gYnVpbGQgYSBjaGFpbiBmb3IgdGhlIGVu ZCBlbnRpdHkgY2VydGlmaWNhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5bUmlja10gSW4gbW9zdCBjYXNlcywgeWVzLiBJZiBzb21lb25lIGhhcyBh Y2Nlc3MgdG8gdGhlIHNlcnZlciBjb25maWd1cmVkIHdpdGggdGhhdCBjZXJ0aWZpY2F0ZSwgdGhl eSBjYW4NCiBkbyBhIFRMUyBoYW5kc2hha2UgYW5kIGdldCB0aGUgY2hhaW4gaW4gbmVhcmx5IGFs bCBjYXNlcy4gV2Ugc2VlIHNvbWUgd2ViIHNlcnZlcnMgdGhhdCBhcmUgbWlzc2luZyB0aGUgaW50 ZXJtZWRpYXRlIENBIGNlcnQsIGFuZCBzb21lIGJyb3dzZXJzIChJRSwgZm9yIGV4YW1wbGUpIHdp bGwgZm9sbG93IHRoZSBBSUEgZXh0ZW5zaW9uIChpZiBpdOKAmXMgaW4gdGhlIGNlcnQpIGFuZCBm ZXRjaCB0aGUgaW50ZXJtZWRpYXRlLiBBbnkgY2xpZW50IGNhbg0KIGRvIHRoYXQgdG9vLiBCdXQg aWYgdGhlIENBIGRpZG7igJl0IHB1dCBhbiBBSUEgZXh0ZW5zaW9uIGluIHRoZSBjZXJ0IGFuZCB5 b3UgY2Fu4oCZdCBmaW5kIGEgc2VydmVyIHdpdGggdGhhdCBjZXJ0LCBpdCBtaWdodCBub3QgYmUg cG9zc2libGUgdG8gZmluZCB0aGUgaW50ZXJtZWRpYXRlIENBIGNlcnQuIEFuZCB3aXRob3V0IHRo ZSBpbnRlcm1lZGlhdGUgKG9yIGludGVybWVkaWF0ZXMhKSB0aGUgbG9nIHdvbuKAmXQgYWNjZXB0 IGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPlRvIGVuYWJsZSBNb25pdG9ycyAoYW5kLCBvcHRp b25hbGx5LCBsb2dzKSB0byBwZXJmb3JtIGFuIGFwcHJvcHJpYXRlIHNldCBvZiBjaGVja3MsJm5i c3A7PHM+dGhlIChwcmUtKTwvcz4mbmJzcDthIENDSUQgTVVTVCBiZSBwcm92aWRlZCB0byBhIGxv ZyB3aGVuIGEgY2VydGlmaWNhdGUgaXMgc3VibWl0dGVkIGJ5IGEgQ0Egb3IgU3ViamVjdC4gVGhp cyBDQ0lEIE1VU1QgYXBwZWFyIGluDQogdGhlIGxvZyBlbnRyeSBhbmQgaW4gdGhlIFNDVCBnZW5l cmF0ZWQgYnkgdGhlIGxvZy4gQnkgcHJvdmlkaW5nIHRoZSBDQ0lEIGluIGxvZ3MgYW5kIFNDVHMs IGJvdGggTW9uaXRvcnMgYW5kIGNsaWVudHMgYXJlIGVtcG93ZXJlZCB0byBwZXJmb3JtIGFwcGxp Y2FibGUgY2hlY2tzIGJhc2VkIG9uIHRoZSBjZXJ0aWZpY2F0ZSBjbGFzcyBhc3NlcnRlZCBieSB0 aGUgQ0Egb3IgU3ViamVjdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SG1t4oCmIFNpbmNlIGFueW9uZSBjYW4gc2VuZCBhIGNlcnQgdG8gYSBs b2csIHRoZSBmaXJzdCBzZW50ZW5jZSBtdXN0IHJlZmxlY3QgdGhhdC4gQnV0IHRoYXQgbWFrZXMg bWUgd29uZGVyIHdoYXQgc2hvdWxkIGhhcHBlbiBpZiB0aGUg4oCcUmVwb3J0ZXLigJ0gKEkgZG9u 4oCZdCB3YW50IHRvIGludHJvZHVjZSBhIG5ldyByb2xlKQ0KIHNlbmRzIHRoZSB3cm9uZyBDQ0lE PyAoQnkg4oCcd3JvbmfigJ0gSSBtZWFuIGl04oCZcyBhIHZhbGlkIENDSUQsIGJ1dCBpdOKAmXMg bm90IHRoZSBvbmUgdGhhdCB0aGUgQ0Egd291bGQgYXNzb2NpYXRlIHdpdGggdGhlIGNlcnQuKSBP ciBzZW5kcyB0aGUgY2VydCBtdWx0aXBsZSB0aW1lcyB3aXRoIGRpZmZlcmVudCBDQ0lEcz8gSSBn dWVzcyBNb25pdG9ycyB3b3VsZCBoYXZlIHRvIGV4cGVjdCBtdWx0aXBsZSBlbnRyaWVzIGZvciBh IGdpdmVuIGNlcnRpZmljYXRlDQogaW4gYSBnaXZlbiBsb2csIHdpdGggZGlmZmVyZW50IENDSURz LiBJ4oCZbSBub3Qgc3VyZSBpZiA2OTYyLWJpcyBpbXBvc2VzIGFueSB1bmlxdWVuZXNzIGNvbnN0 cmFpbnQgdGhhdCB0aGlzIG1pZ2h0IHZpb2xhdGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkFsdGVybmF0aXZlbHksIGEgbG9nIGNvdWxk IGNoZWNrIHRvIHNlZSBpZiB0aGUgcmVwb3J0ZWQgY2VydGlmaWNhdGUgaXMgYWxyZWFkeSBwcmVz ZW50LCBhbmQgaWYgc28sIHJldHVybiB0aGUgb2xkZXIgZW50cnkgdG8gdGhlIHBhcnR5IHRoYXQg cmVwb3J0cyB0aGUgY2VydGlmaWNhdGUuJm5ic3A7IEkgc2VlbSB0byByZWNhbGwgcmVhZGluZyB0 aGlzIGlkZWEgYXQgc29tZSBwb2ludCwgYnV5IEkgYWRtaXQgSSBkaWQgbm90IGxvb2sgaW50byB0 aGUgY3VycmVudA0KIEktRCB0byBzZWUgaWYgdGhhdCB3YXMgd2hlcmUgaSByZWFkIGl0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+W1JpY2tdIFJGQyA2OTYyIGFuZCBiaXMtMDQgc2F5IOKAnElmIHRoZSBsb2cgaGFz IHByZXZpb3VzbHkgc2VlbiB0aGUgY2VydGlmaWNhdGUsIGl0IE1BWSByZXR1cm4gdGhlIHNhbWUN CiBTQ1QgYXMgaXQgcmV0dXJuZWQgYmVmb3JlLuKAnSBCdXQgdGhpcyB3b3VsZCBoYXZlIHRvIGJl IGV4cGFuZGVkIHRvIHNheSDigJxJZiB0aGUgbG9nIGhhcyBwcmV2aW91c2x5IHNlZW4gdGhlIGNl cnRpZmljYXRlDQo8Yj5hbmQgQ0NJRDwvYj4sIGl0IE1BWSByZXR1cm4gdGhlIHNhbWUgU0NUIGFz IGl0IHJldHVybmVkIGJlZm9yZS7igJ0gSXTigJlzIGEgYml0IG1vcmUgY29tcGxleCwgc2luY2Ug dGhlIGxvZyBzZXJ2ZXIgbWF5IG5vdCBzdXBwb3J0IHRoZSBDQ0lEIG9yIGFueSBjaGVja2luZywg aW4gd2hpY2ggY2FzZXMgaXQgd291bGQgYWx3YXlzIGxvZyB0aGUgZW50cnkgd2l0aCBDQ0lEID0x IHRoYXQgaW5kaWNhdGVzIOKAnFRoaXMgbG9nIGRvZXMgbm90IHBlcmZvcm0gc3ludGF4DQogY2hl Y2tz4oCdLCBvciBDQ0lEPTIgdGhhdCBpbmRpY2F0ZXMg4oCcVGhpcyBsb2cgZG9lcyBub3Qgc3Vw cG9ydCBzeW50YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQgQ0NJROKAnS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVp biI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPkEgbG9nIE1VU1QgZ2VuZXJhdGUgYSBTeW50YXgg VmVyaWZpY2F0aW9uIFZhbHVlIChTVlYpIGZvciB0aGUgY2VydGlmaWNhdGUsIGFuZCBpbmNsdWRl IHRoZSBTVlYgaW4gdGhlIGxvZyBlbnRyeSBhbmQgaW4gdGhlIFNDVC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXI7Y29sb3I6YmxhY2siPlRoZSZuYnNwOzxzPkxWVjwvcz48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7KjxiPlNWVjwvYj4q PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJz cDtpcyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjoj MUY0OTdEIj4qPGI+YTwvYj4qJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrIj52YWx1ZQ0KIHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50IChz ZWUgU2VjdGlvbiBaKSB0aGF0IGluZGljYXRlcyB3aGV0aGVyIG9yIG5vdCB0aGUgbG9nIHBlcmZv cm1lZCBhcHBsaWNhYmxlIHN5bnRhY3RpYyBjaGVja3MsIGFuZCB3aGV0aGVyIHRoZSAocHJlLSkg Y2VydGlmaWNhdGUgcGFzc2VkJm5ic3A7PHM+b2Y8L3M+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiMxRjQ5N0QiPio8Yj5vcjwvYj4qJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5mYWlsZWQN CiB0aGUgY2hlY2tzLiBBbHRob3VnaCBpdCBpcyBhbnRpY2lwYXRlZCB0aGF0IG5ldyBjZXJ0aWZp Y2F0ZSBjbGFzc2VzIHdpbGwgYXJpc2Ugb3ZlciB0aW1lLCB0aGUgc2V0IG9mIGxvZyBhY3Rpb25z IHdpdGggcmVzcGVjdCB0byBzeW50YXggY2hlY2tpbmcgYXBwZWFycyB0byBiZSB3ZWxsLWRlZmlu ZWQgYW5kIHRodXMgbmVlZCBub3QgYmUgcmVwcmVzZW50ZWQgaW4gYW4gSUFOQSByZWdpc3RyeS4g RWFjaCBTQ1QgaXNzdWVkIGJ5IGEgbG9nIE1VU1QNCiBpbmNsdWRlIGFuIFNWVi4gJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5WYWx1ZSBJbnRlcnByZXRh dGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MS41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjA8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpi bGFjayI+VGhlIENDSUQgdmFsdWUgd2FzIDAsIHNvJm5ic3A7PHM+bm90PC9zPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjojMUY0OTdEIj4qPGI+bm88 L2I+KiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpi bGFjayI+Y2hlY2tzDQogd2VyZSBwZXJmb3JtZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2Nv bG9yOmJsYWNrIj4xPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPlRoaXMgbG9nIGRvZXMgbm90IHBlcmZvcm0g c3ludGF4IGNoZWNrczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6MS41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjI8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+VGhpcyBsb2cgZG9lcyBub3Qgc3VwcG9ydCBzeW50YXggY2hlY2tzIGZv ciB0aGUgYXNzZXJ0ZWQgQ0NJRDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6MS41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si PjM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q291cmllcjtjb2xvcjpibGFjayI+VGhpcyBsb2cgcGVyZm9ybWVkIHRoZSBzeW50YXggY2hlY2tz IGZvciB0aGUgYXNzZXJ0ZWQgQ0NJRCwNCiBhbmQgdGhlIGNlcnRpZmljYXRlIHBhc3NlZDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+VGhp cyBsb2cgcGVyZm9ybWVkIHRoZSBzeW50YXggY2hlY2tzIGZvciB0aGUgYXNzZXJ0ZWQgQ0NJRCwN CiBhbmQgdGhlIGNlcnRpZmljYXRlIGZhaWxlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5ObyBv dGhlciBTVlYgdmFsdWVzIGFyZSBkZWZpbmVkIGJ5IHRoaXMgUkZDLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCklmIHRoZSBsb2cgcGVyZm9ybXMgc29tZSB2 YWxpZGF0aW9uIGNoZWNrcywgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSByZWx5aW5nIHBhcnR5 IGNhbiBsZXZlcmFnZSB0aGUgd29yayBhbHJlYWR5IGRvbmUgYnkgdGhlIGxvZz8mbmJzcDsgSWYg c28sIGl0IHB1dHMgdGhlIGxvZyBjaGVja2luZyBhdCBhIGRpZmZlcmVudCBwbGFjZSBpbiB0aGUg Y2VydGlmaWNhdGUgdmFsaWRhdGlvbiB0aGFuIEkgd2FzIGltYWdpbmluZy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltSaWNrXSBZZXMsIGEgcmVseWluZyBwYXJ0eSBjb3VsZCBsZXZlcmFnZSB0aGUgd29yayBhbHJl YWR5IGRvbmUgYnkgdGhlIGxvZyBzZXJ2ZXIsIGlmIHRoZSBSUCB0cnVzdGVkDQogaXQuIEdvb2ds ZSB3b3VsZCBwcm9iYWJseSBhZHZpc2UgYWdhaW5zdCB0aGlzLCBzaW5jZSB0aGV5IGhhdmUgYmVl biBwcmV0dHkgY29uc2lzdGVudCBpbiBzYXlpbmcgdGhhdCBDVCBkb2VzbuKAmXQgcmVxdWlyZSB5 b3UgdG8gdHJ1c3QgYW55b25lIGluY2x1ZGluZyB0aGUgbG9nIHNlcnZlci4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpUcmFucyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHJhbnNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UcmFuc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW5zIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFuczwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4262AC0DB9856847A2D00EF817E81139244489scygexch10cygnaco_-- From nobody Wed Oct 29 20:21:49 2014 Return-Path: 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 36CF81ACFFB for ; Wed, 29 Oct 2014 20:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 s4g6G_r9EDtn for ; Wed, 29 Oct 2014 20:21:45 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66A21ACFFA for ; Wed, 29 Oct 2014 20:21:45 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lf10so4488803pab.5 for ; Wed, 29 Oct 2014 20:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=VjGzhd2gUbGIdmZr2faVQuYTqTXn5eDfen7Zkyw83Ak=; b=Lyv7338QaNkw6e9ZDDCPuJ/ByS0PQw8ddMIJRKVR16vaNivlg0Kars2nRTvlO1QDvw 5fkH1ewDRhLDxVA8OKEWU9ooGSdVO3T613S4sx1KdKPkCGDqrvboSbHLwxTdBXpIeLpp dw8ovOvEI0RscsiErM/QrdPNxNZd7iQqLy70JAKhP68g9wPLErMkOu9GN1JmoPw7pApE n34rUalPVhYtXTq9E6GnU7BZsO4GNNVZAUcJp+HrygKmLVv8tG0ZQTJHjzaD7z4MMO51 rpQ5+eGGwdGBa36uL54vamux0acERqO44Rx+a19/FasndNI+Qs2MyrBDQ2PaZVgeQ+uv mA/Q== X-Received: by 10.68.65.74 with SMTP id v10mr14370204pbs.96.1414639305028; Wed, 29 Oct 2014 20:21:45 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (ip-64-134-234-4.public.wayport.net. [64.134.234.4]) by mx.google.com with ESMTPSA id rh5sm5632539pdb.4.2014.10.29.20.21.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 20:21:44 -0700 (PDT) Message-ID: <5451AEC7.6080203@gmail.com> Date: Wed, 29 Oct 2014 20:21:43 -0700 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Aq9zyEjRT6bzK39LqxhbHV4Q7rs Subject: [Trans] Gossip drafts X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 03:21:47 -0000 You all may have noticed that Linus has uploaded three drafts on gossip protocols for CT. Please give those a read. In the short term we need something we can publish as an experimental standard, so please give some thought about how to move this work forward. Once there's been some discussion we can adopt a draft as a working group deliverable. Melinda From nobody Thu Oct 30 01:16:40 2014 Return-Path: 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 2C0681AD03E for ; Thu, 30 Oct 2014 01:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 jWVr25tYPsN9 for ; Thu, 30 Oct 2014 01:16:36 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9C51AD036 for ; Thu, 30 Oct 2014 01:16:35 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9U8GWxM015442 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Oct 2014 09:16:32 +0100 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s9U8GSFW023601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 08:16:31 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1414656991; bh=nl6nQMz5qXMj+6DGKzX01EK0Y9cU8HTQ27ZIUAEuSRI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=fZf9Fd4CvjXMX9k3zNH0ok91w+qOjdKJmc6j717JOOVIuEHqW30xoGqmf+y3r/+xv JzRvtNPI5LU4lS9bFJ+1r3NM8br8vriIFPnyGxZxIgdAdXvsUouXdevFDcrWs/nh+c BVrDkabyPuPW8ZrX93GTnugYInCiankiLq6UJxtU= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 30 Oct 2014 09:16:28 +0100 From: Linus Nordberg To: Melinda Shore Organization: NORDUnet A/S References: <5451AEC7.6080203@gmail.com> Date: Thu, 30 Oct 2014 09:16:59 +0100 In-Reply-To: <5451AEC7.6080203@gmail.com> (Melinda Shore's message of "Wed, 29 Oct 2014 20:21:43 -0700") Message-ID: <877fzic6pw.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aN9kgwOg - 46efbd83ca97 - 20141030 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EXpKlbr6S97J0UZojW8jgoAVwo4 Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip drafts X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 08:16:38 -0000 Melinda Shore wrote Wed, 29 Oct 2014 20:21:43 -0700: | You all may have noticed that Linus has uploaded three | drafts on gossip protocols for CT. Please give those | a read. In the short term we need something we can | publish as an experimental standard, so please give some | thought about how to move this work forward. Once | there's been some discussion we can adopt a draft as | a working group deliverable. Right. I should've announced it here. Gossip split up in three pieces -- general, with a message format; CT specific saying STH and also SCT but with limited destinations; an HTTPS transport: https://datatracker.ietf.org/doc/draft-linus-trans-gossip/ https://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ https://datatracker.ietf.org/doc/draft-linus-trans-gossip-transport-https/ There's a fourth element which isn't found in any of these and that's strategy, or policy, for gossiping. That's been left out partly because I don't have an answer but also because I don't think it should be standardised. From nobody Thu Oct 30 05:25:55 2014 Return-Path: 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 03D691AD0BC for ; Thu, 30 Oct 2014 05:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 fnOYmpS0OsGK for ; Thu, 30 Oct 2014 05:25:46 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818ED1AD0A8 for ; Thu, 30 Oct 2014 05:25:46 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id z6so1538450yhz.26 for ; Thu, 30 Oct 2014 05:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WlrxjA+ZN6VVOYse+fcVYuAhsXo4G5/NlRNppxH0XKg=; b=IE1Nk1yIXvEpSUUwto2U3moiDwQpbd4qqc8B+qp0NGpXe71jH/96QkTh2zII/7GP/u bgnoPO7TeiMsEyfKNVis0AAh+SSwTNcoxHJVX2RRivCo3p+StJADss6ffo+d75mvRu+j WVD3lgdqMyq9VRoof0o8h6Uq65t8NcrD0GRYY+0vTSOFd28zDey7c4OkwkF9rAx3SImP hcLXUDFYKjztIaF/LtLuQwIGSoWrZ4QwxGyC6ss7hrMUWh0LEnWWBC1lkWGw55rg+oiy HfHpaLqVLlHhgp2uv7DxKthMRde/1gt9uqQd5cR6PqXKVv/Bc3+Q5u5vggrpSOhhkCVw FLUw== MIME-Version: 1.0 X-Received: by 10.170.209.206 with SMTP id a197mr16861659ykf.24.1414671945895; Thu, 30 Oct 2014 05:25:45 -0700 (PDT) Received: by 10.170.170.8 with HTTP; Thu, 30 Oct 2014 05:25:45 -0700 (PDT) In-Reply-To: <877fzic6pw.fsf@nordberg.se> References: <5451AEC7.6080203@gmail.com> <877fzic6pw.fsf@nordberg.se> Date: Thu, 30 Oct 2014 16:25:45 +0400 Message-ID: From: Dmitry Belyavsky To: Linus Nordberg , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11392b6ecf14730506a2fae9 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/I0UkrBcy7yrycvrDHy7UpkJD-x8 Subject: Re: [Trans] Gossip drafts X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:25:49 -0000 --001a11392b6ecf14730506a2fae9 Content-Type: text/plain; charset=UTF-8 Hello Linus! On Thu, Oct 30, 2014 at 12:16 PM, Linus Nordberg wrote: > Melinda Shore wrote > Wed, 29 Oct 2014 20:21:43 -0700: > > | You all may have noticed that Linus has uploaded three > | drafts on gossip protocols for CT. Please give those > | a read. In the short term we need something we can > | publish as an experimental standard, so please give some > | thought about how to move this work forward. Once > | there's been some discussion we can adopt a draft as > | a working group deliverable. > > Right. I should've announced it here. > > Gossip split up in three pieces -- general, with a message format; CT > specific saying STH and also SCT but with limited destinations; an HTTPS > transport: > > https://datatracker.ietf.org/doc/draft-linus-trans-gossip/ > https://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ > > https://datatracker.ietf.org/doc/draft-linus-trans-gossip-transport-https/ > > There's a fourth element which isn't found in any of these and that's > strategy, or policy, for gossiping. That's been left out partly because > I don't have an answer but also because I don't think it should be > standardised. > I'm sorry, I did not understand the data flow in whole. Did I understand correctly that browsers will gossip when they communicate with (web)servers? If so, the servers should process the gossip data they got, working as auditors. Or do I miss something? Thank you! -- SY, Dmitry Belyavsky --001a11392b6ecf14730506a2fae9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Linus!

On Thu, Oct 30, 2014 at 12:16 PM, Linus Nordberg <linus@nordu.net> wrote:
Melinda Shore <melinda.shore@gmail.com&= gt; wrote
Wed, 29 Oct 2014 20:21:43 -0700:

| You all may have noticed that Linus has uploaded three
| drafts on gossip protocols for CT.=C2=A0 Please give those
| a read.=C2=A0 In the short term we need something we can
| publish as an experimental standard, so please give some
| thought about how to move this work forward.=C2=A0 Once
| there's been some discussion we can adopt a draft as
| a working group deliverable.

Right. I should've announced it here.

Gossip split up in three pieces -- general, with a message format; CT
specific saying STH and also SCT but with limited destinations; an HTTPS transport:

=C2=A0 https://datatracker.ietf.org/doc/draft-linus-trans-gos= sip/
=C2=A0 https://datatracker.ietf.org/doc/draft-linus-trans-= gossip-ct/
=C2=A0 https://datatracker.ietf.org/doc/draft= -linus-trans-gossip-transport-https/

There's a fourth element which isn't found in any of these and that= 's
strategy, or policy, for gossiping. That's been left out partly because=
I don't have an answer but also because I don't think it should be<= br> standardised.

I'm sorry, I did not = understand the data flow in whole.=C2=A0

Did I und= erstand correctly that browsers will gossip when they communicate with (web= )servers?=C2=A0
If so, the servers should process the gossip data= they got, working as auditors.

Or do I miss somet= hing?

Thank you!

--
=
SY, Dmitry Belyavsky
--001a11392b6ecf14730506a2fae9-- From nobody Thu Oct 30 05:45:13 2014 Return-Path: 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 F2A561A0047 for ; Thu, 30 Oct 2014 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 qCgaYv1bHlvj for ; Thu, 30 Oct 2014 05:45:09 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059DA1A003B for ; Thu, 30 Oct 2014 05:45:08 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9UCj5LH010926 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Oct 2014 13:45:05 +0100 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s9UCj2QS009784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 12:45:04 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1414673104; bh=uWNHPj0x2pZNkeo7lr/afDnvkl4cegc6m4/E8ApCMOk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=DeCEQwAFfpVKpN3kNg0rJx2qHBRSxjp3ifqID7ejB6Ul6Yik6Ebc8C44llNhr9U/j R4su4lF47WJSu2fHedJYMOmU/hBiR3hrfjZOoYRf1jpJyLMqsX1WAYEejxx9XGSreA A24dcZGM9mbc/h4VmeZiEZ47QXAE6w083sYxz9Gw= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 30 Oct 2014 13:45:01 +0100 From: Linus Nordberg To: Dmitry Belyavsky Organization: NORDUnet A/S References: <5451AEC7.6080203@gmail.com> <877fzic6pw.fsf@nordberg.se> Date: Thu, 30 Oct 2014 13:45:34 +0100 In-Reply-To: (Dmitry Belyavsky's message of "Thu, 30 Oct 2014 16:25:45 +0400") Message-ID: <87egtpbua9.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aN9oJ5I0 - 4ad2f0b352e7 - 20141030 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2kFkPyxb0PHtr2CbNHkpA_Z8Ycg Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip drafts X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:45:11 -0000 Dmitry Belyavsky wrote Thu, 30 Oct 2014 16:25:45 +0400: | I'm sorry, I did not understand the data flow in whole. It's not very clear. | Did I understand correctly that browsers will gossip when they communicate | with (web)servers? Yes. | If so, the servers should process the gossip data they got, working as | auditors. | | Or do I miss something? There is no text on how servers should help. I'm thinking "gossip pools", storing some amount of gossiped data, replying to incoming gossip with an equal amount of random entries from the pool. I've been viewing this as strategy so far and not included it.