Issuer DN escaping

[Robert Egglestone <r....@auckland.ac.nz>]

Hi all,

I've run into a problem around the use of issuer DNs while using
xml-security with wss4j. I notice wss4j has some problems in this area, and
I've submitted a patch for that, however I've seen extra escaping coming out
of xml-security causing the DNs to be interpreted differently, and I'm not
sure if this is correct, or what format I should be expecting.

In this case, the issuer in the SOAP request looks like this:
1.2.840.113549.1.9.1=#16197072656d69756d2d736572766572407468617774652e636f6d
,CN=Thawte Premium Server CA,OU=Certification Services Division,O=Thawte
Consulting cc,L=Cape Town,ST=Western Cape,C=ZA

XMLX509IssuerSerial.getIssuerName returns something like this:
1.2.840.113549.1.9.1=\#161970726....
an extra slash has been added before the #.

I'm not sure why an extra slash is added, however I'm wondering if
getIssuerName should be calling RFC2253Parser.xmldsigtoRFC2253 instead of
RFC2253Parser.normalize.

Cheers,
Robert Egglestone

Re: Issuer DN escaping

[Sean Mullan <Se...@Sun.COM>]

Robert Egglestone wrote:
> Hi all,
> 
> I've run into a problem around the use of issuer DNs while using
> xml-security with wss4j. I notice wss4j has some problems in this area, and
> I've submitted a patch for that, however I've seen extra escaping coming out
> of xml-security causing the DNs to be interpreted differently, and I'm not
> sure if this is correct, or what format I should be expecting.
> 
> In this case, the issuer in the SOAP request looks like this:
> 1.2.840.113549.1.9.1=#16197072656d69756d2d736572766572407468617774652e636f6d
> ,CN=Thawte Premium Server CA,OU=Certification Services Division,O=Thawte
> Consulting cc,L=Cape Town,ST=Western Cape,C=ZA
> 
> XMLX509IssuerSerial.getIssuerName returns something like this:
> 1.2.840.113549.1.9.1=\#161970726....
> an extra slash has been added before the #.

This is a bug. It's ok to insert a '\' before the '#' if it is a String 
value, but this is a hex value, and so inserting a '\' makes it 
non-compliant with RFC 2253.

I'll file a bug and fix it.

--Sean