Re: [Trans] Precertificate format

Brian Smith <brian@briansmith.org> Tue, 09 September 2014 20:15 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 39B7A1A01F1 for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 13:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 tGl5TpuAT5aL for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 13:15:23 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895ED1A01EF for <trans@ietf.org>; Tue, 9 Sep 2014 13:15:23 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id i8so18041138qcq.22 for <trans@ietf.org>; Tue, 09 Sep 2014 13:15:22 -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=PlOJH+ZH7lqueVvPXnOBoX4i85OdCKNYRi02vyP7zBk=; b=X4U0JTqS7ftGXzJaQeFssCORRtnCI0AFxid+PG5/f9rRcCS6b2R9yyoBcXlI4ljA72 o19LwvD5IpvfB1HC86sl37kql+iQeSQUT5QRc1yPqb9QeDH5R6BwKenJTHBOPP6LQdMV H2J43wggVpoidl0/LvNT6aUCpP6qVoqQeOyly6jkpGHO44FhePhK//rP9+4Z0rsb00Bp I28Ir5u4E3cKqLuHxKrN8M7ayRy8kNlKCzLGsttVk5rP8ZZIA33qbeM+40hmD4VPP2fs fK9npyF5nQwRVYobQbkaW3SsxpJcjFJMBY4bJputHVRe4QQ6Y7488X3b852ut22m2wcB KlPQ==
X-Gm-Message-State: ALoCoQmaEKC7Y3rHAUKxeOVTRuNpYfsjXhVSRe491m+TI4gICin+9WL6UaHjv333GQo+ynBRxJms
MIME-Version: 1.0
X-Received: by 10.140.107.198 with SMTP id h64mr51715448qgf.42.1410293722631; Tue, 09 Sep 2014 13:15:22 -0700 (PDT)
Received: by 10.224.67.133 with HTTP; Tue, 9 Sep 2014 13:15:22 -0700 (PDT)
In-Reply-To: <540ED39C.5040308@comodo.com>
References: <540DFA75.2040000@gmail.com> <540ED39C.5040308@comodo.com>
Date: Tue, 09 Sep 2014 13:15:22 -0700
Message-ID: <CAFewVt7NivPuSzcUL=mM=6mKauznrcb+gPHgpw5myhfZUO-eEg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Rob Stradling <rob.stradling@comodo.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QQ-CoJqKB7WWX_uXtp-wJftpDwk
Cc: Melinda Shore <melinda.shore@gmail.com>, "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: Tue, 09 Sep 2014 20:15:25 -0000

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. 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.

> 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.

Cheers,
Brian