Re: [Trans] Precertificate format

Brian Smith <brian@briansmith.org> Tue, 09 September 2014 19:56 UTC

Return-Path: <brian@briansmith.org>
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 9B07D1A01D8 for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 12:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 AWrvGH0QY1Sr for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 12:56:12 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4520C1A019B for <trans@ietf.org>; Tue, 9 Sep 2014 12:56:12 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id j5so4586030qga.8 for <trans@ietf.org>; Tue, 09 Sep 2014 12:56:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z1gt35fk+6qglYLGBAO89HJ5Zl+vV4Z9FFfNi0qThn8=; b=lhwx2IFAtqFXNwBBCaVZErwnIoePlQ3o0FH8PGO0id2zYpR1diB15G4MwsXTeGptLq oF1Ka9KfxKkcgjRLWzYiUnNI4x7hKYaMnObhSxUqF418A5hZxuYx/LlMawE2Rq5LxKuC XKJV5jzDdfVooPeWyZPav9Wbbu766WLlUZnDJwZ5l6Bf5mYwn7vDjNyUDsYhXfq2fy3v 279QfC36lm/gjHhqG1k49hVJUhXUgPr1QEkn60bVQGk7g0lqMZoIk83i2P2gbjNE2rmo ATNVV/JA08XCCOYvhunFjyGhUT36SbJFE91F577uK6MFt/81bTCaPQN7Zn7Q5feUaW1W fFZA==
X-Gm-Message-State: ALoCoQkN9gU1k6c8N3oE4A7j2Fw4pPJrirtTbkzYRJyjwYPsA19QXeLsepvJ90HRDOnldYQpZdH1
MIME-Version: 1.0
X-Received: by 10.140.81.134 with SMTP id f6mr52431486qgd.60.1410292571366; Tue, 09 Sep 2014 12:56:11 -0700 (PDT)
Received: by 10.224.67.133 with HTTP; Tue, 9 Sep 2014 12:56:11 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <CAFewVt5kZqw0-W7PqtFHe7yJUsR9PqVJ6C74ZShgo0qs19wLjA@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Tue, 09 Sep 2014 12:56:11 -0700
Message-ID: <CAFewVt4FpwpXhcrW0mM6atASBh6k9jDb3DCCsDBNppJBrkjwXQ@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Rick Andrews <Rick_Andrews@symantec.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ou7n1Fc6Gq8e4OIM1j8eXBs65yM
Cc: "trans@ietf.org" <trans@ietf.org>, Stephen Kent <kent@bbn.com>
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: Tue, 09 Sep 2014 19:56:13 -0000

On Mon, Sep 8, 2014 at 4:24 PM, Rick Andrews <Rick_Andrews@symantec.com> wrote:
>> The CA may use a Precertificate Signing Certificate to sign the Precertificate, and then sign the final certificate with the production CA certificate. Then, there would be no duplicate serial number issues.
>
> Brian, even if the CA uses a Precert signing cert, the precert's issuer name has to be that of the ultimate issuer, and the serial number has to be that of the ultimate certificate, so I don't think that solves the problem.

Thanks for pointing that out. Basically, the cause of that problem is
that a Precertificate is a syntactically-valid X.509 certificate, and
so it could be considered a duplicate of the final certificate. If the
Precertificate weren't a syntactically-valid X.509 certificate, then
there would be no way it could be considered a duplicate. So, why not
make this simple change to the syntax:

enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;

  struct {
    LogEntryType entry_type;
    select (entry_type) {
      case x509_entry: ASN.1Cert;
      case precert_entry: ASN.1Precert;
    } entry;
    ASN.1Cert certificate_chain<0..2^24-1>;
  } LogEntry;

  opaque ASN.1Cert<1..2^24-1>;
  opaque ASN.1Precert<1..2^24-1>;

where the internal syntax of ASN.1Precert is (in ASN.1):

  ASN1Precert ::=  SEQUENCE  {
    precertSigningCert [0] EXPLICIT OptionalCertificate,
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue BIT STRING }

  OptionalCertificate ::= certificate Certificate OPTIONAL;

In other words, ASN1Precert is exactly an X.509 Certificate except
that it starts with an explicitly-tagged, possibly-empty
precertSigningCert field. Thus, no X.509 certificate parser would
parse a precert as though it were a real certificate, and so the
precert could never be considered a duplicate of the final cert.
Additionally, there would be no need for the "poison extension"
because the added precertSigningCert field serves the same purpose.

This strawman only attempts to solve the "duplicate certificate"
problem, not the "must reserve the serial number in advance" problem.
However, I suspect that this change would make it more difficult for
some CAs to create precertificates.

Cheers,
Brian