X500Principal and UTF-16 encoded certificates

Hi,

I have a java application that parses certificates. It works perfectly
for certificates that have their fields encoded in UTF-8.
It doesn't work well for UTF-16 encoding. While debugging the problem
I've found that getName(X500Principal.RFC2253) function returns the
name with extra 0x00 bytes (as if it confuses the first byte of UTF-16
to be a UTF-8 byte).

I've also found in Java doc (http://download.oracle.com/javase/1.4.2/
docs/api/javax/security/auth/x500/
X500Principal.html#getName(java.lang.String) ) that:
"If "RFC2253" is specified as the format, this method emits the
attribute type keywords defined in RFC 2253 (CN, L, ST, O, OU, C,
STREET, DC, UID). Any other attribute type is emitted as an OID. Under
a strict reading, RFC 2253 only specifies a UTF-8 string
representation. The String returned by this method is the Unicode
string achieved by decoding this UTF-8 representation."
This is consistent with the behavior that I've observed.

I would like to ask what are my options for correctly parsing the name
value in accordance with RFC2253 when encoded in UTF-16?

TIA,
Yosi

On Apr 21, 4:22*pm, Yosi Izaq <izaq...@gmail.com> wrote:
> Hi,
>
> I have a java application that parses certificates. It works perfectly
> for certificates that have their fields encoded in UTF-8.
> It doesn't work well for UTF-16 encoding. While debugging the problem
> I've found that getName(X500Principal.RFC2253) function returns the
> name with extra 0x00 bytes (as if it confuses the first byte of UTF-16
> to be a UTF-8 byte).
>
> I've also found in Java doc (http://download.oracle.com/javase/1.4.2/
> docs/api/javax/security/auth/x500/
> X500Principal.html#getName(java.lang.String) ) that:
> "If "RFC2253" is specified as the format, this method emits the
> attribute type keywords defined in RFC 2253 (CN, L, ST, O, OU, C,
> STREET, DC, UID). Any other attribute type is emitted as an OID. Under
> a strict reading, RFC 2253 only specifies a UTF-8 string
> representation. The String returned by this method is the Unicode
> string achieved by decoding this UTF-8 representation."
> This is consistent with the behavior that I've observed.
>
> I would like to ask what are my options for correctly parsing the name
> value in accordance with RFC2253 when encoded in UTF-16?
>
> TIA,
> Yosi

Just an update, rfc2253 (http://www.ietf.org/rfc/rfc2253.txt) states
it's objective as "UTF-8 String Representation of Distinguished
Names". Clearly, the legacy code I'm dealing with didn't take this
into account.
I'm currently experimenting with rfc1779 (http://www.ietf.org/rfc/
rfc1779.txt?number=1779) using all manner of UTF-16 encoded
certificate subjects.
Is there any specific reason why
X500Principal:getName(X500Principal.RFC2253) may be preferable to
X500Principal:getName(X500Principal.RFC1779)?

10x,
Yosi

On 21/04/2011 17:27, Yosi Izaq allegedly wrote:
> On Apr 21, 4:22 pm, Yosi Izaq<izaq...@gmail.com> wrote:
>> Hi,
>>
>> I have a java application that parses certificates. It works perfectly
>> for certificates that have their fields encoded in UTF-8.
>> It doesn't work well for UTF-16 encoding. While debugging the problem
>> I've found that getName(X500Principal.RFC2253) function returns the
>> name with extra 0x00 bytes (as if it confuses the first byte of UTF-16
>> to be a UTF-8 byte).
>>
>> I've also found in Java doc (http://download.oracle.com/javase/1.4.2/
>> docs/api/javax/security/auth/x500/
>> X500Principal.html#getName(java.lang.String) ) that:
>> "If "RFC2253" is specified as the format, this method emits the
>> attribute type keywords defined in RFC 2253 (CN, L, ST, O, OU, C,
>> STREET, DC, UID). Any other attribute type is emitted as an OID. Under
>> a strict reading, RFC 2253 only specifies a UTF-8 string
>> representation. The String returned by this method is the Unicode
>> string achieved by decoding this UTF-8 representation."
>> This is consistent with the behavior that I've observed.
>>
>> I would like to ask what are my options for correctly parsing the name
>> value in accordance with RFC2253 when encoded in UTF-16?
>>
>> TIA,
>> Yosi
>
> Just an update, rfc2253 (http://www.ietf.org/rfc/rfc2253.txt) states
> it's objective as "UTF-8 String Representation of Distinguished
> Names". Clearly, the legacy code I'm dealing with didn't take this
> into account.
> I'm currently experimenting with rfc1779 (http://www.ietf.org/rfc/
> rfc1779.txt?number=1779) using all manner of UTF-16 encoded
> certificate subjects.
> Is there any specific reason why
> X500Principal:getName(X500Principal.RFC2253) may be preferable to
> X500Principal:getName(X500Principal.RFC1779)?
>
> 10x,
> Yosi

I doubt your finding, for the very simple reason that
X500Principal#getName returns a String, not a byte[]. So your extra null
byte would have to come from whichever part it is that transforms the
String to a byte[], or possibly from X500Principal#getEncoded(). The
problem may also be with the input, i.e. when and if the X500Principal
instance is created using the byte[] or java.io.InputStream c'tor.

I would suggest you posted an SSCCE <http://sscce.org/>.

AFAIK, there is no intrinsic reason to use RFC2253 over RFC1779,
although the former appears to me more recently widespread. I would say
it boils down to what the entity you communicate with (be it a library
or a third party) understands.

--
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

On Thu, 21 Apr 2011 08:27:02 -0700 (PDT), Yosi Izaq
<izaqyos@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>Is there any specific reason why
>X500Principal:getName(X500Principal.RFC2253) may be preferable to
>X500Principal:getName(X500Principal.RFC1779)?

I think RFC1779 only applies to ASCII. Even 16-bit Unicode was a new
fangled idea when it was released. C with its 8-bit chars was still
king.

RFC-2253 formally obsoletes RFC-1779.

RFC-2253 explicitly states in its title it is for UTF-8 only.

RFC-2253 in turn was obsoleted by RFC-4510, RFC-4514 and was updated
by RFC 3373.

You can discover this by chasing the links at
http://mindprod.com/jgloss/rfc.html

I wish RFCs would in the header report the obsoletes/obsoleted-by
information. It is so easy to use out of date information. Perhaps
someone might even edit them to create a unified document set with all
obsolete information removed, or at least partially grayed out.

--
Roedy Green Canadian Mind Products
http://mindprod.com
Politicians complain that Kindles and iBooks are killing jobs by
destroying the paper book industry. I see it that they have create a way
to produce books for less than a third the cost without destroying forests
and emitting greenhouse gases in the process. They have created wealth.
They are encouraging literacy and cutting the costs of education.

Fri, 22 Apr 2011 12:38:20 -0700, /Roedy Green/:

> I wish RFCs would in the header report the obsoletes/obsoleted-by
> information. It is so easy to use out of date information.

RFCs do state obsoletes information in their headers. For the
obsoleted-by information, just use:

http://tools.ietf.org/html/

e.g.:

<http://tools.ietf.org/html/rfc2253>:

Obsoleted by: 4510, 4514 PROPOSED STANDARD
Updated by: 3377 Errata Exist

--
Stanimir

On Apr 22, 10:38*pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> On Thu, 21 Apr 2011 08:27:02 -0700 (PDT), Yosi Izaq
> <izaq...@gmail.com> wrote, quoted or indirectly quoted someone who
> said :
>
> >Is there any specific reason why
> >X500Principal:getName(X500Principal.RFC2253) may be preferable to
> >X500Principal:getName(X500Principal.RFC1779)?
>
> I think RFC1779 only applies to ASCII. *Even 16-bit Unicode was a new
> fangled idea when it was released. C with its 8-bit chars was still
> king.
>
> RFC-2253 formally obsoletes RFC-1779. *
>
> RFC-2253 explicitly states in its title it is for UTF-8 only.
>
> RFC-2253 in turn was obsoleted by RFC-4510, RFC-4514 and was updated
> by RFC 3373.
>
> You can discover this by chasing the links athttp://mindprod.com/jgloss/rfc.html
>
> I wish RFCs would in the header report the obsoletes/obsoleted-by
> information. *It is so easy to use out of date information. Perhaps
> someone might even edit them to create a unified document set with all
> obsolete information removed, or at least partially grayed out.
>
> --
> Roedy Green Canadian Mind Productshttp://mindprod.com
> Politicians complain that Kindles and iBooks are killing jobs by
> destroying the paper book industry. *I see it that they have create a way
> to produce books for less than a third the cost without destroying forests
> and emitting greenhouse gases in the process. *They have created wealth.. *
> They are encouraging literacy and cutting the costs of education. *

It would seem as though X500Principal supports an obsolete version of
RFC
Any chance it got updated in a recent Java version?
Googling for that seems to suggest a negative answer, although it does
look that openLDAP SDK got updated.

Thanks!
Yosi

On Sat, 23 Apr 2011 01:09:16 +0300, Stanimir Stamenkov
<s7an10@netscape.net> wrote, quoted or indirectly quoted someone who
said :

>RFCs do state obsoletes information in their headers. For the
>obsoleted-by information, just use:
>
>http://tools.ietf.org/html/
>
>e.g.:

Granted the information is available, but I have yet to see an RFC
listing that integrates it right where they display the document or
that grays out obsolete material.

see http://mindprod.com/project/rfcconversion.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
Politicians complain that Kindles and iBooks are killing jobs by
destroying the paper book industry. I see it that they have create a way
to produce books for less than a third the cost without destroying forests
and emitting greenhouse gases in the process. They have created wealth.
They are encouraging literacy and cutting the costs of education.

On 24/04/2011 20:54, Roedy Green allegedly wrote:
> On Sat, 23 Apr 2011 01:09:16 +0300, Stanimir Stamenkov
> <s7an10@netscape.net> wrote, quoted or indirectly quoted someone who
> said :
>
>> RFCs do state obsoletes information in their headers. For the
>> obsoleted-by information, just use:
>>
>> http://tools.ietf.org/html/
>>
>> e.g.:
>
> Granted the information is available, but I have yet to see an RFC
> listing that integrates it right where they display the document or
> that grays out obsolete material.

Like this?
https://www.rfc-editor.org/cgi-bin/r...tp&filefmt=txt

On Sun, 24 Apr 2011 21:32:29 +0200, Daniele Futtorovic
<da.futt.news@laposte-dot-net.invalid> wrote, quoted or indirectly
quoted someone who said :

>> Granted the information is available, but I have yet to see an RFC
>> listing that integrates it right where they display the document or
>> that grays out obsolete material.
>
>Like this?
>https://www.rfc-editor.org/cgi-bin/r...tp&filefmt=txt

No, not quite. I want it integrated it at the head of the text of the
RFC so you can't read the RFC without realising it is obsolete. You
can land on the RFC itself by a google search and not realise you are
reading obsolete info.

--
Roedy Green Canadian Mind Products
http://mindprod.com
Politicians complain that Kindles and iBooks are killing jobs by
destroying the paper book industry. I see it that they have create a way
to produce books for less than a third the cost without destroying forests
and emitting greenhouse gases in the process. They have created wealth.
They are encouraging literacy and cutting the costs of education.