From filippo@cloudflare.com Thu Jun 1 18:56:57 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7012949D for ; Thu, 1 Jun 2017 18:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com 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 v7AcKmgSooLR for ; Thu, 1 Jun 2017 18:56:56 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 F2A5F12948E for ; Thu, 1 Jun 2017 18:56:55 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id t26so50054016qtg.0 for ; Thu, 01 Jun 2017 18:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=IN79g7A0V2B2mFjBo6vmIClbgDj+T68bBDwhqTRpHvE=; b=Wk0s8deeVDFo1w+TxOPm56o6v2iyxADqIi1P+2ucNUgcURoypvjU2iVzhM2Ki0oWIs 9BAPb0DZSQhfrp0TK5Zy/feiBj2yd30C+mSMPERJL4EMEK2PFzcbrl5y54IO3a1v9Moy hqGG092Ov2jcvcAIJ84H3Iynb9ViCb3TnTJgw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=IN79g7A0V2B2mFjBo6vmIClbgDj+T68bBDwhqTRpHvE=; b=Le96Q/KDOKTyrKsy+x3fS6MrkR8evpSdBmLPCNlymickK1r27M9bASHQNbt1LyXVj/ V44jNC0kLT4R9zQ55+OaCxbv5aizpfqFhrGiXhJXohZWFTl0xuorYKfNpdIH3Pt2+wAU rvlTsUsWLl4Eo8PPC4M0U6zlZwwXj/c7xD+Xyejz9ysArOu328cHS9Og0Grq7FddGcVG VLxirUBFsRdopvCVF2+3MBOxHWzCWyUC5xW23IkubqVvaGtLgoq6vB34VnMvZINxC4Vt LNxiHnv2wm0Ufd4zSzwWZ7bO2BeRreHveK9ZNUUSMxYq9DYw+3xHqRwEPVObDIeslfd+ jM2Q== X-Gm-Message-State: AODbwcBYDRwReQM4Vrc57zPoUrvhxOJaZZrBViS7pgcX+4ZuqVwfW70c NqLQYU58NZfw/1xqanbk3pqRJLPVYgtsxA9khQ== X-Received: by 10.200.34.35 with SMTP id o32mr5698935qto.67.1496368614751; Thu, 01 Jun 2017 18:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.18 with HTTP; Thu, 1 Jun 2017 18:56:34 -0700 (PDT) From: Filippo Valsorda Date: Thu, 1 Jun 2017 18:56:34 -0700 Message-ID: To: trans@ietf.org Cc: Nick Sullivan , George Tankersley Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 02 Jun 2017 02:09:22 -0000 A couple observations on what we can and can't achieve with strict CT. First, I think that for a scheme to be deployable it has to enable and not rollback the HTTPS automation trend. We can't tell Caddy (which recently affirmed that it rather not start than start with an expired certificate) to just wait a MMD or two at startup. We can't afford 24h delays in signups at Cloudflare. So any scheme that requires linking to out-of-band distributed blessed STHs needs an asynchronous verification fallback, at least for young certificates. I heard suggestions that the requirement might be enforced per-CA. I think that would cause pretty twisted incentives, and eventually die the way of HPKP: * A CA opting into "Strict CT"---which should be incentivized as more secure/privacy-preserving---would be exposing its customers to the 24h delays, a strong dis-incentive. LE would never opt-in, Cloudflare couldn't use such a CA. * For it to be effective against attackers that compromise a non-strict CA, the site would have to pin to the strict CA(s). But then losing the certificate private key means a MMD of downtime, which is effectively the same operational risk of leaf-pinning HPKP. Moreover, as Ryan pointed out, clients can be out of sync for significant periods, for causes indistinguishable from maliciousness, so there's no "safe amount of time" a website can wait, while a UA can't stop working after 24h failing to phone home. A zero-MMD log that immediately produces a STH doesn't help, because you face the exact same problems proving that the STH is not forked. It's hard-fail/soft-fail all over again, except we can meaningfully verify asynchronously---there's a CT log to hold accountable. Once you accept the need for an asynchronous verification method it becomes clear that we can't improve upon it in terms of: * complexity, since we still need to implement an asynchronous verification method * security against a colluding CA-log-MitM, since the attacker will keep generating young certificates * privacy against a malicious log, for the same reason All we can do is limit how often the asynchronous verification method is invoked in normal operation. I think the best possible outcome would be: * codify at which period STHs are issued, so each SCT has a known next STH (-bis basically requires a log to have a full and minimal history of STHs already, respectively because there are "existing and not" STHs, and for privacy; let's go the whole way and expose and codify it) * distribute off-band the whole history of STHs (~150 bytes * 2 STH per day * 365 days * 2 years window * 12 logs = 2.6MB) * optionally staple inclusion proofs to SCTs, which are now unique since they only need to link to the next canonical STH * offer an asynchronous method to fetch inclusion proofs for a SCT, which are now easy to cache in DNS because unique * if the UA does not yet have the STH for the SCT, it will defer verification; if it doesn't have the inclusion proof, it will fetch it; but in most cases it will have the STH and will use the stapled inclusion proof to verify the SCT It's compatible with all three distribution methods, still benefits from mandatory SCT (and if possible inclusion proof) in OCSP, and a CA and website willing to wait can also include the inclusion proof directly in the certificate. It would also have the excellent side-effect of making logs endpoints cacheable, as the number of artifacts would now be O(number of certificates). From nobody Sun Jun 4 18:36:32 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BABA126BF3 for ; Sun, 4 Jun 2017 18:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 NMr3qSbEvG1i; Sun, 4 Jun 2017 18:36:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1728124234; Sun, 4 Jun 2017 18:36:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Mon, 05 Jun 2017 01:36:30 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/181#comment:10 Message-ID: <037.14604f0cce4894c7b95282f0474dc4d3@ietf.org> References: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 01:36:31 -0000 #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: reopened => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Mon Jun 5 12:42:43 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC2812EAEE for ; Mon, 5 Jun 2017 12:42:41 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 e2Vu9bmlWBXv for ; Mon, 5 Jun 2017 12:42:39 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 A65FC12EAEF for ; Mon, 5 Jun 2017 12:42:39 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m47so87219943iti.0 for ; Mon, 05 Jun 2017 12:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ajkoh4Zkrr3ca7FEmqt7iPU/3yAuuNOEovAc3YRluQc=; b=MukLQqcVB/lQP8IFd4iTWfiYlK9w2zDh53fAFRb44UL1h2mkYUmWfqj+ZKTbsPYKc8 Ew8HGqPEQyqdqN9xEHMTEHqDp1V3KLGAWy/8UTkd1wBzntuDwMz0rFVND4CSD/dVVgBe ttQk9oYqNZvvycibRu7/DIMPgG2nHMouf5m9vdq4EETNGW9cr1MD1zsnJqhjegf1f/tU XMuwZ8PUy9is20otGBnN9+w+xfjJvocx1oWsNpJGtPgAmkPar0uSYpT21b5ls7CnmPjO o+SDCZtmwhlUINlIah232VW+OXFK4DahFep6X40H7SJDrj6NcVBZ0LVY7TKpdi7ctZX7 d0fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ajkoh4Zkrr3ca7FEmqt7iPU/3yAuuNOEovAc3YRluQc=; b=UBW8JisOHLarEzSBvFanin1/fKsdcEXq1uaUFWuv5VHqh23pep9tl5pbi9SiA4/3jo wrJZ8ZqZ25MvrlooAIOJL+QLyscLsN1+7m6Xf8YI0WvOyIaCSU5iNx9NBCQb4pHs6RKW SnhLF3PdEYlMD5ymMAkX8x6LC5QrnIw72U/PekCtkFqLhesKrIN4X6lHtX8Qk804ZRLx wOS/yygJ2R2aetW2wzovDLoCpZR2bheZGMQ5xZXm5y1SG72MnhFy4/xXexTU0U6vDF+m Y4/rpwzzBHwOtSgzOy5Vt7vXFm/iiK9ZnTHDpb7OOHSjB2a7Ndeh20lgjDE9BpxSkP0m ekEQ== X-Gm-Message-State: AODbwcAsAozUojSptxmlkuQDaZN1hWCEwPN1ReqlE3Z6YkzzK3GJX4rL pmWp1kxttRMxBeynnuDemetSMQjxicSk6xI= X-Received: by 10.36.50.66 with SMTP id j63mr14100747ita.42.1496691758770; Mon, 05 Jun 2017 12:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.204 with HTTP; Mon, 5 Jun 2017 12:42:08 -0700 (PDT) In-Reply-To: <20170528191028.20f285073eea33a3f23b6b5a@andrewayer.name> References: <20170528191028.20f285073eea33a3f23b6b5a@andrewayer.name> From: Eran Messeri Date: Mon, 5 Jun 2017 22:42:08 +0300 Message-ID: To: Andrew Ayer Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a114a8eec9f572c05513bb4d6" Archived-At: Subject: Re: [Trans] Mutability of Certificate Signatures X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 19:42:41 -0000 --001a114a8eec9f572c05513bb4d6 Content-Type: text/plain; charset="UTF-8" That's a known concern we've tried to address: https://trac.ietf.org /trac/trans/ticket/92 I agree this is a sub-optimal aspect of the protocol design, and would welcome better solutions than what we have right now. As you point out, Andrew, this is clumsy (at best) to solve for precertificates, which is what I expect most entries to be in a world where CT is mandatory. I think that the suggestion to fix this by defining as misbehaviour the presentation of an incorrectly-signed certificate chain in get-entries is the right one. Reasoning: - An SCT is useless to an attacker without a valid signature over the certificate/precertificate: The collusion described above is only harmful if a CA an a log are compromised, and even then, all it enables is for the CA to wash its hands of a particular certificate (which wouldn't be accepted by TLS clients without a valid signature). - It is pretty straightforward for a monitor to validate that all chains presented in get-entries are valid chains. - If we can't solve it properly for precertificates, then having different security guarantees for different kinds of entries would be confusing, at best. The upside of the change to only use the TBSCertificate + Issuer key hash in the log entry is that it's much easier to reconstruct the input for SCT signature validation: The same code is used for certs and precertificates. It's also easier to reason about the two entry types since they are treated identically. What do you think? Eran On Mon, May 29, 2017 at 5:10 AM, Andrew Ayer wrote: > In RFC6962-bis, the input to the Merkle Tree leaf hash > includes the TBSCertificate and the hash of the issuer key. > The certificate signature is not included in the leaf hash. > Consequentially, it is possible for a log to alter or remove > the signature without violating the append-only property of the log. > The tree's root hash would remain the same, and the log could still > produce valid inclusion proofs for the corresponding SCT. > > This enables the following attack: if a misissued certificate is > included in a log, an attacker could compromise or collude with the log > operator to alter or remove the certificate's signature. Then the log > no longer contains cryptographic proof that the CA misissued the > certificate. The CA indicated by issuer_key_hash could plausibly claim > that it didn't issue the certificate. Meanwhile, the log operator > could claim the invalid signature came from a submitter, and blame its > presence on a bug in the log's certificate acceptance code, something > which has already happened with two RFC6962 logs and was not considered > sufficiently bad by Chrome to warrant distrust[1]. > > Note that this problem also exists in RFC6962 with pre-certificates, > but not with certificates as the Merkle Tree leaf hash includes the full > certificate. > > This could be fixed without changing the protocol by adding language > that says that if a log cannot produce a full (pre-)certificate with a > valid signature that matches the TBSCertificate and issuer_key_hash in > the Merkle Tree leaf, then it must be considered misbehavior equivalent > to violating the append-only property. > > However, it seems unfortunate that we can't simply rely on the Merkle > Tree to ensure the immutability of crucial data - that is the whole > point of a Merkle Tree, after all. Auditors would need to perform > an additional, complicated step. Furthermore, if a log has a > legitimate bug that causes certificates with invalid signatures to be > accepted by accident, the log would have to be distrusted. > > Unfortunately, we can't simply include a whole pre-certificate in > the Merkle Tree leaf hash, as it is impossible to reconstruct from > the final certificate. (We could put the pre-certificate signature in > an extension in the final certificate, but that seems undesirable.) > > Any thoughts? Since this is a correctness issue, I think it needs a > resolution before RFC6962-bis is finalized. > > Regards, > Andrew > > [1] https://groups.google.com/a/chromium.org/forum/#!topic/ct- > policy/Itoq0YUZTlA > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114a8eec9f572c05513bb4d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's a known concern we've tried to address:=C2= =A0https://trac.ietf.org/trac/trans/ticket/92

I a= gree this is a sub-optimal aspect of the protocol design, and would welcome= better solutions than what we have right now. As you point out, Andrew, th= is is clumsy (at best) to solve for precertificates, which is what I expect= most entries to be in a world where CT is mandatory.

<= div>I think that the suggestion to fix this by defining as misbehaviour the= presentation of an incorrectly-signed certificate chain in get-entries is = the right one.
Reasoning:
- An SCT is useless to an att= acker without a valid signature over the certificate/precertificate: The co= llusion described above is only harmful if a CA an a log are compromised, a= nd even then, all it enables is for the CA to wash its hands of a particula= r certificate (which wouldn't be accepted by TLS clients without a vali= d signature).
- It is pretty straightforward for a monitor to val= idate that all chains presented in get-entries are valid chains.
= - If we can't solve it properly for precertificates, then having differ= ent security guarantees for different kinds of entries =C2=A0would be confu= sing, at best.

The upside of the change to only us= e the TBSCertificate + Issuer key hash in the log entry is that it's mu= ch easier to reconstruct the input for SCT signature validation: The same c= ode is used for certs and precertificates. It's also easier to reason a= bout the two entry types since they are treated identically.

=
What do you think?
Eran

On Mon, May 29, 2017 at 5:10 AM, And= rew Ayer <agwa@andrewayer.name> wrote:
In RFC6962-bis, the input to the Merkle Tree leaf hash
includes the TBSCertificate and the hash of the issuer key.
The certificate signature is not included in the leaf hash.
Consequentially, it is possible for a log to alter or remove
the signature without violating the append-only property of the log.
The tree's root hash would remain the same, and the log could still
produce valid inclusion proofs for the corresponding SCT.

This enables the following attack: if a misissued certificate is
included in a log, an attacker could compromise or collude with the log
operator to alter or remove the certificate's signature. Then the log no longer contains cryptographic proof that the CA misissued the
certificate.=C2=A0 The CA indicated by issuer_key_hash could plausibly clai= m
that it didn't issue the certificate.=C2=A0 Meanwhile, the log operator=
could claim the invalid signature came from a submitter, and blame its
presence on a bug in the log's certificate acceptance code, something which has already happened with two RFC6962 logs and was not considered
sufficiently bad by Chrome to warrant distrust[1].

Note that this problem also exists in RFC6962 with pre-certificates,
but not with certificates as the Merkle Tree leaf hash includes the full certificate.

This could be fixed without changing the protocol by adding language
that says that if a log cannot produce a full (pre-)certificate with a
valid signature that matches the TBSCertificate and issuer_key_hash in
the Merkle Tree leaf, then it must be considered misbehavior equivalent
to violating the append-only property.

However, it seems unfortunate that we can't simply rely on the Merkle Tree to ensure the immutability of crucial data - that is the whole
point of a Merkle Tree, after all.=C2=A0 Auditors would need to perform
an additional, complicated step.=C2=A0 Furthermore, if a log has a
legitimate bug that causes certificates with invalid signatures to be
accepted by accident, the log would have to be distrusted.

Unfortunately, we can't simply include a whole pre-certificate in
the Merkle Tree leaf hash, as it is impossible to reconstruct from
the final certificate.=C2=A0 (We could put the pre-certificate signature in=
an extension in the final certificate, but that seems undesirable.)

Any thoughts?=C2=A0 Since this is a correctness issue, I think it needs a resolution before RFC6962-bis is finalized.

Regards,
Andrew

[1] https://groups.googl= e.com/a/chromium.org/forum/#!topic/ct-policy/Itoq0YUZTlA

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

--001a114a8eec9f572c05513bb4d6-- From nobody Tue Jun 6 10:00:26 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55461294AC for ; Tue, 6 Jun 2017 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 ehV7wCvXQ3Sq for ; Tue, 6 Jun 2017 10:00:24 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320881270FC for ; Tue, 6 Jun 2017 10:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1496768423; bh=RAtp+ZloiKhYRCjZAQ5+LX4naTU3ObgyP8Kp1AJ32M0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=YEEsxibU/y649qRoZugwubH7+48ndb1cfkQXQUXcGLA1zTgKpSH+7tcJR0K52KJ+Y BB/fSoU9Oh9BJj5udgyOSyzGBbBqLMvbyNj+318YgROauSNA//68dHPsZvY4mnyPIw 4B/ndDXqWuNGOy9ToGFaRYfgZOJBdYHCY+BbRxiQLfQh8NL8kCZejwqSKrb1aFLc62 U2puJFKXli3UqKCo2oc3dPnGYSgJUduQKEGT3OKk0B4xF/toOIvlkvE1gnoy8UU7bb AGvsol9KY2RGeUeqYFylSRVPlZn80DeRnsYTB2G3zMTFYBoFzcmXJxny0HogrIvyDC Y7GyxveU/Pb1Q== Date: Tue, 6 Jun 2017 10:00:22 -0700 From: Andrew Ayer To: Eran Messeri Cc: "trans@ietf.org" Message-Id: <20170606100022.581f35cc2775fcc3abdfcfa2@andrewayer.name> In-Reply-To: References: <20170528191028.20f285073eea33a3f23b6b5a@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Mutability of Certificate Signatures X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 17:00:26 -0000 On Mon, 5 Jun 2017 22:42:08 +0300 Eran Messeri wrote: > I think that the suggestion to fix this by defining as misbehaviour > the presentation of an incorrectly-signed certificate chain in > get-entries is the right one. > Reasoning: > - An SCT is useless to an attacker without a valid signature over the > certificate/precertificate: The collusion described above is only > harmful if a CA an a log are compromised, and even then, all it > enables is for the CA to wash its hands of a particular certificate > (which wouldn't be accepted by TLS clients without a valid signature). > - It is pretty straightforward for a monitor to validate that all > chains presented in get-entries are valid chains. > - If we can't solve it properly for precertificates, then having > different security guarantees for different kinds of entries would > be confusing, at best. > > The upside of the change to only use the TBSCertificate + Issuer key > hash in the log entry is that it's much easier to reconstruct the > input for SCT signature validation: The same code is used for certs > and precertificates. You raise a good point: since there are far more TLS clients than monitors, it makes more sense to fix this problem by adding complexity to monitors than to TLS clients. So I agree that defining this as misbehavior and having monitors check is the right solution. Let's make sure we agree what monitors need to check for certificates (mutatis mutandis for precertificates): 1. The tbs_certificate in the x509_entry_v2 TransItem structure returned by get-entries must be byte-for-byte identical to the TBSCertificate portion of the leaf_certificate in the corresponding X509ChainEntry structure returned by get-entries. 2. The issuer_key_hash in the x509_entry_v2 TransItem structure returned by get-entries must correspond to the public key of the issuer of the leaf_certificate in the corresponding X509ChainEntry structure returned by get-entries. 3. The signature of the leaf_certificate in the X509ChainEntry structure returned by get-entries must be a valid signature from the key of its issuer. How should a monitor get the issuer public key to perform checks 2 and 3? The obvious way is to look at the first item in the X509ChainEntry's certificate_chain if the certificate is not self-signed, and at the certificate itself if it is self-signed. Unfortunately, if the logged certificate is a non-self-signed trust anchor accepted by the log, then certificate_chain is empty and there is no way to get the issuer public key. So a log could evade responsibility by making the certificate with a mutated signature a trust anchor. The inability to always get the issuer public key has been an inconvenience for me when monitoring RFC6962 logs. Sometimes I end up with a certificate and all I know about its issuer is its subject, when ideally I would like to know its public key as well (since a CA is uniquely identified by its subject and public key). (I suspect crt.sh has the same problem, based on some weird things I've observed there.) I previously considered this a mere inconvenience, but now I see it as a security problem. I think that the TimestampedCertificateEntryDataV2 structure should contain the full public key of the issuer instead of just its hash. That way, monitors are guaranteed access to the issuer public key, and it's easy to get. Step 2 above could be eliminated, and step 3 becomes simpler (no need to parse the issuer certificate to extract the public key). Thoughts? Regards, Andrew From nobody Tue Jun 6 10:28:26 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B271200CF for ; Tue, 6 Jun 2017 10:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 iIyysduyiwka for ; Tue, 6 Jun 2017 10:28:23 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 44150129AF4 for ; Tue, 6 Jun 2017 10:28:23 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id m47so113981030iti.0 for ; Tue, 06 Jun 2017 10:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EUq97YxSNsVTh9XTHhsQ05aLYlm4OFx4Ggpf4gBEPjo=; b=nnCFnJ0ME4E6aC0A9oE8nq3TZFs0ysRR9JBMflOAdlwT1QbOf/uZfF8PzgGGXbjAE2 6MHBHeAzGl8kx+rz0Ux/Q3MLcWMMY04xqePywzfI5QIGGLH3e78f2whNnjtP+NjXX8cZ ZEfjJZ7PkLOv+zY/2UB3vPkW9AlCmBMA1dFGKHFKEXJTAqMVjmpKAnAqbQfNc7vzYEBe zvRAjJDiWOCbWzBIjl5BZ7+znY5PilefyVHExaRIRmhzkLl4HaX17RfsFtyiFiyro6wh pAw9dZ8hdR5KvuQkawRdmdNWkRe9lwJM09UuLob7q+Y7+rWGD7XLG7I0Ggl2+HfewLZM zBTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EUq97YxSNsVTh9XTHhsQ05aLYlm4OFx4Ggpf4gBEPjo=; b=BdTCNNIGLH6ym2dIAkOFs+oowf+pQpSUZbenfq9XMRBkrkZoXzTL88Mkrh1cVGPgJP wQ2CL5FQrF/F1PZAQMZ9YI4jQS5tV1MPEPc9EQ0p8/auwx1qlWQLM58otm0jGK2M5lud YmyXmFH3Q5mmbXAb/eyPKmasRR6+1oAfKBcIgPsP7BC/2GFXtHg5StG0oo84q30ptGr8 j7zmEW5g6MA0bbaEuKKEIgSVcId5W9nFqewC9u4ZIO9Ykib5mfuBfwbNepMeIM0lSqHk bL/uHMAL/27L7F4GCS1gkEVtpoSyiCQc6v9bHs6jRtaOb3WETdFM1rJwMiGMidQnaxos 6irA== X-Gm-Message-State: AODbwcDZy7+k0fMh+hjhDo7kdln/YGMbac92DKhQ7fiUAci8Fdo+zCmD gxbNEzxY4zbGTcbY4atXeQZiB/CzRgCOF+M= X-Received: by 10.36.131.139 with SMTP id d133mr17967846ite.112.1496770102471; Tue, 06 Jun 2017 10:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.204 with HTTP; Tue, 6 Jun 2017 10:27:51 -0700 (PDT) In-Reply-To: <20170606100022.581f35cc2775fcc3abdfcfa2@andrewayer.name> References: <20170528191028.20f285073eea33a3f23b6b5a@andrewayer.name> <20170606100022.581f35cc2775fcc3abdfcfa2@andrewayer.name> From: Eran Messeri Date: Tue, 6 Jun 2017 18:27:51 +0100 Message-ID: To: Andrew Ayer Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11885e454f0d05514df2f4" Archived-At: Subject: Re: [Trans] Mutability of Certificate Signatures X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 17:28:25 -0000 --94eb2c11885e454f0d05514df2f4 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 6:00 PM, Andrew Ayer wrote: > On Mon, 5 Jun 2017 22:42:08 +0300 > Eran Messeri wrote: > > > I think that the suggestion to fix this by defining as misbehaviour > > the presentation of an incorrectly-signed certificate chain in > > get-entries is the right one. > > Reasoning: > > - An SCT is useless to an attacker without a valid signature over the > > certificate/precertificate: The collusion described above is only > > harmful if a CA an a log are compromised, and even then, all it > > enables is for the CA to wash its hands of a particular certificate > > (which wouldn't be accepted by TLS clients without a valid signature). > > - It is pretty straightforward for a monitor to validate that all > > chains presented in get-entries are valid chains. > > - If we can't solve it properly for precertificates, then having > > different security guarantees for different kinds of entries would > > be confusing, at best. > > > > The upside of the change to only use the TBSCertificate + Issuer key > > hash in the log entry is that it's much easier to reconstruct the > > input for SCT signature validation: The same code is used for certs > > and precertificates. > > You raise a good point: since there are far more TLS clients than > monitors, it makes more sense to fix this problem by adding complexity > to monitors than to TLS clients. So I agree that defining this as > misbehavior and having monitors check is the right solution. > > Let's make sure we agree what monitors need to check for certificates > (mutatis mutandis for precertificates): > > 1. The tbs_certificate in the x509_entry_v2 TransItem structure returned > by get-entries must be byte-for-byte identical to the TBSCertificate > portion of the leaf_certificate in the corresponding X509ChainEntry > structure returned by get-entries. > Correct. > > 2. The issuer_key_hash in the x509_entry_v2 TransItem structure returned > by get-entries must correspond to the public key of the issuer of the > leaf_certificate in the corresponding X509ChainEntry structure returned > by get-entries. > Correct. > > 3. The signature of the leaf_certificate in the X509ChainEntry > structure returned by get-entries must be a valid signature from the > key of its issuer. > Correct. > > How should a monitor get the issuer public key to perform checks 2 and > 3? The obvious way is to look at the first item in the X509ChainEntry's > certificate_chain if the certificate is not self-signed, and at the > certificate itself if it is self-signed. > Yes, the chain must be valid, so the first item in the chain (after the logged leaf) should be the issuer certificate. > > Unfortunately, if the logged certificate is a non-self-signed trust > anchor accepted by the log, then certificate_chain is empty and there > is no way to get the issuer public key. So a log could evade > responsibility by making the certificate with a mutated signature a > trust anchor. > Correct - but then the monitor should be able to verify it was a trust anchor at the point it was logged (maybe the output of get-trust-anchors should be signed?). > > The inability to always get the issuer public key has been an > inconvenience for me when monitoring RFC6962 logs. Sometimes I end up > with a certificate and all I know about its issuer is its subject, when > ideally I would like to know its public key as well (since a CA is > uniquely identified by its subject and public key). (I suspect crt.sh > has the same problem, based on some weird things I've observed there.) > I previously considered this a mere inconvenience, but now I see it as a > security problem. > Could you elaborate? Is that a security problem from a CT perspective - as in, could enable a log to avoid responsibility for something it logged, or from a WebPKI perspective, where some certificates can be in circulation but their issuer unknown? I'm trying to better understand under which circumstances such certificates would end up in the log - when would a log add a non-self-signed certificate as a trust anchor? > > I think that the TimestampedCertificateEntryDataV2 structure should > contain the full public key of the issuer instead of just its hash. > That way, monitors are guaranteed access to the issuer public key, and > it's easy to get. Step 2 above could be eliminated, and step 3 becomes > simpler (no need to parse the issuer certificate to extract the public > key). > > Thoughts? > > Regards, > Andrew > --94eb2c11885e454f0d05514df2f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 6:00 PM, Andrew Ayer <agwa@andrewayer.name> wrote:
On = Mon, 5 Jun 2017 22:42:08 +0300
Eran Messeri <eranm@google.com&g= t; wrote:

> I think that the suggestion to fix this by defining as misbehaviour > the presentation of an incorrectly-signed certificate chain in
> get-entries is the right one.
> Reasoning:
> - An SCT is useless to an attacker without a valid signature over the<= br> > certificate/precertificate: The collusion described above is only
> harmful if a CA an a log are compromised, and even then, all it
> enables is for the CA to wash its hands of a particular certificate > (which wouldn't be accepted by TLS clients without a valid signatu= re).
> - It is pretty straightforward for a monitor to validate that all
> chains presented in get-entries are valid chains.
> - If we can't solve it properly for precertificates, then having > different security guarantees for different kinds of entries=C2=A0 wou= ld
> be confusing, at best.
>
> The upside of the change to only use the TBSCertificate + Issuer key > hash in the log entry is that it's much easier to reconstruct the<= br> > input for SCT signature validation: The same code is used for certs > and precertificates.

You raise a good point: since there are far more TLS clients than monitors, it makes more sense to fix this problem by adding complexity
to monitors than to TLS clients.=C2=A0 So I agree that defining this as
misbehavior and having monitors check is the right solution.

Let's make sure we agree what monitors need to check for certificates (mutatis mutandis for precertificates):

1. The tbs_certificate in the x509_entry_v2 TransItem structure returned by get-entries must be byte-for-byte identical to the TBSCertificate
portion of the leaf_certificate in the corresponding X509ChainEntry
structure returned by get-entries.
Correct.=C2=A0

2. The issuer_key_hash in the x509_entry_v2 TransItem structure returned by get-entries must correspond to the public key of the issuer of the
leaf_certificate in the corresponding X509ChainEntry structure returned
by get-entries.
Correct.=C2=A0

3. The signature of the leaf_certificate in the X509ChainEntry
structure returned by get-entries must be a valid signature from the
key of its issuer.
Correct.=C2=A0

How should a monitor get the issuer public key to perform checks 2 and
3? The obvious way is to look at the first item in the X509ChainEntry's=
certificate_chain if the certificate is not self-signed, and at the
certificate itself if it is self-signed.
Yes, the chai= n must be valid, so the first item in the chain (after the logged leaf) sho= uld be the issuer certificate.=C2=A0

Unfortunately, if the logged certificate is a non-self-signed trust
anchor accepted by the log, then certificate_chain is empty and there
is no way to get the issuer public key.=C2=A0 So a log could evade
responsibility by making the certificate with a mutated signature a
trust anchor.
Correct - but then the monitor should be= able to verify it was a trust anchor at the point it was logged (maybe the= output of get-trust-anchors should =C2=A0be signed?).

The inability to always get the issuer public key has been an
inconvenience for me when monitoring RFC6962 logs. Sometimes I end up
with a certificate and all I know about its issuer is its subject, when
ideally I would like to know its public key as well (since a CA is
uniquely identified by its subject and public key).=C2=A0 (I suspect crt.sh=
has the same problem, based on some weird things I've observed there.)<= br> I previously considered this a mere inconvenience, but now I see it as a security problem.
Could you elaborate? Is that a secur= ity problem from a CT perspective - as in, could enable a log to avoid resp= onsibility for something it logged, or from a WebPKI perspective, where som= e certificates can be in circulation but their issuer unknown?
I&= #39;m trying to better understand under which circumstances such certificat= es would end up in the log - when would a log add a non-self-signed certifi= cate as a trust anchor?

I think that the TimestampedCertificateEntryDataV2 structure should contain the full public key of the issuer instead of just its hash.
That way, monitors are guaranteed access to the issuer public key, and
it's easy to get.=C2=A0 Step 2 above could be eliminated, and step 3 be= comes
simpler (no need to parse the issuer certificate to extract the public
key).

Thoughts?

Regards,
Andrew

--94eb2c11885e454f0d05514df2f4-- From nobody Tue Jun 6 10:39:15 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B86C129B16 for ; Tue, 6 Jun 2017 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 y2OsYiYxapY6 for ; Tue, 6 Jun 2017 10:39:11 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65AF129B0E for ; Tue, 6 Jun 2017 10:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1496770751; bh=IOnigPbcz5KxJI4Dt98MRS5bv9qlhqreHmJO1gXmGOc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GJ61b63cg3F7sm8uaIOuy7qLmS5sC9t8V8nWo/RQGXFkwNIO51AtWZRbvuDoRqwye 0smItVPK/nNxBBBOJ6zsz3daup6f/FAsXuQAG/1paepmgm47FI+BV6YweWCXwcPDD6 SeR2+fDCbr3mwp6B0T6WiM9ODd0bb+xNIdYwOtIQP0Sui93Rzms1n/RFrXOed/C4SV /xm4HxbEPBOF40JgnAXhdv7ywwvpka2iFUOt2X4Du44+750hYvBcTUPI0gsjVZC8mj pt1anGyDX4W3mHZeMNsgTTzlU4G049/7FYBE75kGhpiz6jcf4IUgFXVuHlp+YDAW7x tUcYrTmBJ2OuQ== Date: Tue, 6 Jun 2017 10:39:10 -0700 From: Andrew Ayer To: Eran Messeri Cc: "trans@ietf.org" Message-Id: <20170606103910.fd3034e146a98322c1227a14@andrewayer.name> In-Reply-To: References: <20170528191028.20f285073eea33a3f23b6b5a@andrewayer.name> <20170606100022.581f35cc2775fcc3abdfcfa2@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Mutability of Certificate Signatures X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 17:39:13 -0000 On Tue, 6 Jun 2017 18:27:51 +0100 Eran Messeri wrote: > [...] > > > > > Unfortunately, if the logged certificate is a non-self-signed trust > > anchor accepted by the log, then certificate_chain is empty and > > there is no way to get the issuer public key. So a log could evade > > responsibility by making the certificate with a mutated signature a > > trust anchor. > > > Correct - but then the monitor should be able to verify it was a trust > anchor at the point it was logged (maybe the output of > get-trust-anchors should be signed?). Could you elaborate? How does the monitor being able to verify it was a trust anchor at time of logging help? Regardless, the monitor is unable to perform checks 2 and 3 if it can't get the issuer public key, and so the attack which started this email thread can still be performed. > > > > The inability to always get the issuer public key has been an > > inconvenience for me when monitoring RFC6962 logs. Sometimes I end > > up with a certificate and all I know about its issuer is its > > subject, when ideally I would like to know its public key as well > > (since a CA is uniquely identified by its subject and public key). > > (I suspect crt.sh has the same problem, based on some weird things > > I've observed there.) I previously considered this a mere > > inconvenience, but now I see it as a security problem. > > > Could you elaborate? Is that a security problem from a CT perspective > - as in, could enable a log to avoid responsibility for something it > logged, or from a WebPKI perspective, where some certificates can be > in circulation but their issuer unknown? I mean from the CT perspective: that is, the log can still perform the attack we're trying to prevent. > I'm trying to better understand under which circumstances such > certificates would end up in the log - when would a log add a > non-self-signed certificate as a trust anchor? I don't know, but I have seen such certificates added as "roots" in existing RFC6962 logs. It's also interesting that RFC6962-bis changed the language from "root" to "trust anchor" which suggests this practice was intended to be explicitly supported. What was the motivation behind this language change? It would certainly fix the problem if trust anchors were required to be roots - that is, self-signed. Regards, Andrew From nobody Tue Jun 6 12:28:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942631294B2 for ; Tue, 6 Jun 2017 12:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 kwUV3elsUe3t for ; Tue, 6 Jun 2017 12:28:20 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C0F1242EA for ; Tue, 6 Jun 2017 12:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=+i0uLMHX4WwSGPmZeNxwkkUBskS+q+8PaLfcIYon1To=; b=uhOcgnvNnfiBG6SKvX55/l+/1d/b+ri9iSP2FXa2PXze87WOL3zLXnjVtaNE4SYja1Y1Ju6MMoofFk+OsM/4Q66dGL2qidYw4rZhLTcRcxcIYX6KPMlMhA1/XFk0vRL+1Yw+blr/A+JLZAGkPb02tRbNWXxrQljey5JB43ff4tA=; Received: ; Tue, 06 Jun 2017 12:28:19 -0700 To: Eran Messeri , "trans@ietf.org" References: From: Jacob Hoffman-Andrews Message-ID: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> Date: Tue, 6 Jun 2017 12:28:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FBE777B7AC7CDBBBC37E87CF" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 19:28:23 -0000 This is a multi-part message in MIME format. --------------FBE777B7AC7CDBBBC37E87CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'll echo what Filippo said and say that fast issuance (order of minutes) is important, and anything that breaks fast issuance for new sites (or for sites moving between providers) is a problem. In the long run, getting a certificate will be part of standing up a web site just as much as getting DNS and hosting are today. Are we willing to ask the web to accept a delay of 24 hours for any new site? I think that would be a big step backwards. On 05/23/2017 05:42 AM, Eran Messeri wrote: > Options for dealing with the delayed usability of certificates: > > * Opt-in: servers requires presence of proofs via header / X.509 > extension [6]. > This seems like the most plausible option, with the same caveats as HSTS about first visit. However, if Strict CT is only applied for a small number of sites that opt in, is it worth the extra ecosystem complexity? It seems like Strict CT on an opt-in basis would not be a meaningful substitute for gossip. > Certificate is used immediately, only with SCT: Clients accept certificates only with SCTs for a limited duration; after that an inclusion proof must be accompanied [4]. > [4] That requires auditing logs asynchronously, since an attacker with persistent access could keep getting new SCTs issued, or some clients may not have fresh STHs because they missed some updates. This seems potentially promising but I think it has some flaws. Would this auditing be done by the logs themselves, or by monitors? IIUC, logs are allowed to produce infinite SCTs for the same cert once they've logged it, and they don't have to produce the list of SCTs they've signed. So the only party that could meaningfully audit for excessive SCT generation would be the log itself, which is the party we're trying to defend against. --------------FBE777B7AC7CDBBBC37E87CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'll echo what Filippo said and say that fast issuance (order of minutes) is important, and anything that breaks fast issuance for new sites (or for sites moving between providers) is a problem. In the long run, getting a certificate will be part of standing up a web site just as much as getting DNS and hosting are today. Are we willing to ask the web to accept a delay of 24 hours for any new site? I think that would be a big step backwards.

On 05/23/2017 05:42 AM, Eran Messeri wrote:
Options for dealing with the delayed usability of certificates:
  • Opt-in: servers requires presence of proofs via header / X.509 extension [6].
This seems like the most plausible option, with the same caveats as HSTS about first visit. However, if Strict CT is only applied for a small number of sites that opt in, is it worth the extra ecosystem complexity? It seems like Strict CT on an opt-in basis would not be a meaningful substitute for gossip.

> Certificate is used immediately, only with SCT: Clients accept certificates only with SCTs for a limited duration; after that an inclusion proof must be accompanied [4].
> [4] That requires auditing logs asynchronously, since an attacker with persistent access could keep getting new SCTs issued, or some clients may not have fresh STHs because they missed some updates.

This seems potentially promising but I think it has some flaws. Would this auditing be done by the logs themselves, or by monitors? IIUC, logs are allowed to produce infinite SCTs for the same cert once they've logged it, and they don't have to produce the list of SCTs they've signed. So the only party that could meaningfully audit for excessive SCT generation would be the log itself, which is the party we're trying to defend against.
--------------FBE777B7AC7CDBBBC37E87CF-- From nobody Wed Jun 7 05:51:53 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2007112EC10 for ; Wed, 7 Jun 2017 05:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 N0DPFBaQICJR for ; Wed, 7 Jun 2017 05:51:48 -0700 (PDT) Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de3]) (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 61ABF129459 for ; Wed, 7 Jun 2017 05:51:48 -0700 (PDT) Received: from smtp-4.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-4.sys.kth.se (Postfix) with ESMTP id 3A388182; Wed, 7 Jun 2017 14:51:46 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-4.sys.kth.se ([127.0.0.1]) by smtp-4.sys.kth.se (smtp-4.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dVy91Qnc39Dh; Wed, 7 Jun 2017 14:51:45 +0200 (CEST) Received: from [IPv6:::1] (s17.lan.kth.se [IPv6:2001:6b0:1:1d20:214:c2ff:fe3a:5eec]) by smtp-4.sys.kth.se (Postfix) with ESMTPS id DAE4BCB3; Wed, 7 Jun 2017 14:51:41 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Magnus Ahltorp In-Reply-To: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> Date: Wed, 7 Jun 2017 14:51:39 +0200 Cc: Eran Messeri , "trans@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 12:51:52 -0000 6 June 2017 21:28 Jacob Hoffman-Andrews wrote: > I'll echo what Filippo said and say that fast issuance (order of = minutes) is important, and anything that breaks fast issuance for new = sites (or for sites moving between providers) is a problem. In the long = run, getting a certificate will be part of standing up a web site just = as much as getting DNS and hosting are today. Are we willing to ask the = web to accept a delay of 24 hours for any new site? I think that would = be a big step backwards. Well, that depends on the assurance level, doesn't it? For = domain-validated certificates, sure, but those are next to worthless = anyway. It would be hard to hold a CA responsible for issuing them, so = the need for logging them is really small. > > Certificate is used immediately, only with SCT: Clients accept = certificates only with SCTs for a limited duration; after that an = inclusion proof must be accompanied [4]. > > [4] That requires auditing logs asynchronously, since an attacker = with persistent access could keep getting new SCTs issued, or some = clients may not have fresh STHs because they missed some updates. >=20 > This seems potentially promising but I think it has some flaws. Would = this auditing be done by the logs themselves, or by monitors? IIUC, logs = are allowed to produce infinite SCTs for the same cert once they've = logged it, and they don't have to produce the list of SCTs they've = signed. So the only party that could meaningfully audit for excessive = SCT generation would be the log itself, which is the party we're trying = to defend against. If we are talking about "limited duration" of SCTs, we are talking about = the age of the timestamp in the SCT. Each timestamp that is used to = generate an SCT is required to be logged in the log. That is what the = log is logging, cert+timestamp. /Magnus From nobody Wed Jun 7 06:08:16 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDC12EC23 for ; Wed, 7 Jun 2017 06:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 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, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com 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 Gb-mRPURsRR0 for ; Wed, 7 Jun 2017 06:08:12 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D4B12EC01 for ; Wed, 7 Jun 2017 06:08:12 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 39C4BA004921 for ; Wed, 7 Jun 2017 06:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=Wuj8XUvqCQwouI6u11QGdC4zNQE=; b= vKiknugfKII/5Nhhi1HkadQdYr6e9BfQEgeSCZqSDygmwQ+wLLrUqpoeamyaBmnc c+2COKDj5myP7bRNZJ9jYmX8ViGwNFoS8WBagFyKtQrppmpqRGqbPJ4Ce78HiXjB aZJUiwol9pr3AljWlUsGz4sFzI8/mT4y1JHBNvvE2lU= Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 0F066A00491C for ; Wed, 7 Jun 2017 06:08:12 -0700 (PDT) Received: by mail-wm0-f52.google.com with SMTP id d64so9486148wmf.1 for ; Wed, 07 Jun 2017 06:08:11 -0700 (PDT) X-Gm-Message-State: AODbwcBXLpVlYf3ULGEa9Gj7nA6cNS/jgrQGB+rjxBGzOyhyXW7l/Z+A 7TpVGYylnw+HtAZw4mmZaYKlXu6vSg== X-Received: by 10.28.232.8 with SMTP id f8mr2147856wmh.51.1496840890440; Wed, 07 Jun 2017 06:08:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.200 with HTTP; Wed, 7 Jun 2017 06:08:09 -0700 (PDT) In-Reply-To: References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> From: Ryan Sleevi Date: Wed, 7 Jun 2017 09:08:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Magnus Ahltorp Cc: Jacob Hoffman-Andrews , Eran Messeri , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a11466ec68f8a4005515e6d1f" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 13:08:15 -0000 --001a11466ec68f8a4005515e6d1f Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp wrote: > Well, that depends on the assurance level, doesn't it? For > domain-validated certificates, sure, but those are next to worthless > anyway. It would be hard to hold a CA responsible for issuing them, so the > need for logging them is really small. > Let's not introduce CAs' marketing distinction into the technical discussion. Domain validated certificates - the basis for the Web PKI - are the only security level that matter. The holder of such a certificate can impersonate any site named in the certificate - whether from example.com to google.com. The other forms of certificates, "Organizationally Validated" or "Extended Validation", or, in the EU, Qualified Website Authentication Certificates, while nominally trying to provide higher assurance, do not meaningfully do so in the security model of the Web (which is the Origin). To that end, the past decade of CA misissuance responses have come down, in part, to the misissuance of certificates that attest to a websites identity, and CAs have been held responsible. I can totally appreciate a perspective that believes that CAs' human processes are far more secure than their automated processes, even if that perspective is not supported by the data. However, if we accept that - from a pragmatic and practical security perspective - that identifying a website grants the capability of TLS termination (namely, lacking an EKU or having an id-kp-serverAuth EKU, and naming one or more dNSName or iPAddress identities in a SAN) - then these certificates are very much in scope of the Web PKI, and thus need to be logged, as they present risk to the Web PKI consumers. > > > > Certificate is used immediately, only with SCT: Clients accept > certificates only with SCTs for a limited duration; after that an inclusion > proof must be accompanied [4]. > > > [4] That requires auditing logs asynchronously, since an attacker with > persistent access could keep getting new SCTs issued, or some clients may > not have fresh STHs because they missed some updates. > > > > This seems potentially promising but I think it has some flaws. Would > this auditing be done by the logs themselves, or by monitors? IIUC, logs > are allowed to produce infinite SCTs for the same cert once they've logged > it, and they don't have to produce the list of SCTs they've signed. So the > only party that could meaningfully audit for excessive SCT generation would > be the log itself, which is the party we're trying to defend against. > > If we are talking about "limited duration" of SCTs, we are talking about > the age of the timestamp in the SCT. Each timestamp that is used to > generate an SCT is required to be logged in the log. That is what the log > is logging, cert+timestamp. > I think this may have resulted from a misunderstanding. I'll try to explain one such scenario. Consider at T=0, Certificate X is logged, and an SCT(X, 0) is issued. The proof that such SCT has been incorporated into the STH will not be required until T=24, so such a certificate can be used (without proof of inclusion) from T=0 to T=24. Now, if I am a malicious CA, a T=23, I approach the log again, and request SCT(X, 23). The log, colluding with the CA, issues SCT(X, 23) - rather than the expect SCT(X, 0). Further, the log does not incorporate the SCT(X, 0) into STH(24) - it silently discards it. Clients will not expect to see a proof of this inclusion until STH(47) - that is, SCT(X, 23) + 24. On T=46, I repeat this process, obtaining SCT(X, 46), and clients not expecting this until STH(70). By the CA and Log colluding, I can continue to extend the period upon which I, the Evil Log, do not log this certificate. This situation arises because the SCTs can be delivered through multiple means, so it does not necessarily need to be fixed in the certificate. Yet even if it was fixed in the certificate, so long as I, the Evil Server, stop serving the cert prior to T=24, clients won't check the inclusion proof. This is why it was remarked that some form of auditing - of the SCTs produced by the log - would need to be asynchronously done, to ensure that SCT(X, 0) wasn't 'extended' beyond that. --001a11466ec68f8a4005515e6d1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp <map@kth.se> wro= te:
Well, that depends on the assurance l= evel, doesn't it? For domain-validated certificates, sure, but those ar= e next to worthless anyway. It would be hard to hold a CA responsible for i= ssuing them, so the need for logging them is really small.
=

Let's not introduce CAs' marketing distinction = into the technical discussion.

Domain validated ce= rtificates - the basis for the Web PKI - are the only security level that m= atter. The holder of such a certificate can impersonate any site named in t= he certificate - whether from example.com to google.com.

The other forms of certificates, "Organizationally Validated" or= "Extended Validation", or, in the EU, Qualified Website Authenti= cation Certificates, while nominally trying to provide higher assurance, do= not meaningfully do so in the security model of the Web (which is the Orig= in).

To that end, the past decade of CA misissuanc= e responses have come down, in part, to the misissuance of certificates tha= t attest to a websites identity, and CAs have been held responsible.
<= div>
I can totally appreciate a perspective that believes tha= t CAs' human processes are far more secure than their automated process= es, even if that perspective is not supported by the data. However, if we a= ccept that - from a pragmatic and practical security perspective - that ide= ntifying a website grants the capability of TLS termination (namely, lackin= g an EKU or having an id-kp-serverAuth EKU, and naming one or more dNSName = or iPAddress identities in a SAN) - then these certificates are very much i= n scope of the Web PKI, and thus need to be logged, as they present risk to= the Web PKI consumers.
=C2=A0

> > Certificate is used immediately, only with SCT: Clients accept ce= rtificates only with SCTs for a limited duration; after that an inclusion p= roof must be accompanied [4].
> > [4] That requires auditing logs asynchronously, since an attacker= with persistent access could keep getting new SCTs issued, or some clients= may not have fresh STHs because they missed some updates.
>
> This seems potentially promising but I think it has some flaws. Would = this auditing be done by the logs themselves, or by monitors? IIUC, logs ar= e allowed to produce infinite SCTs for the same cert once they've logge= d it, and they don't have to produce the list of SCTs they've signe= d. So the only party that could meaningfully audit for excessive SCT genera= tion would be the log itself, which is the party we're trying to defend= against.

If we are talking about "limited duration" of SCTs, we are= talking about the age of the timestamp in the SCT. Each timestamp that is = used to generate an SCT is required to be logged in the log. That is what t= he log is logging, cert+timestamp.

I th= ink this may have resulted from a misunderstanding. I'll try to explain= one such scenario.

Consider at T=3D0, Certificate= X is logged, and an SCT(X, 0) is issued. The proof that such SCT has been = incorporated into the STH will not be required until T=3D24, so such a cert= ificate can be used (without proof of inclusion) from T=3D0 to T=3D24.

Now, if I am a malicious CA, a T=3D23, I approach the = log again, and request SCT(X, 23). The log, colluding with the CA, issues S= CT(X, 23) - rather than the expect SCT(X, 0). Further, the log does not inc= orporate the SCT(X, 0) into STH(24) - it silently discards it.
Clients will not expect to see a proof of this inclusion until= STH(47) - that is, SCT(X, 23) + 24.

On T=3D46, I = repeat this process, obtaining SCT(X, 46), and clients not expecting this u= ntil STH(70).

By the CA and Log colluding, I can c= ontinue to extend the period upon which I, the Evil Log, do not log this ce= rtificate.

This situation arises because the SCTs = can be delivered through multiple means, so it does not necessarily need to= be fixed in the certificate. Yet even if it was fixed in the certificate, = so long as I, the Evil Server, stop serving the cert prior to T=3D24, clien= ts won't check the inclusion proof. This is why it was remarked that so= me form of auditing - of the SCTs produced by the log - would need to be as= ynchronously done, to ensure that SCT(X, 0) wasn't 'extended' b= eyond that.
--001a11466ec68f8a4005515e6d1f-- From nobody Wed Jun 7 06:29:50 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BA812EC3B for ; Wed, 7 Jun 2017 06:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Dri5q8DYA33R for ; Wed, 7 Jun 2017 06:29:44 -0700 (PDT) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de2]) (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 9DC7412EC48 for ; Wed, 7 Jun 2017 06:29:43 -0700 (PDT) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id E53E83514; Wed, 7 Jun 2017 15:29:40 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([127.0.0.1]) by smtp-3.sys.kth.se (smtp-3.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZqzTmqWmXd7O; Wed, 7 Jun 2017 15:29:37 +0200 (CEST) Received: from [IPv6:::1] (s17.lan.kth.se [IPv6:2001:6b0:1:1d20:214:c2ff:fe3a:5eec]) by smtp-3.sys.kth.se (Postfix) with ESMTPS id 926542A7B; Wed, 7 Jun 2017 15:29:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Magnus Ahltorp In-Reply-To: Date: Wed, 7 Jun 2017 15:29:29 +0200 Cc: Jacob Hoffman-Andrews , Eran Messeri , "trans@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3EE25497-89C9-47D3-B65C-836087F66344@kth.se> References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> To: Ryan Sleevi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 13:29:48 -0000 7 June 2017 15:08 Ryan Sleevi wrote: > On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp wrote: >> Well, that depends on the assurance level, doesn't it? For = domain-validated certificates, sure, but those are next to worthless = anyway. It would be hard to hold a CA responsible for issuing them, so = the need for logging them is really small. >=20 > Let's not introduce CAs' marketing distinction into the technical = discussion. >=20 > Domain validated certificates - the basis for the Web PKI - are the = only security level that matter. The holder of such a certificate can = impersonate any site named in the certificate - whether from example.com = to google.com. >=20 > The other forms of certificates, "Organizationally Validated" or = "Extended Validation", or, in the EU, Qualified Website Authentication = Certificates, while nominally trying to provide higher assurance, do not = meaningfully do so in the security model of the Web (which is the = Origin). >=20 > To that end, the past decade of CA misissuance responses have come = down, in part, to the misissuance of certificates that attest to a = websites identity, and CAs have been held responsible. >=20 > I can totally appreciate a perspective that believes that CAs' human = processes are far more secure than their automated processes, even if = that perspective is not supported by the data. However, if we accept = that - from a pragmatic and practical security perspective - that = identifying a website grants the capability of TLS termination (namely, = lacking an EKU or having an id-kp-serverAuth EKU, and naming one or more = dNSName or iPAddress identities in a SAN) - then these certificates are = very much in scope of the Web PKI, and thus need to be logged, as they = present risk to the Web PKI consumers. CAs cannot be held responsible for domain-validated certificates for the = simple reason that they don't have documentation, and therefore cannot = be required to produce documentation, which means that they can claim = anything. > > > Certificate is used immediately, only with SCT: Clients accept = certificates only with SCTs for a limited duration; after that an = inclusion proof must be accompanied [4]. > > > [4] That requires auditing logs asynchronously, since an attacker = with persistent access could keep getting new SCTs issued, or some = clients may not have fresh STHs because they missed some updates. > > > > This seems potentially promising but I think it has some flaws. = Would this auditing be done by the logs themselves, or by monitors? = IIUC, logs are allowed to produce infinite SCTs for the same cert once = they've logged it, and they don't have to produce the list of SCTs = they've signed. So the only party that could meaningfully audit for = excessive SCT generation would be the log itself, which is the party = we're trying to defend against. >=20 > If we are talking about "limited duration" of SCTs, we are talking = about the age of the timestamp in the SCT. Each timestamp that is used = to generate an SCT is required to be logged in the log. That is what the = log is logging, cert+timestamp. >=20 > I think this may have resulted from a misunderstanding. I'll try to = explain one such scenario. >=20 > Consider at T=3D0, Certificate X is logged, and an SCT(X, 0) is = issued. The proof that such SCT has been incorporated into the STH will = not be required until T=3D24, so such a certificate can be used (without = proof of inclusion) from T=3D0 to T=3D24. >=20 > Now, if I am a malicious CA, a T=3D23, I approach the log again, and = request SCT(X, 23). The log, colluding with the CA, issues SCT(X, 23) - = rather than the expect SCT(X, 0). Further, the log does not incorporate = the SCT(X, 0) into STH(24) - it silently discards it. >=20 > Clients will not expect to see a proof of this inclusion until STH(47) = - that is, SCT(X, 23) + 24. >=20 > On T=3D46, I repeat this process, obtaining SCT(X, 46), and clients = not expecting this until STH(70). >=20 > By the CA and Log colluding, I can continue to extend the period upon = which I, the Evil Log, do not log this certificate. >=20 > This situation arises because the SCTs can be delivered through = multiple means, so it does not necessarily need to be fixed in the = certificate. Yet even if it was fixed in the certificate, so long as I, = the Evil Server, stop serving the cert prior to T=3D24, clients won't = check the inclusion proof. This is why it was remarked that some form of = auditing - of the SCTs produced by the log - would need to be = asynchronously done, to ensure that SCT(X, 0) wasn't 'extended' beyond = that. It is definitely possible to generate new timestamps and not log them, = but I was rebutting "they don't have to produce the list of SCTs they've = signed", which is not true, unless "don't have to" is different from = "not required to". Logs are required to produce the list of all = timestamps they have signed when MMD has passed. That is what it means = to be a log. /Magnus From nobody Wed Jun 7 06:35:17 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D902612EC22 for ; Wed, 7 Jun 2017 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 c1ugxxPwGovi for ; Wed, 7 Jun 2017 06:35:11 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 7829412EB0C for ; Wed, 7 Jun 2017 06:35:11 -0700 (PDT) Received: (qmail 7949 invoked by uid 1004); 7 Jun 2017 13:35:09 -0000 Received: from rmdccgwarp2.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.83) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 07 Jun 2017 14:35:09 +0100 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201706071435064706; Wed, 07 Jun 2017 14:35:06 +0100 To: Andrew Ayer , Eran Messeri Cc: "trans@ietf.org" References: <20170528191028.20f285073eea33a3f23b6b5a@andrewayer.name> <20170606100022.581f35cc2775fcc3abdfcfa2@andrewayer.name> <20170606103910.fd3034e146a98322c1227a14@andrewayer.name> From: Rob Stradling Message-ID: <06e9d311-0033-8ecf-62e7-1fb2a38110f8@comodo.com> Date: Wed, 7 Jun 2017 14:35:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170606103910.fd3034e146a98322c1227a14@andrewayer.name> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Mutability of Certificate Signatures X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 13:35:16 -0000 On 06/06/17 18:39, Andrew Ayer wrote: >> I'm trying to better understand under which circumstances such >> certificates would end up in the log - when would a log add a >> non-self-signed certificate as a trust anchor? > > I don't know, but I have seen such certificates added as "roots" in > existing RFC6962 logs. It's also interesting that RFC6962-bis changed > the language from "root" to "trust anchor" which suggests this > practice was intended to be explicitly supported. What was the motivation > behind this language change? https://trac.ietf.org/trac/trans/ticket/102 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jun 7 06:57:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35312EC52 for ; Wed, 7 Jun 2017 06:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 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, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com 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 KJ5ppQri5Cpw for ; Wed, 7 Jun 2017 06:57:20 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DFC128796 for ; Wed, 7 Jun 2017 06:57:20 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 0D715A007332 for ; Wed, 7 Jun 2017 06:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=1yhx71A/HkioqCcVlFDWNj2SDN4=; b= Dfa2CrYP12N7JWhTC0QjsvO15ansUWn3oxKcQHAp7nL83lXyLdo3Nzpy1pEM6QYU x7epCEGXXiEX3wpHWtCyUi7fdgn416bmo+dVOrhBLzqs/b7GZFYdVk51SHG4uaKf +V7Hys3RMqhf/qG6jCQljL2mRKgupCsYYM7TB73D4wE= Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id D3E50A007330 for ; Wed, 7 Jun 2017 06:57:19 -0700 (PDT) Received: by mail-wm0-f43.google.com with SMTP id d73so11828762wma.0 for ; Wed, 07 Jun 2017 06:57:19 -0700 (PDT) X-Gm-Message-State: AKS2vOx4i66moQ+bMZXiOJeeZMrFPRGkMFSNX8MilVuwXRndDbcnlf26 1/oyKqBju7caiydF8EdbAiGbWbJOKA== X-Received: by 10.28.45.143 with SMTP id t137mr2523726wmt.6.1496843838453; Wed, 07 Jun 2017 06:57:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.200 with HTTP; Wed, 7 Jun 2017 06:57:17 -0700 (PDT) In-Reply-To: <3EE25497-89C9-47D3-B65C-836087F66344@kth.se> References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> <3EE25497-89C9-47D3-B65C-836087F66344@kth.se> From: Ryan Sleevi Date: Wed, 7 Jun 2017 09:57:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Magnus Ahltorp Cc: Ryan Sleevi , Eran Messeri , "trans@ietf.org" , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="001a1142467e46bb2d05515f1d3a" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 13:57:22 -0000 --001a1142467e46bb2d05515f1d3a Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 9:29 AM, Magnus Ahltorp wrote: > CAs cannot be held responsible for domain-validated certificates for the > simple reason that they don't have documentation, and therefore cannot be > required to produce documentation, which means that they can claim anything. > At the risk of going offtopic, by broadening into policy discussions, at least with respect to the Web PKI - which is certainly the only (publicly) deployed instance of CT, https://cabforum.org/baseline-requirements-documents/ govern and https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.5.pdf applies (Sections 3.2.2.4 & .5 and Section 5.4) TL;DR: Yes they do produce documentation, no, they cannot claim anything. > It is definitely possible to generate new timestamps and not log them, but > I was rebutting "they don't have to produce the list of SCTs they've > signed", which is not true, unless "don't have to" is different from "not > required to". Logs are required to produce the list of all timestamps they > have signed when MMD has passed. That is what it means to be a log. I'm not sure your usage of "required" to. If you mean in the abstract, philosophical sense - yes, a well-behaving log is expected to do so. However, an evil log can lie - and not produce such timestamps, by not integrating them into the log, despite having signed them. Which was the point - only an Honest Log can audit the production of all of its SCTs and make sure they're integrated, but the concern here is about a Dishonest Log, which would only integrate some of the SCTs into the STH. --001a1142467e46bb2d05515f1d3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 9:29 AM, Magnus Ahltorp <map@kth.se> wro= te:
CAs cannot be held= responsible for domain-validated certificates for the simple reason that t= hey don't have documentation, and therefore cannot be required to produ= ce documentation, which means that they can claim anything.

At the risk of going offtopic, by broadening into poli= cy discussions, at least with respect to the Web PKI - which is certainly t= he only (publicly) deployed instance of CT,=C2=A0https://cabforum.org/baseline-requi= rements-documents/ govern and=C2=A0https://cabforum.org/wp-conte= nt/uploads/CA-Browser-Forum-BR-1.4.5.pdf applies (Sections 3.2.2.4 &= ; .5 and Section 5.4)

TL;DR: Yes they do produce d= ocumentation, no, they cannot claim anything.
=C2=A0
It is definitely possible to gen= erate new timestamps and not log them, but I was rebutting "they don&#= 39;t have to produce the list of SCTs they've signed", which is no= t true, unless "don't have to" is different from "not re= quired to". Logs are required to produce the list of all timestamps th= ey have signed when MMD has passed. That is what it means to be a log.

I'm not sure your usage of "required&q= uot; to. If you mean in the abstract, philosophical sense - yes, a well-beh= aving log is expected to do so.

However, an evil l= og can lie - and not produce such timestamps, by not integrating them into = the log, despite having signed them. Which was the point - only an Honest L= og can audit the production of all of its SCTs and make sure they're in= tegrated, but the concern here is about a Dishonest Log, which would only i= ntegrate some of the SCTs into the STH.=C2=A0
--001a1142467e46bb2d05515f1d3a-- From nobody Wed Jun 7 07:36:29 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC912EC7C for ; Wed, 7 Jun 2017 07:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9uStfv546nBa for ; Wed, 7 Jun 2017 07:36:24 -0700 (PDT) Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de3]) (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 2E68512EC81 for ; Wed, 7 Jun 2017 07:36:23 -0700 (PDT) Received: from smtp-4.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-4.sys.kth.se (Postfix) with ESMTP id B9DEA427; Wed, 7 Jun 2017 16:36:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-4.sys.kth.se ([127.0.0.1]) by smtp-4.sys.kth.se (smtp-4.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QAe9xTvHT767; Wed, 7 Jun 2017 16:36:21 +0200 (CEST) Received: from [IPv6:::1] (s17.lan.kth.se [IPv6:2001:6b0:1:1d20:214:c2ff:fe3a:5eec]) by smtp-4.sys.kth.se (Postfix) with ESMTPS id 35E521C05; Wed, 7 Jun 2017 16:36:17 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Magnus Ahltorp In-Reply-To: Date: Wed, 7 Jun 2017 16:36:17 +0200 Cc: Eran Messeri , "trans@ietf.org" , Jacob Hoffman-Andrews Content-Transfer-Encoding: quoted-printable Message-Id: <3EA1C32B-B6A6-44BA-8E10-7053684B1732@kth.se> References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> <3EE25497-89C9-47D3-B65C-836087F66344@kth.se> To: Ryan Sleevi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 14:36:28 -0000 7 June 2017 15:57 Ryan Sleevi wrote: >> It is definitely possible to generate new timestamps and not log = them, but I was rebutting "they don't have to produce the list of SCTs = they've signed", which is not true, unless "don't have to" is different = from "not required to". Logs are required to produce the list of all = timestamps they have signed when MMD has passed. That is what it means = to be a log. >=20 > I'm not sure your usage of "required" to. If you mean in the abstract, = philosophical sense - yes, a well-behaving log is expected to do so. >=20 > However, an evil log can lie - and not produce such timestamps, by not = integrating them into the log, despite having signed them. Which was the = point - only an Honest Log can audit the production of all of its SCTs = and make sure they're integrated, but the concern here is about a = Dishonest Log, which would only integrate some of the SCTs into the STH.=20= But then "they don't have to produce the list of SCTs they've signed" = would be a meaningless statement, since no action by anyone in the world = would make them "have to" do anything. The only reasonable = interpretation of "have to" in this context is what is called "MUST" in = RFC 2119. If you mean "can do this undetected until time t", then say = so. But, in the same sentence, Jacob wrote: "IIUC, logs are allowed to = produce infinite SCTs for the same cert once they've logged it", which = is what I based my answer on. If the log disregards all rules and = doesn't care about being discovered as a bad log, surely it wouldn't = care about whether it was allowed to produce many SCTs for the same cert = or not. Which means that restricting that wouldn't solve that problem. /Magnus From nobody Wed Jun 7 08:31:16 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE04129B8B for ; Wed, 7 Jun 2017 08:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 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, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com 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 gUlHSDO1pyVo for ; Wed, 7 Jun 2017 08:31:12 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752CE129521 for ; Wed, 7 Jun 2017 08:31:12 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id CC125A007F02 for ; Wed, 7 Jun 2017 08:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=ccP2bYIDurRWu7gfm/iFkOHvm1w=; b= sKWM7l23fOB5SP1GhfmFbbUvolwjx5kXdVzoWH70dUcaB/HSzgaX3HAqdGv2ONoM 6f7NrSuo/pVmaFy9C4fooFYejI4SzWBKCoattBtsOIl9tUBkfsc7okF7VxIXKWvz e8KPV7u5R2BDw/Edc1XXWYGhqmPzolzEnvoj/Td3V/s= Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 9F4E8A007F01 for ; Wed, 7 Jun 2017 08:31:11 -0700 (PDT) Received: by mail-wm0-f53.google.com with SMTP id x70so60452906wme.0 for ; Wed, 07 Jun 2017 08:31:11 -0700 (PDT) X-Gm-Message-State: AODbwcBiI+MeX8mJNAuSS4lx6Lc/XHJlMm192Jix6oTpbDRw4+/vjZr6 CqJFjOVgf8J1U0/86OeUMtztYDgHfA== X-Received: by 10.28.220.212 with SMTP id t203mr214631wmg.6.1496849470172; Wed, 07 Jun 2017 08:31:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.200 with HTTP; Wed, 7 Jun 2017 08:31:09 -0700 (PDT) In-Reply-To: <3EA1C32B-B6A6-44BA-8E10-7053684B1732@kth.se> References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> <3EE25497-89C9-47D3-B65C-836087F66344@kth.se> <3EA1C32B-B6A6-44BA-8E10-7053684B1732@kth.se> From: Ryan Sleevi Date: Wed, 7 Jun 2017 11:31:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Magnus Ahltorp Cc: Ryan Sleevi , Eran Messeri , "trans@ietf.org" , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="001a114b2d6ef3ec490551606c9b" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 15:31:14 -0000 --001a114b2d6ef3ec490551606c9b Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 10:36 AM, Magnus Ahltorp wrote: > > But, in the same sentence, Jacob wrote: "IIUC, logs are allowed to produce > infinite SCTs for the same cert once they've logged it", which is what I > based my answer on. If the log disregards all rules and doesn't care about > being discovered as a bad log, surely it wouldn't care about whether it was > allowed to produce many SCTs for the same cert or not. Which means that > restricting that wouldn't solve that problem. > I think there may be some disconnect here still, unfortunately. For example, in your response, you note "and doesn't care about being discovered about a bad log". The concerns raised - with respect to the production of SCTs and the deferring of inclusion proof fetching on the basis of that timestamp - were to highlight that it creates a scenario in which a bad log would not be discovered using the scheme, as proposed. This is why it was highlighted that 'someone' would have to examine the SCTs produced - including those _before_ the 'must include inclusion proof' time - so make sure that those SCTs were, in fact, logged. Which brings us back to the original problem, of clients checking inclusion proofs of SCTs asynchronously/out-of-band (and/or gossiping them), which suggests that a solution of stapled inclusion proofs (with a 'grace period') doesn't solve the client-checking problem, and the (original) discussion of stapled inclusion proofs (with no grace period) is operationally unviable, because it means a certificate cannot be deployed until the inclusion. These were all motivating design factors in both the original and subsequent designs of 6962 and 6962-bis, but were perhaps not articulated clearly as such. --001a114b2d6ef3ec490551606c9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 10:36 AM, Magnus Ahltorp <<= a href=3D"mailto:map@kth.se" target=3D"_blank">map@kth.se> wr= ote:
But, in the same sentence, Jacob wrote: "IIUC, logs are allowed to pro= duce infinite SCTs for the same cert once they've logged it", whic= h is what I based my answer on. If the log disregards all rules and doesn&#= 39;t care about being discovered as a bad log, surely it wouldn't care = about whether it was allowed to produce many SCTs for the same cert or not.= Which means that restricting that wouldn't solve that problem.

I think there may be some disconnect here stil= l, unfortunately.

For example, in your response, y= ou note "and doesn't care about being discovered about a bad log&q= uot;. The concerns raised - with respect to the production of SCTs and the = deferring of inclusion proof fetching on the basis of that timestamp - were= to highlight that it creates a scenario in which a bad log would not be di= scovered using the scheme, as proposed. This is why it was highlighted that= 'someone' would have to examine the SCTs produced - including thos= e _before_ the 'must include inclusion proof' time - so make sure t= hat those SCTs were, in fact, logged. Which brings us back to the original = problem, of clients checking inclusion proofs of SCTs asynchronously/out-of= -band (and/or gossiping them), which suggests that a solution of stapled in= clusion proofs (with a 'grace period') doesn't solve the client= -checking problem, and the (original) discussion of stapled inclusion proof= s (with no grace period) is operationally unviable, because it means a cert= ificate cannot be deployed until the inclusion. These were all motivating d= esign factors in both the original and subsequent designs of 6962 and 6962-= bis, but were perhaps not articulated clearly as such.=C2=A0
--001a114b2d6ef3ec490551606c9b-- From nobody Wed Jun 7 08:45:09 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7235812ECA5 for ; Wed, 7 Jun 2017 08:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2GHa4n_u1dk1 for ; Wed, 7 Jun 2017 08:44:56 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 5351A1294BF for ; Wed, 7 Jun 2017 08:44:56 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id h4so7291075oib.3 for ; Wed, 07 Jun 2017 08:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oGWMMg2Xavlg72fMVxcaLFVxvP3fgOy8nsfiYoEgCAs=; b=HqvTQFIEflZ4ccZVc+7nuYIMFlGr0tZkqUtBrK8EohHpPHsBfDkT/reAwUYiFgDjO1 v6afua/Mfh7158iNF2xuPLD4aUUEgW33/L+MSsse81Mb22XnlrkPiozBQ7AzMo7u8KXO hHyAZo/XKWRU24mVAq/WfJa8PaTujFzAIOAreif/cS0NOGnYrDYv0IPXypBZfi7VRrrj pQW/TqTerY+UilNCQ7+TfIWsjVOu/31mcrHPxXl2+RJv0g0sMDsQylEoHtMn8YtTiuBT VPsuUpgeKJ9VF1g0YiUugZhHHhxebK812UIfxv2SR8qwEBMSWRK0x3tpkTxEuHwGQku3 XtrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oGWMMg2Xavlg72fMVxcaLFVxvP3fgOy8nsfiYoEgCAs=; b=jWQKI5hnHmATGOvvdbcjt/9CAI9cUnwqlwRNHeY0T2UxVWj+ps6sfBIeE7X5+4fTan qdw2qezIm1hR/hOh3DGE/HrPXTEhcbfnGuYsjs2LKLyTSUC2kiZcb4IRG2a1VmC/AujA vrs62gIuNO8NCzNGqv2SlzS1rXDsn/qsM2NrkPL0FHpY+Iu6V1f6DBPdQnoExNAKkVqc vWmH0X4lf0RyfSQqwdwnKAhq3+DcLsUpai+SFWutKrMv25/BYpGQlrI02xc3pMJ3rCS6 HOK3dq/tTSutP+vS7MOWgy43107h1kSoh5gosbeqZlpKDlNrM5WIVpIjwZA/cN2YI1Id v1Kg== X-Gm-Message-State: AODbwcAHxJRLh+/Cno1JY6cwNzOHyVWKSIja8w15APufbz/UCLWnULFg S/duAAgkC2JCxBue9EQyeE+gy8M0gg== X-Received: by 10.202.192.67 with SMTP id q64mr19195813oif.65.1496850295618; Wed, 07 Jun 2017 08:44:55 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Wed, 7 Jun 2017 08:44:54 -0700 (PDT) In-Reply-To: References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> From: Phillip Hallam-Baker Date: Wed, 7 Jun 2017 11:44:54 -0400 X-Google-Sender-Auth: hzUKyfbKoqMNzYpJyJ90KTy-f5E Message-ID: To: Ryan Sleevi Cc: Magnus Ahltorp , Eran Messeri , "trans@ietf.org" , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="001a1135b6c827031b0551609e44" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 15:45:05 -0000 --001a1135b6c827031b0551609e44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 7, 2017 at 9:08 AM, Ryan Sleevi wrote: > > > On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp wrote: > >> Well, that depends on the assurance level, doesn't it? For >> domain-validated certificates, sure, but those are next to worthless >> anyway. It would be hard to hold a CA responsible for issuing them, so t= he >> need for logging them is really small. >> > > Let's not introduce CAs' marketing distinction into the technical > discussion. > =E2=80=8BMarketing is sometimes based on facts. In this case inconvenient f= acts for people proposing to trash the WebPKI trust model. If you want to spread disinformation, then I am going to respond to correct. https://www.scmagazineuk.com/updated-97-of-malicious-mobile-malware-targets= -android/article/535410/ The press have stopped writing articles about 97% of malware targeting Android because it is no longer news. Apple do have some advantages in their structure besides enforcing what amounts to EV validation of developers. But it is the validation of every developer before they get developer credentials that makes the rest of their model feasible. > Domain validated certificates - the basis for the Web PKI - are the only > security level that matter. The holder of such a certificate can > impersonate any site named in the certificate - whether from example.com > to google.com. > =E2=80=8BDomain Validation is not the 'basis' for the WebPKI. It did not ev= en exist until late in the dotCom boom. The WebPKI was originally designed to establish accountability. It is the bridge between the online and offline accountability infrastructure. What was not anticipated in the original design was that there would be a demand for certificates that only provided encryption and a minimal level of authentication. And in our defense, I will point out that even the banks were not encrypting their entire sites until quite late in the game. Back in 1997, RSA was a serious resource hog even at 1024 bits and SSL accelerators were only just starting to exist in usable form (you could buy 'em, taking delivery was another matter). The other forms of certificates, "Organizationally Validated" or "Extended > Validation", or, in the EU, Qualified Website Authentication Certificates= , > while nominally trying to provide higher assurance, do not meaningfully d= o > so in the security model of the Web (which is the Origin). > =E2=80=8BI suggest that stating that the Web has a single security model is obviously wrong. The JavaScript security model is origin but even that is a retrofit and it is not the Web security model.=E2=80=8B > To that end, the past decade of CA misissuance responses have come down, > in part, to the misissuance of certificates that attest to a websites > identity, and CAs have been held responsible. > Issuance =E2=80=8Bof phishing certificates with Paypal in the name is explo= ding. But if you aren't actually bothered about phishing fraud, I guess you can claim an improvement. One of the facts that the industry is going to have to face is that there is a choice, only one of the following can be true: * Every site is encrypted. * Certificates are not issued to criminals. =E2=80=8BNow the WebPKI model for EV and DV is very much that the second is= true and always has been in the 25 years I have been involved in its development. And no, I do not need an adventure in 'alternative history'. I was there. I was part of the original design discussions. What I am getting at though is something different. There are in fact multiple security concerns for a system as large as the Web and one size fits all security is not going to work. The problem with equating enabling encryption with 'security' is that it just is not so. Encryption is a starting point for security but it is a weak one. That was how I broke SSL/1.0, Marc had only considered confidentiality as a security concern. The way to address the conflict raised above is to observer that while it is true that every communication should be encrypted, it is not true that every communication should be represented to the user as providing security. What we need to do is to bifurcate the DV level and distinguish between certificates that only enable confidentiality and those that provide authentication. The first would become a new category 'minimal validation' and would not be required to prevent issue of paypal certificates etc, or provide for revocation or any other controls. The second would be an enhanced DV providing full revocation and lifecycle management. > I can totally appreciate a perspective that believes that CAs' human > processes are far more secure than their automated processes, even if tha= t > perspective is not supported by the data. > =E2=80=8BActually it is. The work factor for obtaining an EV cert as a criminal is markedly higher than for DV which is in turn markedly higher than that for those who don't do any lifecycle controls. =E2=80=8B =E2=80=8BPHB=E2=80=8B --001a1135b6c827031b0551609e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ju= n 7, 2017 at 9:08 AM, Ryan Sleevi <ryan-ietf@sleevi.com> = wrote:


On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp <map@kth.se> wrote:
Well, that= depends on the assurance level, doesn't it? For domain-validated certi= ficates, sure, but those are next to worthless anyway. It would be hard to = hold a CA responsible for issuing them, so the need for logging them is rea= lly small.

Let's not introdu= ce CAs' marketing distinction into the technical discussion.

=E2=80=8BMarketing is sometimes based on facts. I= n this case inconvenient facts for people proposing to trash the WebPKI tru= st model. If you want to spread disinformation, then I am going to respond = to correct.
https://www.scmagazineuk.com/updated-97-of-maliciou= s-mobile-malware-targets-android/article/535410/

The press have stopped writing articles about 9= 7% of malware targeting Android because it is no longer news. Apple do have= some advantages in their structure besides enforcing what amounts to EV va= lidation of developers. But it is the validation of every developer before = they get developer credentials that makes the rest of their model feasible.=


=C2=A0
Domain validated certificates - the basis for the Web PKI - are= the only security level that matter. The holder of such a certificate can = impersonate any site named in the certificate - whether from example.com to google.com.

=E2=80=8BDomain Validation is not the 'basis' for the WebPKI. I= t did not even exist until late in the dotCom boom. The WebPKI was original= ly designed to establish accountability. It is the bridge between the onlin= e and offline accountability infrastructure.

What was not anticipated in the original design was th= at there would be a demand for certificates that only provided encryption a= nd a minimal level of authentication. And in our defense, I will point out = that even the banks were not encrypting their entire sites until quite late= in the game. Back in 1997, RSA was a serious resource hog even at 1024 bit= s and SSL accelerators were only just starting to exist in usable form (you= could buy 'em, taking delivery was another matter).



The other forms of certificates, "Organizationally Validated" = or "Extended Validation", or, in the EU, Qualified Website Authen= tication Certificates, while nominally trying to provide higher assurance, = do not meaningfully do so in the security model of the Web (which is the Or= igin).

=E2=80=8BI suggest that statin= g that the Web has a single security model is obviously wrong.

The JavaScript security model is orig= in but even that is a retrofit and it is not the Web security model.=E2=80= =8B

=C2=A0
To that end, the past decade of CA misissuance r= esponses have come down, in part, to the misissuance of certificates that a= ttest to a websites identity, and CAs have been held responsible.

Issuance =E2=80=8Bof phishing certificates with = Paypal in the name is exploding. But if you aren't actually bothered ab= out phishing fraud, I guess you can claim an improvement.=C2=A0

One of the facts that the industry i= s going to have to face is that there is a choice, only one of the followin= g can be true:
=
* Every si= te is encrypted.
* Certificates are not issued to criminals.

=E2=80=8BNow the WebPKI model= for EV and DV is very much that the second is true and always has been in = the 25 years I have been involved in its development. And no, I do not need= an adventure in 'alternative history'. I was there. I was part of = the original design discussions.

What I am getting at though is something different. There are in fa= ct multiple security concerns for a system as large as the Web and one size= fits all security is not going to work. The problem with equating enabling= encryption with 'security' is that it just is not so. Encryption i= s a starting point for security but it is a weak one. That was how I broke = SSL/1.0, Marc had only considered confidentiality as a security concern.


The way to address the conflict raise= d above is to observer that while it is true that every communication shoul= d be encrypted, it is not true that every communication should be represent= ed to the user as providing security.=C2=A0

What we need to do is to bifurcate the DV level and di= stinguish between certificates that only enable confidentiality and those t= hat provide authentication. The first would become a new category 'mini= mal validation' and would not be required to prevent issue of paypal ce= rtificates etc, or provide for revocation or any other controls. The second= would be an enhanced DV providing full revocation and lifecycle management= .
=C2=A0
I can totally appreciate a perspective that believes that CAs' hu= man processes are far more secure than their automated processes, even if t= hat perspective is not supported by the data.

=E2=80=8BActually it is.

The work factor for obtaining an EV cert as a criminal is markedly h= igher than for DV which is in turn markedly higher than that for those who = don't do any lifecycle controls.
=E2=80=8B

=E2=80=8B= PHB=E2=80=8B

--001a1135b6c827031b0551609e44-- From nobody Sun Jun 11 18:23:00 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B581279E5 for ; Sun, 11 Jun 2017 18:22:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RSGZYUJdYjdz for ; Sun, 11 Jun 2017 18:22:57 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 3B0111200C1 for ; Sun, 11 Jun 2017 18:22:57 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id a70so40088206pge.3 for ; Sun, 11 Jun 2017 18:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ra4RLphNgXq3CwMWSlZCOhf0nPL/nXDK/3XIWU6K4w0=; b=sI5Wm/I3eeWkEqxmvfFr6mBuxSNeI2aVoGaQtpu8j00Yi8zJ2KyGMimIwGem1fG07E ZxH7+mcvhFULEpDQ8A9r+TCPvYcMFtpiOqi40BvjK9aQ2ai3N56mCApiFkwIx1Ssf0fI C565yWrqLj3YVmMH/CU0I1ht9ic6ksIDrM71hlSLnu3WSb5XXtvZVPavNwC7kQlGsZGZ u7DQ1XzFNqFNqMAA91om7b0znVIHXh6piSBTU7OULRiEaB+UTSc4jxyAPRVIyEpHq9ld pSgSJR3coSRvDSqBvXSTWSFbQvD4eNbIT3ZvCyzBkanJXnwUkcbXxoHh8VfU8498Mgpk 2Cxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ra4RLphNgXq3CwMWSlZCOhf0nPL/nXDK/3XIWU6K4w0=; b=RipfQs/mZFKAfqirsVV1fezdZHmsefXLERb5LmYKWP7czwXtYsfECZSolBCLYE2fDT GZJMxwCvx6WMAgbRdIok8ftvjqVbrYo0j40p82UzCwOmIL4jDW0MGud/RG+OzMrigrhz b6Z9+wRZGHZBgk55KgODgwzi6dhGBiEudHK98DUZmFtti04Zci8Fr/XQQr5JqZN/MduN kVuI+CI1/5XLDg2AQfYLJWgw1U8qaSmemjpp5tqgYNok763qZ8OM7NlaX0Ffi98ZdAXK ThBczqcPy3Lnssw/UTgNcvRzJlb7HUWrKWHp+KEIcOMWyM4wAVp6Qn8HmbsI2f0qmwg8 PR7A== X-Gm-Message-State: AODbwcDUYzTYQVusR9GbQdMJSh42c0MgsHEBQJ/vfVjZvlsfRZNh9zLv JeqLbAYfILPRv7cTwqOdjeguYsxNJg== X-Received: by 10.98.158.138 with SMTP id f10mr42968568pfk.177.1497230576794; Sun, 11 Jun 2017 18:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.225 with HTTP; Sun, 11 Jun 2017 18:22:56 -0700 (PDT) In-Reply-To: References: <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> From: Watson Ladd Date: Sun, 11 Jun 2017 18:22:56 -0700 Message-ID: To: Phillip Hallam-Baker Cc: Ryan Sleevi , Eran Messeri , Jacob Hoffman-Andrews , "trans@ietf.org" , Magnus Ahltorp Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 01:22:59 -0000 On Jun 7, 2017 8:45 AM, "Phillip Hallam-Baker" wrote: On Wed, Jun 7, 2017 at 9:08 AM, Ryan Sleevi wrote: > > > > On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp wrote: >> >> Well, that depends on the assurance level, doesn't it? For domain-validated certificates, sure, but those are next to worthless anyway. It would be hard to hold a CA responsible for issuing them, so the need for logging them is really small. > > > Let's not introduce CAs' marketing distinction into the technical discussion. Marketing is sometimes based on facts. In this case inconvenient facts for people proposing to trash the WebPKI trust model. If you want to spread disinformation, then I am going to respond to correct. https://www.scmagazineuk.com/updated-97-of-malicious-mobile-malware-targets-android/article/535410/ The press have stopped writing articles about 97% of malware targeting Android because it is no longer news. Apple do have some advantages in their structure besides enforcing what amounts to EV validation of developers. But it is the validation of every developer before they get developer credentials that makes the rest of their model feasible. > > Domain validated certificates - the basis for the Web PKI - are the only security level that matter. The holder of such a certificate can impersonate any site named in the certificate - whether from example.com to google.com. Domain Validation is not the 'basis' for the WebPKI. It did not even exist until late in the dotCom boom. The WebPKI was originally designed to establish accountability. It is the bridge between the online and offline accountability infrastructure. So I get to sue Verisign if they issue a cert incorrectly? Oh wait, that isn't actually the case: CAs disclaim all responsibility for what you say they they are supposed to do. Was it ever the case that this was possible? From nobody Fri Jun 16 03:42:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4632C1292D3 for ; Fri, 16 Jun 2017 03:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 jlbYvyXqlQSQ; Fri, 16 Jun 2017 03:42:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBF1271DF; Fri, 16 Jun 2017 03:42:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 16 Jun 2017 10:42:50 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/189#comment:2 Message-ID: <051.1c869d1809b66633434aaeb3f267f9a6@ietf.org> References: <036.0d5f9d9469341d54f42d6a36bef19485@ietf.org> X-Trac-Ticket-ID: 189 In-Reply-To: <036.0d5f9d9469341d54f42d6a36bef19485@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #189: Permit logs to use EdDSA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 10:42:51 -0000 #189: Permit logs to use EdDSA -----------------------------+--------------------------------------------- Reporter: rob.stradling@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: enhancement | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+--------------------------------------------- Changes (by rob.stradling@…): * milestone: => review Comment: Addressed by https://github.com/google/certificate-transparency- rfcs/commit/7ed2a968743f9e715812eab1ed9eae582827ac4e This adds Ed25519 (PureEdDSA with the edwards25519 curve) to the 6962-bis signature algorithm registry. Also, as per discussion on the list, we briefly considered switching the RSA requirement from PKCS#1v1.5 to RSA-PSS, but we've ultimately decided to drop RSA support altogether. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 16 03:55:00 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8A412EB74 for ; Fri, 16 Jun 2017 03:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 8SVhBB9yBaHG; Fri, 16 Jun 2017 03:54:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD3A12EB72; Fri, 16 Jun 2017 03:54:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 16 Jun 2017 10:54:56 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/178#comment:5 Message-ID: <037.41b95d9c40cf12443e0e324f45df3a7b@ietf.org> References: <022.a550ca4084a919cdc9173ec2b964eb58@ietf.org> X-Trac-Ticket-ID: 178 In-Reply-To: <022.a550ca4084a919cdc9173ec2b964eb58@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #178: Add description of how to validate an SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 10:54:58 -0000 #178: Add description of how to validate an SCT -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by rob.stradling@…): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/d04286f962a49c99ae177b053133d9fec8b299be -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 16 04:03:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4A0129B98 for ; Fri, 16 Jun 2017 04:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 wiKobAW4PWxR; Fri, 16 Jun 2017 04:03:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0F129571; Fri, 16 Jun 2017 04:03:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 16 Jun 2017 11:03:17 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/164#comment:3 Message-ID: <037.89429f0d6a6f3256fa3832182df38615@ietf.org> References: <022.cb417955443b987d41bd54530fd8fa72@ietf.org> X-Trac-Ticket-ID: 164 In-Reply-To: <022.cb417955443b987d41bd54530fd8fa72@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #164: Incorporate new protocol mechanisms into TLS Client section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 11:03:19 -0000 #164: Incorporate new protocol mechanisms into TLS Client section -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by rob.stradling@…): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/f5be0a19f384cb19fb95635d9e8377600cc2a594 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 16 04:29:01 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0BD12ECB6 for ; Fri, 16 Jun 2017 04:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 yoWSP7zrTtbi; Fri, 16 Jun 2017 04:28:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78181129B5E; Fri, 16 Jun 2017 04:28:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 16 Jun 2017 11:28:59 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/175#comment:5 Message-ID: <037.35552644bccd165fbb3c9e43c1c104db@ietf.org> References: <022.1197840a8a29deb402e60d707464842f@ietf.org> X-Trac-Ticket-ID: 175 In-Reply-To: <022.1197840a8a29deb402e60d707464842f@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #175: Clarify guarantees around MMD, STH age X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 11:29:00 -0000 #175: Clarify guarantees around MMD, STH age -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by rob.stradling@…): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/afa79c66777f2ca623e2e7939d55ea56fb786a58 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 16 04:38:33 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE64129B6F for ; Fri, 16 Jun 2017 04:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 lzX7y06UgSDN; Fri, 16 Jun 2017 04:38:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43312129B6C; Fri, 16 Jun 2017 04:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 16 Jun 2017 11:38:30 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/174#comment:4 Message-ID: <037.3ef72f06856cac7bb178c8e82f041d8c@ietf.org> References: <022.bc3bdfe661186204aa95d08583fc6798@ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <022.bc3bdfe661186204aa95d08583fc6798@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #174: Remove use of `digitally-signed`? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 11:38:32 -0000 #174: Remove use of `digitally-signed`? -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by rob.stradling@…): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/8d5068f335b5013944e37191fb4cda4cb26cc473 and https://github.com/google/certificate-transparency- rfcs/commit/5abcd60e6d8cd98aabccae827a3e80e6283f5fb5 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 16 04:48:05 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5C12ECB8 for ; Fri, 16 Jun 2017 04:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 lsSQob4joiYA; Fri, 16 Jun 2017 04:48:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83944129B81; Fri, 16 Jun 2017 04:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 16 Jun 2017 11:48:02 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/177#comment:3 Message-ID: <037.cfbe76afc217a6d35b01525c543f7276@ietf.org> References: <022.ecd78ce200156cb980c8ae0ad7efdfbd@ietf.org> X-Trac-Ticket-ID: 177 In-Reply-To: <022.ecd78ce200156cb980c8ae0ad7efdfbd@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #177: Instructions for constructing leaf hash from cert + SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 11:48:04 -0000 #177: Instructions for constructing leaf hash from cert + SCT -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+--------------------------------------------- Changes (by rob.stradling@…): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/d04286f962a49c99ae177b053133d9fec8b299be (which also fixed #178) -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 16 06:19:31 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01BA129C0B for ; Fri, 16 Jun 2017 06:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 tIdiftaWlmqI; Fri, 16 Jun 2017 06:19:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36085129BFC; Fri, 16 Jun 2017 06:19:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 16 Jun 2017 13:19:28 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/79#comment:13 Message-ID: <051.9040fb93eba015776dc1e6918fc41f47@ietf.org> References: <036.276c7af997e3e364d157b87e6cb15496@ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <036.276c7af997e3e364d157b87e6cb15496@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #79: Precertificate signature must be over something other than just the TBSCertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 13:19:30 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate -----------------------------+------------------------------ Reporter: rob.stradling@… | Owner: rob.stradling@… Type: defect | Status: reopened Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------ Changes (by rob.stradling@…): * status: closed => reopened * resolution: fixed => * milestone: review => Comment: I recently took another look at how we're using CMS for precertificates in 6962-bis, and I found myself repeating the same misunderstandings that are documented earlier in this ticket. Therefore, I thought it would be wise to explain the requirements in more detail, drawing particular attention to the RFC5652 requirement that the signedAttrs field MUST be included: https://github.com/google/certificate-transparency-rfcs/pull/264 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Sat Jun 17 19:39:21 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84D1267BB for ; Sat, 17 Jun 2017 19:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 ldN-YejoYSLb; Sat, 17 Jun 2017 19:39:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D911201F2; Sat, 17 Jun 2017 19:39:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Sun, 18 Jun 2017 02:39:18 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/177#comment:4 Message-ID: <037.c9fa885ce94f05280b457192e724730b@ietf.org> References: <022.ecd78ce200156cb980c8ae0ad7efdfbd@ietf.org> X-Trac-Ticket-ID: 177 In-Reply-To: <022.ecd78ce200156cb980c8ae0ad7efdfbd@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #177: Instructions for constructing leaf hash from cert + SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 02:39:19 -0000 #177: Instructions for constructing leaf hash from cert + SCT -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Sat Jun 17 19:39:58 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6E4127076 for ; Sat, 17 Jun 2017 19:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 K2lFMdCTJzbA; Sat, 17 Jun 2017 19:39:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A27D1201F2; Sat, 17 Jun 2017 19:39:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Sun, 18 Jun 2017 02:39:56 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/164#comment:4 Message-ID: <037.fd40bab447add4ce660f7472558eabcd@ietf.org> References: <022.cb417955443b987d41bd54530fd8fa72@ietf.org> X-Trac-Ticket-ID: 164 In-Reply-To: <022.cb417955443b987d41bd54530fd8fa72@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #164: Incorporate new protocol mechanisms into TLS Client section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 02:39:57 -0000 #164: Incorporate new protocol mechanisms into TLS Client section -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Sat Jun 17 19:40:37 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C586D1267BB for ; Sat, 17 Jun 2017 19:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 NGSdoj5qfyzk; Sat, 17 Jun 2017 19:40:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2261201F2; Sat, 17 Jun 2017 19:40:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Sun, 18 Jun 2017 02:40:35 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/174#comment:5 Message-ID: <037.890528e571e0c3e9e5f24fc73025900f@ietf.org> References: <022.bc3bdfe661186204aa95d08583fc6798@ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <022.bc3bdfe661186204aa95d08583fc6798@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #174: Remove use of `digitally-signed`? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 02:40:37 -0000 #174: Remove use of `digitally-signed`? -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Sat Jun 17 19:41:11 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378CB1267BB for ; Sat, 17 Jun 2017 19:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 QPfFIdRroawN; Sat, 17 Jun 2017 19:41:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05ABC1201F2; Sat, 17 Jun 2017 19:41:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Sun, 18 Jun 2017 02:41:10 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/175#comment:6 Message-ID: <037.768f8d2fa09f05b3d8577b6022e97873@ietf.org> References: <022.1197840a8a29deb402e60d707464842f@ietf.org> X-Trac-Ticket-ID: 175 In-Reply-To: <022.1197840a8a29deb402e60d707464842f@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #175: Clarify guarantees around MMD, STH age X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 02:41:11 -0000 #175: Clarify guarantees around MMD, STH age -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Sat Jun 17 19:41:43 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC60B127058 for ; Sat, 17 Jun 2017 19:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 hrSlwRK29ooV; Sat, 17 Jun 2017 19:41:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7EF1201F2; Sat, 17 Jun 2017 19:41:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Sun, 18 Jun 2017 02:41:40 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/178#comment:6 Message-ID: <037.1e64c58a898a7aaad5307ce9ec012ba4@ietf.org> References: <022.a550ca4084a919cdc9173ec2b964eb58@ietf.org> X-Trac-Ticket-ID: 178 In-Reply-To: <022.a550ca4084a919cdc9173ec2b964eb58@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #178: Add description of how to validate an SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 02:41:42 -0000 #178: Add description of how to validate an SCT -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Sat Jun 17 19:42:22 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B491267BB for ; Sat, 17 Jun 2017 19:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=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 NvPMHYXV4Krr; Sat, 17 Jun 2017 19:42:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 404F81201F2; Sat, 17 Jun 2017 19:42:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Sun, 18 Jun 2017 02:42:20 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/189#comment:3 Message-ID: <051.cbd04a1dfd223c19df5348ef3bc34c31@ietf.org> References: <036.0d5f9d9469341d54f42d6a36bef19485@ietf.org> X-Trac-Ticket-ID: 189 In-Reply-To: <036.0d5f9d9469341d54f42d6a36bef19485@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #189: Permit logs to use EdDSA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 02:42:21 -0000 #189: Permit logs to use EdDSA -----------------------------+--------------------------------------------- Reporter: rob.stradling@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: enhancement | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 23 06:43:28 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFDA12EAEF for ; Fri, 23 Jun 2017 06:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 hsENgbSwQvAG; Fri, 23 Jun 2017 06:43:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 154F312EAE4; Fri, 23 Jun 2017 06:43:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 23 Jun 2017 13:43:23 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/176#comment:4 Message-ID: <037.97d57b6fdfc14538bffbd38a21cdeaac@ietf.org> References: <022.a61c2efd583cb5d6d92a69e29e45826a@ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <022.a61c2efd583cb5d6d92a69e29e45826a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #176: Remove `X509ChainEntry` and `PrecertChainEntryV2` X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 13:43:27 -0000 #176: Remove `X509ChainEntry` and `PrecertChainEntryV2` -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by rob.stradling@…): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/8e390389668944420af38056ba66783170b58a71 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 23 06:46:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7180312EAEF for ; Fri, 23 Jun 2017 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 VtYe6vc8aMox; Fri, 23 Jun 2017 06:46:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5861B129B2F; Fri, 23 Jun 2017 06:46:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 23 Jun 2017 13:46:17 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/190#comment:2 Message-ID: <043.2f9d9f91a5572c0fb623fc713176571b@ietf.org> References: <028.ab68de0a691c5c1318c07706fa749a67@ietf.org> X-Trac-Ticket-ID: 190 In-Reply-To: <028.ab68de0a691c5c1318c07706fa749a67@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #190: Simplify data structures in 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 13:46:18 -0000 #190: Simplify data structures in 6962-bis -------------------------+---------------------- Reporter: eranm@… | Owner: eranm@… Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+---------------------- Comment (by rob.stradling@…): PR 256 has been merged (see also #176). Eran wrote... "See if there are any additional data structures that can be removed/simplified or renamed to reflect their true meaning." ...so let's leave this ticket open for now. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 23 08:56:44 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5D126DC2 for ; Fri, 23 Jun 2017 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 lGHUbR7WUrBD; Fri, 23 Jun 2017 08:56:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DEF120726; Fri, 23 Jun 2017 08:56:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 23 Jun 2017 15:56:41 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/176#comment:5 Message-ID: <037.399afe97e9715515139148035ceda2b7@ietf.org> References: <022.a61c2efd583cb5d6d92a69e29e45826a@ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <022.a61c2efd583cb5d6d92a69e29e45826a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #176: Remove `X509ChainEntry` and `PrecertChainEntryV2` X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 15:56:43 -0000 #176: Remove `X509ChainEntry` and `PrecertChainEntryV2` -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 23 17:15:03 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17912EB54; Fri, 23 Jun 2017 17:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ekr@rtfm.com, trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283431.7840.10922095883180868957.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:14 -0700 Archived-At: Subject: [Trans] trans - Requested session has been scheduled for IETF 99 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000 Dear Paul Wouters, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (1:30:00) Wednesday, Afternoon Session II 1520-1650 Room Name: Berlin/Brussels size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Paul Wouters Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ipsecme tls dnsop Second Priority: curdle People who must be present: Eric Rescorla Melinda Shore Paul Wouters Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 29 02:34:32 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3363F12ECED for ; Thu, 29 Jun 2017 02:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 iJYm8UuQqfNO; Thu, 29 Jun 2017 02:34:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835E12ECBC; Thu, 29 Jun 2017 02:34:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 29 Jun 2017 09:34:30 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/160#comment:4 Message-ID: <051.0a99ae39ba6283021915283abcaa6b2c@ietf.org> References: <036.294435e9c2fd7583ffa63bcf96f58873@ietf.org> X-Trac-Ticket-ID: 160 In-Reply-To: <036.294435e9c2fd7583ffa63bcf96f58873@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #160: New get-sths API for fetching all STHs in a given time range X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 09:34:31 -0000 #160: New get-sths API for fetching all STHs in a given time range -----------------------------+------------------------------ Reporter: rob.stradling@… | Owner: rob.stradling@… Type: enhancement | Status: assigned Priority: minor | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------ Changes (by eranm@…): * component: rfc6962-bis => to-be-decided Comment: Changing component to TBD because there was no consensus around adding that, and some consensus around not having it: https://www.ietf.org/mail-archive/web/trans/current/msg02962.html -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu Jun 29 03:08:07 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190FC12EC00 for ; Thu, 29 Jun 2017 03:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 JrpB3pKip75F; Thu, 29 Jun 2017 03:08:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EF612EC01; Thu, 29 Jun 2017 03:08:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 29 Jun 2017 10:08:03 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/79#comment:14 Message-ID: <051.e43c2cc079f53233637803b7b871c824@ietf.org> References: <036.276c7af997e3e364d157b87e6cb15496@ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <036.276c7af997e3e364d157b87e6cb15496@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #79: Precertificate signature must be over something other than just the TBSCertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 10:08:05 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate -----------------------------+------------------------------ Reporter: rob.stradling@… | Owner: rob.stradling@… Type: defect | Status: reopened Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------ Changes (by rob.stradling@…): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/7cba1cc2bfd35cbef7c3e32d6e56ef82759af81a -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu Jun 29 03:24:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F5D12EC00 for ; Thu, 29 Jun 2017 03:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 67--Iv-SOpGC; Thu, 29 Jun 2017 03:24:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CF8129468; Thu, 29 Jun 2017 03:24:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 29 Jun 2017 10:24:17 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/184#comment:3 Message-ID: <037.d5b392b14fa22e487abdbe9681c83760@ietf.org> References: <022.417fe70c3e08d0963a6bfafe9b8a837f@ietf.org> X-Trac-Ticket-ID: 184 In-Reply-To: <022.417fe70c3e08d0963a6bfafe9b8a837f@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #184: Remove unnecessary restrictions on clients X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 10:24:19 -0000 #184: Remove unnecessary restrictions on clients -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+--------------------------------------------- Changes (by eranm@…): * milestone: => review Comment: This was addressed in https://github.com/google/certificate-transparency- rfcs/pull/266 (which was merged after Rob's review: https://github.com/google/certificate-transparency- rfcs/commit/e987be68bbb6a9f787e2e51b1e7c67aa60449e00) As discussed in-person with Richard, section 8.2.8. was removed and the language around compliance was changed to make it clear it is a client policy and clients may require SCTs, inclusion proofs or a combination of both. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu Jun 29 03:32:57 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255A1129468 for ; Thu, 29 Jun 2017 03:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 AY1nVmnHc01G; Thu, 29 Jun 2017 03:32:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22426127876; Thu, 29 Jun 2017 03:32:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 29 Jun 2017 10:32:55 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/190#comment:3 Message-ID: <043.bdb67442b2c013fe9c9c7b6b2fc4b25a@ietf.org> References: <028.ab68de0a691c5c1318c07706fa749a67@ietf.org> X-Trac-Ticket-ID: 190 In-Reply-To: <028.ab68de0a691c5c1318c07706fa749a67@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #190: Simplify data structures in 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 10:32:56 -0000 #190: Simplify data structures in 6962-bis -------------------------+---------------------- Reporter: eranm@… | Owner: eranm@… Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+---------------------- Changes (by eranm@…): * milestone: => review Comment: I think this could be now closed. We've removed what can be removed, made it clear that implementations can store data the way they see fit as long as the submission structure can be recreated and IMHO the names of the remaining data structures have sensible names. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu Jun 29 05:06:42 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A306D12EC0F for ; Thu, 29 Jun 2017 05:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 xzuNIpPyhdwD; Thu, 29 Jun 2017 05:06:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A06681204DA; Thu, 29 Jun 2017 05:06:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 29 Jun 2017 12:06:40 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/162#comment:4 Message-ID: <037.2211360a810bc63e9c2033b2e56cd326@ietf.org> References: <022.7212bc2ce646972ebd8eb69407a1fe1b@ietf.org> X-Trac-Ticket-ID: 162 In-Reply-To: <022.7212bc2ce646972ebd8eb69407a1fe1b@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #162: Bound the set of artifacts a log is expected to produce X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 12:06:42 -0000 #162: Bound the set of artifacts a log is expected to produce -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * milestone: => review Comment: The 2nd suggestion was implemented by Rob in https://github.com/google /certificate-transparency-rfcs/pull/267 I think this is enough to defer handling the bigger idea of a "Strict CT" variant in a separate document. Setting milestone to review for the chairs to either close this issue or move it to the 'to-be-decided' component. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu Jun 29 10:10:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC03C12EC66 for ; Thu, 29 Jun 2017 10:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 DibpumUUK9TV; Thu, 29 Jun 2017 10:10:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A824129B5E; Thu, 29 Jun 2017 10:10:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 29 Jun 2017 17:10:49 -0000 X-URL: Message-ID: <032.fcc41ab2d5bb35f8a3b742ab5df4deb2@ietf.org> Archived-At: Subject: [Trans] [Public Notary Transparency Wiki] Batch modify: #79, #162, #190, #184 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 17:10:51 -0000 Batch modification to #79, #162, #190, #184 by melinda.shore@gmail.com: Action: resolve -- Tickets URL: Public Notary Transparency Wiki My example project From nobody Fri Jun 30 15:15:05 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B005D126E3A; Fri, 30 Jun 2017 15:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149886090365.422.7228956540800801462@ietfa.amsl.com> Date: Fri, 30 Jun 2017 15:15:03 -0700 Archived-At: Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-25.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 22:15:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Certificate Transparency Version 2.0 Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-25.txt Pages : 54 Date : 2017-06-30 Abstract: This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-25 https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/