Re: [Trans] Precertificate format

Erwann Abalea <eabalea@gmail.com> Fri, 12 September 2014 19:27 UTC

Return-Path: <eabalea@gmail.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 2F24B1A8763 for <trans@ietfa.amsl.com>; Fri, 12 Sep 2014 12:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJFnvosWekjb for <trans@ietfa.amsl.com>; Fri, 12 Sep 2014 12:27:46 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFD81A86E2 for <trans@ietf.org>; Fri, 12 Sep 2014 12:26:58 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id hy10so1193799vcb.3 for <trans@ietf.org>; Fri, 12 Sep 2014 12:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g6meLqlZPgfSzS5j6GfbHR8w6A+qCTS2kJcXDkKB+So=; b=ovP4HPHsHgDTb7lMIexF3elPZEP8PItn44ojWl41QbQuRKcFY+D/nafW9u+zEgWyjG vk1B4qDaP8mXGdOn5cIcWlawgyCSE9d/XhTlyGnerJaC04RCqbiFE1S98jbJqAzGWoui qjoW3X6smo0TOBUE6TTa5hP0XMxCKMr3Qi/4XOB8Kj0KBp1xVsimDkFgKwnAIQy0bH16 284kGbLRc2zDwSuHwETeOV2FD6OGv8ekV54m3Haq9sW6wz8ksDfy94qVThFUL4uAJEYS DZb4vzraF0ymqmksC/KlnhxciV7ilsUyoeoO7tW2pCBEx6SpkGxFu2LLeHMx6N7lle0o htzg==
MIME-Version: 1.0
X-Received: by 10.52.117.238 with SMTP id kh14mr2739232vdb.91.1410550016147; Fri, 12 Sep 2014 12:26:56 -0700 (PDT)
Received: by 10.52.241.4 with HTTP; Fri, 12 Sep 2014 12:26:56 -0700 (PDT)
In-Reply-To: <02c365fdc2b8478fb78f310382ae0bb7@EX2.corp.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>
Date: Fri, 12 Sep 2014 21:26:56 +0200
Message-ID: <CA+i=0E4bKzn6DB73H7p8k+kDyrku54WhU5ZFcA2g5zY69Kn-Hg@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Jeremy Rowley <jeremy.rowley@digicert.com>
Content-Type: multipart/alternative; boundary=bcaec547c813a6ab310502e34457
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/d8RKooaPmnmrPZEdb_mlMf8Q6fc
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: Fri, 12 Sep 2014 19:27:49 -0000

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?).
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>om>:

> 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] On Behalf Of Stephen Kent
> Sent: Thursday, September 11, 2014 12:15 PM
> To: 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
> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>



-- 
Erwann.