Re: [Trans] Precertificate format
Rob Stradling <rob.stradling@comodo.com> Mon, 15 September 2014 09: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 1DDB81A0714 for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 02:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CndgxH68o4w for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 02:32:09 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AA11A0704 for <trans@ietf.org>; Mon, 15 Sep 2014 02:32:08 -0700 (PDT)
Received: (qmail 14926 invoked by uid 1000); 15 Sep 2014 09:32:06 -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; Mon, 15 Sep 2014 10:32:06 +0100
Message-ID: <5416B216.6050904@comodo.com>
Date: Mon, 15 Sep 2014 10:32:06 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Erwann Abalea <eabalea@gmail.com>, Jeremy Rowley <jeremy.rowley@digicert.com>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com><540E28FD.7050809@gmail.com> <540ECD3A.4040704@primekey.se><540F4598.5010505@bbn.com><CABrd9SSg5=wuierLoqAU00pMHxgGx+=ai5mHv4u5t6zm43yDWg@mail.gmail.com><5410779A.20209@bbn.com><CABrd9STnjqDBF4-5ABJ86M_d0bwRyjRNjRW6Hnj9UpeYC7Xz9A@mail.gmail.com><5411BDE4.1060508@bbn.com><CABrd9STAHzg_KJi=nA7hsvz+k0SMS+bg6c3hcBtUwfOUm=hqTQ@mail.gmail.com><5411E6B4.5040401@bbn.com><02c365fdc2b8478fb78f310382ae0bb7@EX2.corp.digicert.com> <CA+i=0E4bKzn6DB73H7p8k+kDyrku54WhU5ZFcA2g5zY69Kn-Hg@mail.gmail.com>
In-Reply-To: <CA+i=0E4bKzn6DB73H7p8k+kDyrku54WhU5ZFcA2g5zY69Kn-Hg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/XNe7HMkAkUX8Cl2xU7Nt2bQnXXk
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Precertificate format
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Sep 2014 09:32:13 -0000
On 12/09/14 20:26, Erwann Abalea wrote: > Nice idea, solves the RFC5280 concerns, and doesn't require a completely > new data structure. > > IIUC, what you propose is that the PreCert is a CMS (RFC5652) with a > signedData content-type, for which the data is the TBSCertificate > (name-redacted or not, no necessary poison extension). The SignerInfo > refers to the PreCert issuer (CA or dedicated issuer, same as now). > > It can only work if the log signs the content (=TBSCertificate) and not > the whole CMS, thus ignoring the PreCert issuer signature. Leaving that > signature aside isn't more risky than it is now because it's already the > case (the log removes the poison extension before signing the resulting > certificate, right?). Yes. The log removes the poison extension, and (if a Precertificate Signing Certificate was used) it also changes the issuer name and AKI to match those of the final certificate's issuing CA. This behaviour can remain the same. I agree that using CMS to sign the Precert TBSCertificate is a good solution to the duplicated certificate serial number problem. :-) > If the log signs the whole CMS, the SCT covers information unknown to > the browser at connection time (content of SignerInfo, maybe additional > attributes --authenticated or not--, digest algorithm chosen by the > PreCert issuer, etc). > > > 2014-09-12 20:44 GMT+02:00 Jeremy Rowley <jeremy.rowley@digicert.com > <mailto:jeremy.rowley@digicert.com>>: > > Why not use a TBSCertificate from RFC 5280 with no modifications > from the final certificate (no poison extension) and sign it with a > PKCS7 signature instead of a RFC 5280 signature? By doing this you > are not creating a valid certificate so you are not technically > breaking RFC 5280 (re-using serial numbers) and it couldn't be used > as a certificate even if some software incorrectly ignored the > poison extension. > > Jeremy > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org > <mailto:trans-bounces@ietf.org>] On Behalf Of Stephen Kent > Sent: Thursday, September 11, 2014 12:15 PM > To: trans@ietf.org <mailto:trans@ietf.org> > Subject: Re: [Trans] Precertificate format > > Ben, > > > ... > > I managed to miss that proposal. I've found it now. > > > > There seems to be a flaw: if I'm an evil CA wishing to issue an evil > > certificate, I simply log a precert, minus serial, get an SCT*, log a > > certificate containing that SCT*, which I then revoke when requested > > to do so, > > > > In order to attack a user with the evil certificate, I simply issue a > > second copy with a different serial, containing the original > SCT*, and > > the certificate works. Yes, the discrepancy should be discovered in > > audit, but that is a significantly weaker protection than we get if > > the serial is included in the pre-certificate. > I agree that the attack you describe would work, but it needs to be > evaluated in the overall context of how CT works in the case of > several different types of attack scenarios. The threat model and > attack model text I just submitted provides a first cut at > describing such scenarios. Once we get agreement on that model, > let's revisit the question of whether the vulnerability you noted > above is significant relative to other residual vulnerabilities. > > Also this adds quite a lot of complexity in order to allow what > > appears to be, so far, an entirely theoretical use case. > I do know that when VeriSign used the Safekeyper HSM to issue all of > its certs (which it did for several years), it would have been > impossible to generate a pre-cert and matching final cert. So, the > concern I raise would have been a show stopper for them in that time > frame. I guess it depends on how one defines a "theoretical use > case" :-) > > Separately, the pre-cert model, requires a CA to issue two certs > with the same serial number, which is a bad security practice. I > think it makes sense to re-consider forcing CAs to behave this way. > > Steve > > _______________________________________________ > Trans mailing list > Trans@ietf.org <mailto:Trans@ietf.org> > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > Trans@ietf.org <mailto:Trans@ietf.org> > https://www.ietf.org/mailman/listinfo/trans > > > > > -- > Erwann. > > > _______________________________________________ > 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] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Rick Andrews
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Matt Palmer
- Re: [Trans] Precertificate format Matt Palmer
- Re: [Trans] Precertificate format Eran Messeri
- Re: [Trans] Precertificate format Tomas Gustavsson
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Carl Wallace
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Kyle Hamilton
- Re: [Trans] Precertificate format Watson Ladd
- Re: [Trans] Precertificate format Tomas Gustavsson
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Jeremy Rowley
- Re: [Trans] Precertificate format Erwann Abalea
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Erwann Abalea
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Erwann Abalea
- [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Stephen Davidson
- Re: [Trans] Precertificate format Ben Laurie
- [Trans] Fwd: Precertificate format Erwann Abalea
- Re: [Trans] Fwd: Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Russ Housley
- Re: [Trans] Precertificate format Rob Stradling