Re: [Trans] Alternate formats for Precertificates

On 26 February 2014 16:31, Tomas Gustavsson <tomas@primekey.se> wrote:
>
> 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.

We're only discussing alternatives to avoid breaking ritual compliance
with the RFC, so selecting another one we have to violate hardly seems
like forward motion.

>
>
>>
>> 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 mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans