Re: Should PKIX protocols support XML well

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Ambarish,

> Hi Steve/Russ,
>     I hope nothing that I posted even implied that I recommend that
> certs and CRLs be encoded in XML. I think there is enough investment
> in ASN.1 certs/CRLs etc. to not make it a worthwhile effort. The
> remark I was trying to make is that I think future PKIX work should
> try and see if specifying protocols in XML or both XML and ASN.1
> make sense for the task they are trying to do.
> 
>     This is precisely why I tried to specify SCVP in both syntaxes.

Let me jump into this discussion. ASN.1 has been used historically to define
*protocols*. Since such protocols were carrying data structures that could
have their own existence outside their transmission in the protocols, we
ended up with ASN.1 for *data structures*. The prime examples are
certificates and CRLs.

The basic question is thus NOT whether we should specify new protocols in
ASN.1, XML or both XML and ASN.1, but rather whether we want to define NEW
data structures in XML or ASN.1. As an example, an OCSP response is an ASN.1
data structure that has an existence beyond its transmission in the
protocol, since it can be stored and re-used to make sure, e.g., it was
correctly signed. 

The basic question is thus the following : should new data structures,
signed by an authority, which would vouch for the validity (they are various
flavors around that term) of a certificate or certificate chain against some
rules be defined in ASN.1 and/or XML ?

Let me just provide one first argument: ASN.1 is much more compact than XML.
There are other arguments indeed. You are welcome to provide them.

Denis
 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  ambarish@valicert.com
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Stephen Kent [mailto:kent@bbn.com]
> > Sent: Monday, November 13, 2000 11:04 AM
> > To: Ambarish Malpani
> > Cc: 'ietf-pkix@imc.org '
> > Subject: Re: Should PKIX protocols support XML well
> >
> >
> > Ambarish,
> >
> > XML has various benefits for representing certain kinds of data, but
> > none of those seem especially relevant to the encoding of certs or
> > CRLs. Moreover, at a time when people in various quarters (e.g.,
> > wireless folks) complain about the size of certs, it would not seem
> > especially appropriate to adopt an XML encoding, which would increase
> > the size of these data items.
> >
> > I am not persuaded by comments that allude only to the "trendiness"
> > of XML vs. ASN.1 encoding, as several others have pointed out. PKIX
> > was started as a profiler of X.509 protocols, and we have expanded
> > our charter to create new protocols that support X.509 certs and
> > which seem appropriate to PKI use in the Internet. That makes it hard
> > to justify developing new syntax for existing data structures, as
> > noted above.  However, as Russ pointed out, standards for carriage of
> > certs and CRLs (ASN.1 encoded) in an XML context are not out of the
> > question.
> >
> > Steve
> >
> 
> ----------------Russ's Original Message-------------
> Ambarish:
> 
> I agree that we need to support XML clients.  It would not have been one of
> my three criteria if I thought otherwise.  However, I do not think that we
> should abandon ASN.1.  I think that certificates and CRLs MUST be ASN.1
> encoded.  Providing an XML wrapper to carry an ASN.1-encoded blob is just
> fine.  Base64-encode it if you like.  Anyway, the server can obtain the
> ASN.1-encode certificate perform validation services.  The server will
> return an indication of validity and parse some information (especially the
> public key, alt names, and critical extension information) from the
> certificate.  This will allow the client to be completely ASN.1 ignorant.
> 
> I realize that this is just one aspect of making the entire system XML
> client friendly; however, I think that it is a very reasonable place to
> begin.  In many systems, enrollment is handled by issuing a token (such as
> a smart card).  In this case, the client has nothing to do with
> enrollment.  So, certificate validation is a good place to begin.
> 
> Russ
> -------------End of Message----------------------------