Re: XKMS 2: errata: X.509 DNs not in RFC 2253 format

> I don't know if Tommy generated those, or just inherited them?

I inherited them. I'll see what I can do about that.

Regards,
Tommy

On 10/17/05, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
>
> Hi James,
>
> Sounds like we should make those changes to the examples. I don't
> know if Tommy generated those, or just inherited them?
>
> However I'd note in passing that using "bad" x.509 in our examples,
> does show that we achieved the required x.509/xkms blood-brain
> barrier:-)
>
> Thanks,
> Stephen.
>
> Manger, James H wrote:
> > 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 <http://2.5.29.10> & 2.5.29.1 <http://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...
>
>
>