Re: [Trans] Alternate formats for Precertificates

On Feb 26, 2014 7:48 AM, "Tomas Gustavsson" <tomas@primekey.se> wrote:
>
>
> <snip>
>
>
>>>>>
>>>>> 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.
>
>
> Just bringing some more alternatives to the table.
> I'm sure modifying RFC4211 is easier than modifying RFC5280 ;-)

(Apologies for the crispy formatting, I'm typing on a phone).  Anyway, that
would be essentially correct - there are issues around thongs like deployed
base, and how much would or could break as a result.  These are the sorts
of questions for which "ritual compliance" is unhelpful language.
>
>
>
>>>
>>>>
>>>> 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