Peter,
May I say again what a valuable service you are performing in trying to
document the current practices in this area.
I spoke to Mike Myers and Michael Baum of Verisign on this issue, which is
somewhat more complex than it might sound at first.
Not only do there appear to be some rather fundamental problems with
PKCS #10, but the various CA's don't seem to be prepared to handle
extensions other than the ones they encode.
Whereas including an extension in the certificate request might make the
most sense, the few CA's I've tried seem to add predefined extensions,
e.g., the Microsoft code-signing attribute, and the similar but different
Netscape extension, based on what options are selected in the html page
you go to.
So even static extensions may be a problem if they are not already quite
well-known. Extensions that take a variable content from certificate to certificate
seem to be even more problematic. And finally, as we have already discussed
on this list, proprietary attributes (either proprietary to one vendor, or proprietary
to a subscriber) raised the pig-in-poke issue [an old southern US term for
for an unknown object carried in a sack or bag] -- the CA cannot reasonable
be asked to sign someonthing it doesn't understand, unless or until a Nonverified
Subscriber Information flag is defined that would apply to such extensions
in a standardized manner.
It seems to me that:
1. PKCS #10 is badly bent, if not completely broken. It either needs to be
updated, or replaced by some of the PKIX work. But what to do in the meantime?
2. I haven't been following the LDAP discussions. Will we have the same problems
with respect to certificate retrieval from and/or insertion into a directory using
LDAP,
or does it just transport on OCTET STRING blob?
Bob
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[EMAIL PROTECTED]
"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."
"The most dangerous strategy is to cross a chasm in two jumps."
>>> Peter Gutmann <[EMAIL PROTECTED]> 04/10 4:38 PM >>>
I'm trying to say something definitive about PKCS #10 attributes in the X.509
style guide, but noone seems to have any clear idea about how to encode
anything beyond the original, now mostly obsolete PKCS #9 attributes. PKCS
#10 defines an attribute as:
type = PKCS #9 OID
value = SET OF <x defined by OID>
However this all predates X.509v3, which renders many of the PKCS #9
attributes unnecessary and which requires support for some types of
user-specified extensions such as altnames and key usage flags. Noone seems
to know how to encode X.509v3 extensions as attributes, the three approaches I
can think of are:
1. Treat the extension as if it were an attribute:
type = cert.extension OID
value = SET OF <cert.extension data>
-- SIZE (1)
This doesn't allow you to communicate a critical flag, and performing a
sideways conversion of an extension to an attribute may not be the correct
thing to do.
2. Create an OID specifying that the atrribute is a collection of cert
extensions:
type = foo OID
value = SET OF <complete cert.extension>
This probably follows the intent of PKCS #10 most closely and is the most
logical one, but it gets ugly because of the DER encoding constraints
imposed on the SET OF.
3. As 2, but
type = bar OID
value = SET OF -- SIZE (1)
SEQUENCE OF <complete cert.extension>
This has the advantage that it neatly sidesteps the SET encoding problem.
This variant is the one used by the draft S/MIME cert request standard, but
the current state doesn't inspire confidence: It's only a draft, the OID in
the draft has a comment with a question mark after it, and the OID itself
is listed as "PKCS #9 Experimental".
A poll on the PKIX list a few weeks back didn't yield much information:
Answers ranged from "We ignore any extensions we find" through to "I don't
know what our software does". I'm not actually sure how you're supposed to
communicate something like an altname or key usage requirement to a CA (which
probably reflects the complete lack of altnames and nontrivial key usage
extensions in the 100-odd certs from assorted CA's which I have here). A last
resort approach would be to try out each CA and see how they respond, but it's
a bit difficult because I don't even know what format they'd like things in.
Is anyone using X.509 extensions with PKCS #10 requests? Is there a need for
this sort of thing? If everything about the S/MIME draft wasn't so uncertain
I'd go with that, but if there's something which a number of others are using
I'll use that instead.
Peter.
+--------------------------------------------------------------------------+
+ For information about the cert-talk mailing list, including archives +
+ and how to subscribe and unsubscribe, visit: +
+ http://mail.structuredarts.com/cert-talk +
+--------------------------------------------------------------------------+
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
