Re: ;binary

[Phil Griffin <phil.griffin@asn-1.com>]

"Ramsay, Ron" wrote:
> 
> 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.

Yes. This XML encoding is a way to better leverage 
browsers for ASN.1 users, and other formats can be 
produced using style sheets as well.

> 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?

Yes, CXER cand DER are two encodings of the same abstract
values which are based on the same underlying schema - the
ASN.1 definitions defined in the X.680 series. The 2002
Draft is at Host:  ftp://ties.itu.int login: asn1 
password: notation1, but X.693 was not there when last 
I looked. 

In X9.96, the signatures on X.509 and X9.68 certificates
will be over the DER encoding (or PER in the case of
X9.68 which allows either) - nothing new there. But the
signature in SignedData will be over an XML encoding, not
DER.

But this work will also define an XML representation of
the values of all of the types it references, so there
will be an XML representation of an X.509 certificate
produced in this work.

Phil


> 
> 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