Subject: RE: RFC2253 e-mail address

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 15 Nov 2001 14:49:21 +1100

So, why isn't it a real solution. You code the object identifier and wrap
the value:

1.3.6.1.4.1.1466.115.121.1.41=#0411726f6e2e726a6d7361794063612e636f6d

?

Ron.

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Thursday, 15 November 2001 14:07
To: Ramsay, Ron
Cc: [email-masked]
Subject: Re: RFC2253 e-mail address

"Ramsay, Ron" wrote:
> 
> You may be right. I know there was some concern in LDAP about servers
being
> able to understand DNs, particularly when they support chaining and the
> server for which the DN was meant could understand it. For interoperabilty
> (and, in your case, portability), the attributes used in DNs should be
> restricted the geographical ones occurring in the X.500 examples.

But that's not a real solution since a sender implementation would
be free to also use hex-string BER-encoding for the classical X.500
attributes still being compliant to RFC 2253.

Ciao, Michael.

> Ron.
> 
> -----Original Message-----
> From: Michael Ströder [mailto:[email-masked]]
> Sent: Thursday, 15 November 2001 12:57
> To: Ramsay, Ron
> Cc: [email-masked]
> Subject: Re: RFC2253 e-mail address
> 
> "Ramsay, Ron" wrote:
> >
> > For true interoperability, some believe you should only use the name
forms
> > for the attributes in the table in 2.3. This would be the baseline for
> > interoperability. To encode an ascii string in BER for this case, you
> might
> > think that the X.500 version of directory string would be meant, this
> would
> > result in the encoding 16 04 41 42 43 44 as the encoding of "ABCD".
> However,
> > I think all that LDAP requires is an octet string wrapper, when the
> encoding
> > would be 04 04 41 42 43 44.
> 
> Ron, you raise another issue which BER encoding is used. For me the
> conclusion is that RFC 2253 is not sufficient to represent
> certificate subject and issuer names in e.g. XML-DSIG.
> 
> Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 15 Nov 2001 11:22:41 +0100

> 1.3.6.1.4.1.1466.115.121.1.41=#0411726f6e2e726a6d7361794063612e636f6d

Because it's unclear which BER-encoding to use for the string type?
E.g. if CN contains NON-ASCII chars and the attribute value is
encoded as T61String. Which string type to use for the BER encoding?
The answer is clear for LDAP (UTF-8-encoded Unicode wrapped in OCTET
STRING). But for PKIX?

Ciao, Michael.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 15 Nov 2001 13:35:52 +0100

OOOoops!
This "simple" question was apparently not that trvial..

It seems that the XMLDsig designers failed to realize that an element

        <X509SignatureCertificate
            Subject="Optional string in arbitrary interpretation"
            Issuer="Optional string in arbitrary interpretation"
            Serial="Optional integer">base64certblob</X509SignatureCerificate>

would have reduced the problem to NIL instead of going into string matching which
seems to be a real PITA and also looks like s---t.

Anders

----- Original Message -----
From: "Michael Ströder" <[email-masked]>
To: "Ramsay, Ron" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 15, 2001 11:22
Subject: Re: RFC2253 e-mail address

Ciao, Michael.