On Feb 26, 2014 7:48 AM, "Tomas Gustavsson" <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
