>Neither do any of the three PKCS 10 schemes - that's why you raised the
>question in the first place.
Actually PKCS #10 *almost* does it, but because it hasn't received any real
publicity, noone seems to know about it. As it turns out, the scheme defined
in the CMMF draft, which appears to have a valid PKCS #9 OID allocated for it
and which is identical to the third scheme in the list I posted, seems about
the best way to do it. Once I get confirmation from the authors that this is
stable, I'll add it to the style guide, since it's extremely trivial to add to
any existing PKCS #10 implementations. With attribute support present, the
only really significant problem in PKCS #10 is fixed.
>Entrust deserves every bit of distrust they have engendered by their recent
>patent actions. However, there is nothing specific to CRMF which is
>especially likely to become encumbered. If you regard Carlisle as guilty by
>association, you might as well use the same argument against GSS-IDUP, CAST5,
>or any of the other work he has been involved with.
I was in no way intending to cast any aspersions on the fine work which Entrust
people have done in the crypto area. What I was pointing out is that PKCS #10
has been around for a long time and, barring the ambiguity over tagging of
attributes, is completely stable and very easy to implement. In contrast the
CRMF draft may or may not require changes to avoid patent complications, and it
could take a long time before we know whether it's safe (unencumbered) or not.
>You might not see the need for the issuer name, but if I were requesting a
>cert from VeriSign, I might populate the request with the Class 1 PCA, the
>Class 2 PCA, or the Class 3 PCA in the issuer field. (That might not be a good
>example, but it extends to intranet CAs which could have multiple logical
>issuers at the same physical location.)
Hmm... this doesn't appear to have caused any problems to date, but I'll admit
there's a possiblity it'd be useful for something. It'd be nicer, however, if
the request were laid out so that the purpose of the fields were a bit more
obvious, eg:
requestedIssuingCert ::= IssuerAndSerialNumber
requestedValidityDate ::= Validity
instead of including every possible cert field as a tagged optional extra. For
one thing it'd eliminate the "what the ??!?" response when you first see the
proposed structure :-).
Peter.
+--------------------------------------------------------------------------+
+ For information about the cert-talk mailing list, including archives +
+ and how to subscribe and unsubscribe, visit: +
+ http://mail.structuredarts.com/cert-talk +
+--------------------------------------------------------------------------+
