Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer keyhash into the Precertificate
Rob Stradling <rob.stradling@comodo.com> Fri, 03 July 2015 14:32 UTC
Return-Path: <rob.stradling@comodo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E84B1A1A02 for <trans@ietfa.amsl.com>; Fri, 3 Jul 2015 07:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMdVjhT5DUKJ for <trans@ietfa.amsl.com>; Fri, 3 Jul 2015 07:32:29 -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 51E681A03FF for <trans@ietf.org>; Fri, 3 Jul 2015 07:32:25 -0700 (PDT)
Received: (qmail 1902 invoked by uid 1004); 3 Jul 2015 14:32:23 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 03 Jul 2015 15:32:23 +0100
Received: (qmail 15053 invoked by uid 1000); 3 Jul 2015 14:32:23 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 03 Jul 2015 15:32:23 +0100
Message-ID: <55969CF7.9040305@comodo.com>
Date: Fri, 03 Jul 2015 15:32:23 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>, trans issue tracker <trac+trans@tools.ietf.org>, benl@google.com
References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org><071.ac1382a23021309632a3cfb2c9ac8ce0@tools.ietf.org> <559543E1.6010501@bbn.com>
In-Reply-To: <559543E1.6010501@bbn.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/8m2N9q4KlYQwHrGa5nzXU6sqTc4>
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer keyhash into the Precertificate
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2015 14:32:33 -0000
On 02/07/15 15:00, Stephen Kent wrote: > Rob, Hi Steve. > I agree with your conclusoon that inclusion of the issuer public key hash > will enable a browser to verify the correspondence between an SCT without > interacting with a log. Even though we don't yet have a browser behavior > spec, I agree that this is a good candidate behavior to enable. > > Do you propose this as an extension to the current SCT format, or a change > to the format? A change to the format. Proposal here: https://github.com/google/certificate-transparency-rfcs/pull/58 > If you propose a change, then I'll argue that my proposed > cert type declaration and checks performed fields also should be included, > since we'll be making a not backward compatible change to the SCT. 6962-bis has already made backwards-incompatible changes to RFC6962 SCT v1. > If this is an (optional) extension, then I guess my proposed fields can be > the second and third extensions defined. I think that required fields should be in the main part of the SCT structure, whilst optional fields should be extensions. IINM, we agreed a while ago that your proposed fields (cert type declaration and checks performed) would be, at most, optional. (I still think that it makes more sense for monitors, not logs, to perform checks relating to the declared cert type). > Steve >> #80: Re-introduce the issuer key hash into the Precertificate >> >> >> Comment (by rob.stradling@comodo.com): >> >> This problem affects browser clients and any other client that wants to >> verify that an SCT corresponds to a particular cert. A browser has the >> full cert chain (from the TLS handshake) and the corresponding SCTs, >> but >> it is _not_ expected to have the full log entries (i.e. extra_data, >> etc). >> >> In the current text, the SCT is bound to the Issuer Name (because >> that's >> in the TBSCertificate), but not to the Issuer Key (because that's >> not in >> the TBSCertificate). >> >> There could exist two or more publicly-trusted intermediate CA certs >> with >> the same Name but different Keys. One of those intermediates might be >> logged, while the other(s) are not logged. Each of them could issue >> leaf >> certs that have an identical TBSCertificate. Only one of those leaf >> certs >> needs to be logged for there to exist SCT(s) that are valid for all of >> those leaf certs. >> >> The logged leaf cert might get revoked, but the other(s) might not get >> revoked. However, the SCT(s) would still work for all of those certs, >> including the non-logged ones. >> >> Therefore, we need to fix SCTs so that they're bound to the Issuer Key >> Hash as well as the Issuer Name. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
- [Trans] [trans] #80 (client-behavior): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… Stephen Kent
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… Rob Stradling
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker
- Re: [Trans] [trans] #80 (rfc6962-bis): Re-introdu… trans issue tracker