Re: [Trans] Alternate formats for Precertificates
Tomas Gustavsson <tomas@primekey.se> Wed, 26 February 2014 16:31 UTC
Return-Path: <tomas@primekey.se>
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 08ABA1A04B6 for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 08:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 ef-MMdKX7x4l for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 08:31:17 -0800 (PST)
Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id B7FFB1A00FB for <trans@ietf.org>; Wed, 26 Feb 2014 08:31:12 -0800 (PST)
Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 7012745C00CD for <trans@ietf.org>; Wed, 26 Feb 2014 17:32:26 +0100 (CET)
Received: from [192.168.1.107] (c-50-184-94-125.hsd1.ca.comcast.net [50.184.94.125]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 07DAC45C00B8 for <trans@ietf.org>; Wed, 26 Feb 2014 17:32:25 +0100 (CET)
Message-ID: <530E16CD.6030908@primekey.se>
Date: Wed, 26 Feb 2014 08:31:09 -0800
From: Tomas Gustavsson <tomas@primekey.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: trans@ietf.org
References: <CABrd9SSOmEgbTvLNw5bPN2SnKbob800qEecn+tHvZUkrghFcQg@mail.gmail.com> <530E100A.7040503@primekey.se> <530E142A.90007@comodo.com>
In-Reply-To: <530E142A.90007@comodo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/SWrMNRXAZWxjJnKYTM3vOV9Nfiw
Subject: Re: [Trans] Alternate formats for Precertificates
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, 26 Feb 2014 16:31:26 -0000
On 02/26/2014 08:19 AM, Rob Stradling wrote: > On 26/02/14 16:02, Tomas Gustavsson wrote: >> On 02/26/2014 07:30 AM, Ben Laurie wrote: >>> On 26 February 2014 14:13, Tomas Gustavsson <tomas@primekey.se> wrote: >>>> >>>> Did anyone consider using RFC4211 CRMF requests as "pre-certificates"? >>>> CRMF has both issuer and serialNumber, as well as extensions. The >>>> CertTemplate of RFC4211 is basically a TBSCertificate. >>> >>> Hmm. So it is. I had not come across this RFC before. >>> >>> Does anything implement it? >> >> Absolutely. It is used in CMP (RFC4210). EJBCA has had support for it as >> a request format for years, so we have code for both producing and >> parsing of course. >> >> BouncyCastle has Java APIs for CMP/CRMF. >> http://www.bouncycastle.org/ >> >> cmpforopenssl supports it I believe, C API and command line. >> http://sourceforge.net/apps/mediawiki/cmpforopenssl/index.php?title=Main_Page >> >> >> >> I don't know why I did not think of this earlier, since I use it all the >> time. CMP with CRMF is used in many systems in production. Card >> management, LTE base stations (3GPP standardization), some routers etc. >> >> Re-using existing RFC always feels good :-) > > RFC4211 says: > "The fields of CertRequest have the following meaning: > ... > serialNumber MUST be omitted. This field is assigned by the CA > during certificate creation. > > signingAlg MUST be omitted. This field is assigned by the CA > during certificate creation." > > So that's two ways we would need to violate RFC4211 in order to use its > CertTemplate format for Precertificates. Seems like very minor violations to me. In addition using CRMF would remove the need for the poison certificate extension. CRMF also gives more flexibility as you (RFC 6962 that is) can choose which fields to include and/or exclude, potentially answering to questions like privacy issues and such. > > In contrast, allowing a Precertificate/Certificate pair to use the same > serial number only violates RFC5280 in one way. (Oh, and to me, reusing > the TBSCertificate format feels good too! ;-) )
- [Trans] Alternate formats for Precertificates Ben Laurie
- Re: [Trans] Alternate formats for Precertificates Phillip Hallam-Baker
- Re: [Trans] Alternate formats for Precertificates Tomas Gustavsson
- Re: [Trans] Alternate formats for Precertificates Goulet, Walter
- Re: [Trans] Alternate formats for Precertificates Rob Stradling
- Re: [Trans] Alternate formats for Precertificates Tomas Gustavsson
- Re: [Trans] Alternate formats for Precertificates Ben Laurie
- Re: [Trans] Alternate formats for Precertificates Tomas Gustavsson
- Re: [Trans] Alternate formats for Precertificates Paul Hoffman
- Re: [Trans] Alternate formats for Precertificates Carl Wallace
- Re: [Trans] Alternate formats for Precertificates Paul Hoffman
- Re: [Trans] Alternate formats for Precertificates Carl Wallace
- Re: [Trans] Alternate formats for Precertificates Melinda Shore
- Re: [Trans] Alternate formats for Precertificates Robin Alden
- Re: [Trans] Alternate formats for Precertificates Rob Stradling
- Re: [Trans] Alternate formats for Precertificates Rob Stradling
- Re: [Trans] Alternate formats for Precertificates Tomas Gustavsson