IssuerDN issue

[Marcel Ammerlaan <ma...@dyskolus.com>]

Hi,

A second issue with interop testing I found is the issuer-name. In the
test-certificate I use
the state attribute is present. The .Net platform generates a message with
the attribute
'ST=' whereas Java generates 'S=' (or the other way round. I don't have the
messages at hand
right now).
I saw some other issues regarding matching of the DN, but these were related
to the order of the
attributes. Is there any definitive workaround for this (apart from the hack
I made..)

Regards,

Marcel Ammerlaan.

Re: IssuerDN issue

[Marcel Ammerlaan <ma...@dyskolus.com>]

On Nov 29, 2007 5:23 AM, Tom Scavo <tr...@gmail.com> wrote:

> On 11/28/07, Scott Cantor <ca...@osu.edu> wrote:
>
> > > I saw some other issues regarding matching of the DN, but these were
> > > related to the order of the
> > > attributes. Is there any definitive workaround for this (apart from
> the
> > > hack I made..)
>
> Your best bet is RFC2253 conformance.


Ok. I'll doublecheck and let the .net guys make the relevant changes or I'll
just put in a notice that
the state-attribute should not be used in the issued keys.

As to the robustness: I think some changes mentioned in the JIRA regarding
the ordering of
attributes should be integrated however. I understand it will not fix
everything but from a (quick)
glance at the relevant RFC, the attributes can be in any order by spec.

Regards,

Marcel Ammerlaan.

Re: IssuerDN issue

[Tom Scavo <tr...@gmail.com>]

On 11/28/07, Scott Cantor <ca...@osu.edu> wrote:
> Marcel Ammerlaan wrote:
> > A second issue with interop testing I found is the issuer-name. In the
> > test-certificate I use the state attribute is present. The .Net platform
>  > generates a message with the attribute 'ST=' whereas Java generates 'S='
>  > (or the other way round. I don't have the messages at hand right now).

ST agrees with RFC2253.  (I'd be surprised if Java does otherwise; see
javax.security.auth.x500.X500Principal)

> > I saw some other issues regarding matching of the DN, but these were
> > related to the order of the
> > attributes. Is there any definitive workaround for this (apart from the
> > hack I made..)

Your best bet is RFC2253 conformance.

> Having gone down this road over the warnings of people with more experience
> than myself, I can tell you that DN comparison is not a basis for reliable
> software.

Amen!

Tom

Re: IssuerDN issue

[Scott Cantor <ca...@osu.edu>]

Marcel Ammerlaan wrote:
> A second issue with interop testing I found is the issuer-name. In the 
> test-certificate I use the state attribute is present. The .Net platform
 > generates a message with the attribute 'ST=' whereas Java generates 'S='
 > (or the other way round. I don't have the messages at hand right now).
> I saw some other issues regarding matching of the DN, but these were 
> related to the order of the
> attributes. Is there any definitive workaround for this (apart from the 
> hack I made..)

Having gone down this road over the warnings of people with more experience 
than myself, I can tell you that DN comparison is not a basis for reliable 
software. If you really want to do it, you need to work in OID land and turn 
the RDNs into logical pieces you can compare without regard for the short names.

-- Scott