<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 ;-)
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