Re: [Trans] Precertificate format

Rob Stradling <rob.stradling@comodo.com> Wed, 10 September 2014 10:31 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 044261A06DA for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 03:31:09 -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 GNOdJM34l9S1 for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 03:31:06 -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 E1B2B1A0678 for <trans@ietf.org>; Wed, 10 Sep 2014 03:31:05 -0700 (PDT)
Received: (qmail 8742 invoked by uid 1000); 10 Sep 2014 10:31:02 -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; Wed, 10 Sep 2014 11:31:02 +0100
Message-ID: <54102866.8070200@comodo.com>
Date: Wed, 10 Sep 2014 11:31:02 +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: "trans@ietf.org" <trans@ietf.org>
References: <540DFA75.2040000@gmail.com><540ED39C.5040308@comodo.com> <CAFewVt7NivPuSzcUL=mM=6mKauznrcb+gPHgpw5myhfZUO-eEg@mail.gmail.com>
In-Reply-To: <CAFewVt7NivPuSzcUL=mM=6mKauznrcb+gPHgpw5myhfZUO-eEg@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/ZmEpV9Fpd_3lCnln00Isk-jFQFk
Cc: Melinda Shore <melinda.shore@gmail.com>, Brian Smith <brian@briansmith.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: Wed, 10 Sep 2014 10:31:09 -0000

On 09/09/14 21:15, Brian Smith wrote:
> On Tue, Sep 9, 2014 at 3:17 AM, Rob Stradling <rob.stradling@comodo.com> wrote:
>> I don't mind us adding an alternative Precertificate format to 6962-bis (if
>> we can agree on a suitable format!), but I'd also like to retain the RFC6962
>> Precertificate format as an option.
>
> If the old form is acceptable, then there would be no point in
> defining a new form. The chief issue is that technically the old form
> of precertificate is technically a certificate, and since it has the
> same issuer name it must (according to RFC 5280) have a different
> serial number. It would be good for the group to decide whether or not
> that issue is so bad that we cannot accept it.

Chairs,

Do we have the option of keeping the existing Precertificate format, 
such that once 6962-bis becomes a standards track RFC it would violate 
the serial number uniqueness rule in the RFC5280?
Or, does the IETF process absolutely require that we don't violate any 
rules in existing standards track RFCs?

> If it is that bad, it makes sense to define a replacement format. If it isn't
> so bad that we can't accept it, then it doesn't make sense to define a
> replacement format, IMO.

Brian,

Unless it turns out that there is no single format that all CAs are able 
to use, I agree.

>> Several CAs have already deployed code to generate RFC6962 Precertificates.
>> Why force these CAs to change to a different format just because some other
>> CAs find it hard to implement the RFC6962 format?
>
> If the only issue is whether it is a little bit tricky to implement
> the X.509-certificate form of precertificate, then there's no point in
> defining a new format. CAs always have the non-precertificate
> mechanism to fall back on.
>
> IMO, the ultimate goal should be to get the non-precertificate
> mechanisms working well enough that we can remove (or at least
> deprecate) the precertificate mechanism completely.

I'm not convinced that this should be the ultimate goal.  A benefit of 
the Precertificate mechanism is that the certificate holder doesn't need 
to worry about configure their TLS Server for CT, because the CA has 
already taken care of the CT stuff for them.

Also, out of scope for 6962-bis but in scope for discussion on this list...
Precertificates could be useful if/when we extend CT to Code Signing 
certificates, S/MIME certificates, etc, but the RFC6962 TLS Extension 
won't be useful in these contexts.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online