Re: [Trans] Precertificate format

Watson Ladd <watsonbladd@gmail.com> Wed, 10 September 2014 01:25 UTC

Return-Path: <watsonbladd@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 574BE1A045E for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 18:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_37=0.6, 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 0c8G8EsfrP_o for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 18:25:38 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0EA1A0418 for <trans@ietf.org>; Tue, 9 Sep 2014 18:25:37 -0700 (PDT)
Received: by mail-yk0-f176.google.com with SMTP id 131so2096609ykp.7 for <trans@ietf.org>; Tue, 09 Sep 2014 18:25:37 -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=MX7Y6iysUSL3SU7VyfQVGK2Ufaqa/9u/fAr9KBYjo0U=; b=YTXGaJvc1EJiHctm89soytFVb1HF2LWmGwVPJ5Lt7STd17MbzhOKtaABmTRGNHyN9d bP3M+PqOSrZcZ6OHKkUjhmfF1LXhGmSBF7nJ4P3qW+N7VWLQUIHZJJ1ir5tXplf5KNYN tnIhQdW+6q0UsiE1vcM21Ko2Y7FZ+259GFoAnM6NAfBeoQCGZ8FKJX1vXVStRq7Qv5wk woN+JMYRhrEfbiLaOblfMQqnQ0IwnbWh1/7zL6vN7yz1UJRl/6BoAgPdx2rYgPKDuoNh 737B+0qcOkx2yOPfgZbYK/I1MbXbWcFcEYYtQaVSV1jfQxc4MkSawry6N7BAe/E+jad6 uJVg==
MIME-Version: 1.0
X-Received: by 10.236.207.73 with SMTP id m49mr57647952yho.90.1410312337217; Tue, 09 Sep 2014 18:25:37 -0700 (PDT)
Received: by 10.170.207.216 with HTTP; Tue, 9 Sep 2014 18:25:37 -0700 (PDT)
In-Reply-To: <4c67a3bd-ff97-43d3-8e1f-449954b59f02@email.android.com>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <CAFewVt5kZqw0-W7PqtFHe7yJUsR9PqVJ6C74ZShgo0qs19wLjA@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CAFewVt4FpwpXhcrW0mM6atASBh6k9jDb3DCCsDBNppJBrkjwXQ@mail.gmail.com> <4c67a3bd-ff97-43d3-8e1f-449954b59f02@email.android.com>
Date: Tue, 9 Sep 2014 18:25:37 -0700
Message-ID: <CACsn0ckPm2k9q-aFZJPJLBNVXSwa_KS-pjdXDj6UU4VRGttsSw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Kyle Hamilton <aerowolf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rH8Z_S4Bh6lcywWmh1ej9o9-2y4
Cc: "trans@ietf.org" <trans@ietf.org>, Brian Smith <brian@briansmith.org>, Rick Andrews <Rick_Andrews@symantec.com>, 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: Wed, 10 Sep 2014 01:25:40 -0000

On Tue, Sep 9, 2014 at 4:40 PM, Kyle Hamilton <aerowolf@gmail.com> wrote:
> I think the best way to change a Certificate into a Precertificate would be
> to alter the first field of the tbsCertificate to be non-optional and
> explicitly tagged as something other than tag [0]. Then, reconstruct the
> actual tbsCertificate by changing the first field to tag [0], perform any
> other necessary edits (like, for name redaction), re-encode the
> validly-tagged tbsCertificate to DER, and digest the encoded data.

Let's back up a bit: we want to ensure that the certificate chains
browsers use are a matter of public record. To do this we need to
record the chain in a log, and give the server back a way to prove
"yes, we've seen this chain" from the log. What I don't understand
here is the role of the CA and the Precertificate in this process.

Sincerely,
Watson Ladd
>
> But, I also proposed (a few years ago) a way to include an issued
> certificate list in a CRL extension to mitigate the Diginotar-style "we
> didn't know it had been issued" problem, and to be able to feed CRL-based
> OCSP responders with a minimum of code changes. That didn't go anywhere, and
> I expect this suggestion to go nowhere as well.
>
> -Kyle H
>
> On September 9, 2014 12:56:11 PM PST, Brian Smith <brian@briansmith.org>
> wrote:
>>
>> 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
>>
>> ________________________________
>>
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin