[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ;binary

Thanks, Phil.

You raise two implicit matters.

The first relates to style sheets and LDAP browsers. Style sheets are not a
part of LDAP and, though many clients may be HTML aware, the dependency
needs to be pointed out.

The second relates to your representation of certificates in XML. Are you
saying that CXER can be uniquely mapped to DER? I assume you preserve the
original signature (over the DER), otherwise you would be defining an XML
certificate?

Ron.

-----Original Message-----
From: Phil Griffin [mailto:phil.griffin@asn-1.com]
Sent: Monday, 25 February 2002 16:56
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: ;binary


Ron,

You can likely achieve the LDAP string encoding and
the other representation that you show below by style 
sheet processing of an XER encoding. Many such textual
representations are possible. But you are correct, for
the ASN.1 XML Encoding Rules the encoding will be XML 
1.0 markup.

And this markup is human-readable, though not as readable
as plain text. But it can be easily transformed into other
textual formats in a standard way, using readily available
tools. And this XML markup representation does exist for
each and every ASN.1 value, regardless of whether or not
an alternative LDAP defined encoding exists. 

For example, there is an XER representation of ASN.1 type 
Certificate that is human-readable. This representation
will be defined in the X9.96 XML Cryptographic Message
Syntax NWI just approved last week by X9. It carries 
X.509 certificates in one of the saddle bags of type 
SignedData.

In X9.96, the messages defined in X9.73 CMS (the ANSI X9 
version of IETF S/MIME and RSA PKCS #7) will be specified
using the ASN.1 from that standard, in a canonical XML 
variant of XER (CXER), so that the resulting XML messages
can be cryptographically enhanced. I spoke on this subject
at the RSA conference last week (http://ASN-1.com/cxer.zip).

Phil




"Ramsay, Ron" wrote:
> 
> Phil,
> 
> I would think that this wouldn't encode an address as "1 First Avanue,
> Downtown" (human readable) or "1 FirstAvanue$Downtown" (LDAP) but as
> 
> <street-address><item>1 First
> Avanue</item><item>Downtown</item></street-address>
> 
> ?
> 
> Ron.
> 
> -----Original Message-----
> From: Phil Griffin [mailto:phil.griffin@asn-1.com]
> Sent: Monday, 25 February 2002 14:42
> To: ietf-ldapbis@OpenLDAP.org
> Subject: Re: ;binary
> 
> The possibility of defining a human-readable
> format for binary ASN.1 values in the future
> is here, right now. Done already - or at least
> very near final approval.
> 
> It's called the 2002 edition of ISO/IEC 8824-1 |
> ITU-T Recommendation X.680, and it defines an XML
> markup representation for every value of every ASN.1
> type. Interestingly, it defines a dotted format,
> borrowed from LDAP, for values of type OBJECT
> IDENTIFIER.
> 
> And there's XML Encoding Rules (XER), defined in
> ISO/IEC 8825-3 | ITU-T Recommendation X.693. These
> encodings carry the exact same abstract values as
> defined in the ASN.1 standards, but in a human-
> readable textual format.
> 
> Having XER allows you to easily switch back and
> forth between binary and textual representations
> of the exact same values.
> 
> Phil
> 
> "Ramsay, Ron" wrote:
> >
> > Steven,
> >
> > I think you have stepped over the edge with this proposal. After Kurt
was
> so
> > careful to explain that we must use the ASN.1 implied by the attribute
OID
> > with reference to the X.500 documents!
> >
> > What about aci;encoding=novel;. Would this be a subtype?
> >
> > Ron.
> >
> > -----Original Message-----
> > From: Steven Legg [mailto:steven.legg@adacel.com.au]
> > Sent: Monday, 25 February 2002 10:47
> > To: 'Christopher Oliva'
> > Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)'
> > Subject: RE: ;binary
> >
> > Chris,
> >
> > Christopher Oliva wrote:
> > > > The problem with this is that if a server is allowed to
> > > > return ;binary when the client makes a request without
> > > > ;binary then the servers might actually do that.  That
> > > > would be bad as client wouldn't get what they asked for.
> > > >
> > > As I have shown above, the client would know what they are getting
> > > since the server has replied with ";binary".
> >
> > Unfortunately, client implementors often don't take into account all
> > the potential responses they can get. They usually do enough to make
> > their client work with their preferred LDAP server and leave it at
> > that. So even if we explicitly specify that servers are allowed to
return
> > ";binary" without it being requested, there will still be people
> > implementing clients that don't expect it.
> >
> > Apropos of the current discussion, I've found a good reason for NOT
> > specifying that the native LDAP encoding for some syntax is the
> > same as its ";binary" encoding. I've just submitted an I-D for
> > an LDAP profile of X.500's Basic Access Control (it should appear in
> > a few days) which uses the ACI Item syntax from RFC 2252. I've defined
> > c for this syntax. However, I
> > would have had a problem if the native LDAP encoding for this syntax
> > had been previously defined to be the same as its ";binary" encoding.
> >
> > By not defining the native LDAP encoding to be the same as the ";binary"
> > encoding for syntaxes that don't have a defined human-readable encoding,
> > we leave open the possibility that we might define one in the future.
> >
> > Regards,
> > Steven