>Recognition of the fact that PKCS #10 does not support X.509 v3 is what drove
>PKIX to develop the Certificate Request Message Format (CRMF), which includes
>every X.509 v3 certificate field. As VeriSign and Entrust were co-authors of
>the CRMF specification, one might expect it to become widely supported. Can
>the same be said for agreement on a specific ad-hoc method of stretching
>PKCS#10?
At the moment CRMF has three major problems:
1. Noone uses it (I know that that'll change in the future, but it doesn't help
encourage implementors at the moment).
2. Pieces of it may be covered by Nortel/Entrust stealth patents, requiring
major restructuring to avoid them.
3. It has some underspecified and downright bizarre fields in there - what the
purpose of allowing a subject to specify a CA's DN is is beyond me. It
looks like they've taken every possible X.509 field (including ones which
are obsolete or deprecated or make absolutely no sense in a cert request),
stuck a tag in front of them, and added them to the message.
Once you strip out all the unnecessary bits, you're left with PKCS #10 with
support for X.509v3 attributes (which CMMF gives you anyway), and a bit of
POP stuff which may or may not be covered by patents and may or may not be
of any use in practice.
Given that you lose any compatibility with existing implementations, there
seems to be little incentive to move to CRMF - the only reason would be that
you specifically need POP support for non-signature keys.
(The reason I haven't started picking all this apart yet on the PKIX list is
that I'm still not through griping about the cert/CRL profile, and I want to
limit myself to one standard at a time :-).
Peter.
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
