Re: Should PKIX protocols support XML well

[Russ Housley <housley@xxxxxxxxxx>]

Steve:

I agree with both of your points.  However, XML-enabled clients are of 
interest when those clients are using XML digital signatures.

I would like to see a solution where clients that are prepared to deal with 
ASN.1 can get a signed response in the CMS format (RFC 2630), and clients 
that are prepared to deal with Signed XML can get a response in that 
yet-to-be-finalized format.

Further, the XML client should be able to treat the X.509 certificate as an 
octet blob.  They simply pass the certificate to the trusted server, and 
the server returns a signed testament that the certificate is valid, the 
public key, and alt names.  There may be other fields that should be 
returned, but we need to explore this model further to understand what they 
might be.

Russ

At 02:04 PM 11/13/2000 -0500, Stephen Kent wrote:
> 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