> I think RFC 3280 (section 4.1.2.4 Issuer) defines the common set of
> attributes every reasonable CA should use.
OK, thanks! Is this a final answer from the EUGridPMA or David should
asknowledge it ;)
Think that I got the error in the Bouncy Castle code: is puts
the {"sn", OID(2.5.4.5)} pair into the lookup table, but as per RFC 2256
this should be {"serialNumber", OID(2.5.4.5)} and the "sn" is an shorthand
for the OID(2.5.4.4). Am I right?
There were the same error in the OpenSSL prior to 0.9.7, here is the snippet
from the CHANGES file:
-----
*) Make object definitions compliant to LDAP (RFC2256): SN is the short
form for "surname", serialNumber has no short form.
Use "mail" as the short name for "rfc822Mailbox" according to RFC2798;
therefore remove "mail" short name for "internet 7".
The OID for unique identifiers in X509 certificates is
x500UniqueIdentifier, not uniqueIdentifier.
Some more OID additions. (Michael Bell <[log in to unmask]>)
[Lutz Jaenicke]
-----
Were this related to some historical confusion? I am just curious...
The snippets from the BC code (org/bouncycastle/asn1/x509/X509Name.java):
-----
/**
* device serial number name - StringType(SIZE(1..64))
*/
public static final DERObjectIdentifier SN = new DERObjectIdentifier("2.5.4.5");
/**
* Naming attributes of type X520name
*/
public static final DERObjectIdentifier SURNAME = new DERObjectIdentifier("2.5.4.4");
DefaultLookUp.put("sn", SN);
DefaultLookUp.put("surname", SURNAME);
-----
A side note: I really do not understand why the trustmanager code should deal
with the textual representation of the DN and use X509Name class. We have
the (proxy) certificate at hand, so why we aren't using the ASN.1 structure
itself? Life will be much easier, because the translation from strings to
ASN.1 when we have the access to the ASN.1 itself is a bit overkill. Or I am
missing something? Joni?
--
rea
BOFH excuse #253:
We've run out of licenses
|