- From: Manger, James H <James.H.Manger@team.telstra.com>
- Date: Mon, 17 Oct 2005 14:33:16 +1000
- To: <www-xkms@w3.org>
The certificate returned in the example of registration of a client-generated key pair (section 6.1.1) is strange.
The <RegisterRequest> includes:
<UseKeyWith Application="urn:ietf:rfc:2459"
Identifier='C="US" O="Alice Corp" CN="Alice Aardvark"' />
The subject distinguished name (DN) in the resulting certificate consists of 1 RDN with 1 attribute (commonName):
subject rdnSequence:{
{
{ type commonName, value "Alice Aardvark O=Alice Corp C=US" }
}
},
This is too weird. Presumably DN should consist of 3 RDNs each with a 1 attribute:
subject rdnSequence:{
{
{ type countryName, value "US" },
{ type organizationName, value "Alice Corp" },
{ type commonName, value " Alice Aardvark " }
}
},
The certificate has 2 extensions: basic constraints indicating that it is an end-entity certificate; and authority key id indicating the CA's key & certificate details. Both these extensions use very old (deprecated) OIDs (2.5.29.10 & 2.5.29.1) and syntaxes! Even RFC 2459 (which XKMS 2 references, but is itself obsolete) uses newer OIDs for these extensions. In fact, those OIDs are so old I cannot find their specs!
The certificate serial number is a negative, which is not PKIX-compliant (RFC 3280).
The certificates in other examples are similarly strange.
P.S. Section 10.4 "Security of Limited Use Shared Secret" says a shared secret SHOULD contain a minimum of 32 bits of entropy. The example in section 6.1.1, however, uses 6 decimal digits "024837", which has less than 20 bits of entropy.
_____________________________________________
From: Manger, James H
Sent: Monday, 17 October 2005 10:24 AM
XML-Signature formats X.509 distinguished names (DNs) according to RFC 2253 "LDAP (v3): UTF-8 representation of distinguished names". XKMS should use the same format...
Received on Monday, 17 October 2005 04:38:03 UTC