Re: [Trans] Alternate formats for Precertificates

[Tomas Gustavsson <[e-mail]>]

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 <[e-mail]> 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! ;-) )