Subject: RE: Should PKIX protocols support XML well

From: Ambarish Malpani <[email-masked]>
Date: Mon, 13 Nov 2000 11:16:27 -0800

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.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, November 13, 2000 11:04 AM
> To: Ambarish Malpani
> Cc: [email-masked] '
> 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----------------------------

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 14 Nov 2000 15:27:19 +0100

Ambarish,

>     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