Subject: Re: Should PKIX protocols support XML well

From: Russ Housley <[email-masked]>
Date: Fri, 10 Nov 2000 16:42:52 -0500

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

At 11:08 AM 11/10/2000 -0800, Ambarish Malpani wrote:

>There are a bunch of industries/communities that are using XML
>throughout their systems - all their messages are in XML, all
>their development is in XML and XML is their chosen future
>direction.
>
>We may or may not agree about whether this is a wise decision, but
>that decision has been made and is one that we (PKIX) can not
>change.
>
>Now the question is, do we try and support such groups in their
>efforts or do we say: "Sorry, we think you did the wrong thing
>by not picking ASN.1, so go figure out how to do public key
>cryptography by yourself - we won't help"
>
>My personal bias is that if a significant percent of the world
>is headed towards XML, it makes more sense for us to support that
>group and make sure that when they do PKI, they do it in a
>secure way, rather than ignore that world and have them do PKI
>either insecurely, or in n different ways. After having seen
>different standards groups, I am quite convinced that IETF
>actually do a pretty good job with their specifications and the
>thoroughness with which specifications are reviewed. I think it
>is our responsibility to help set the standards so that people
>can use them in most significant environments, rather than have us
>ignore the issue and have people not only do it in less secure
>ways, but also have different groups do the same job in
>different ways.
>
>[Note: I am not trying to say that IETF should set all standards
>in the world, but it does need to acknowledge and react to the
>needs of large and diverse groups. And the XML community is one
>such group].
>
>Comments?
>Ambarish
>
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                                650.567.5457
>ValiCert, Inc.                                  [email-masked]
>339 N. Bernardo Ave.                          http://www.valicert.com
>Mountain View, CA 94043
>
>

---

From: Ambarish Malpani <[email-masked]>
Date: Wed, 15 Nov 2000 11:50:18 -0800

Steve, if the goal was to keep the clients simple, I would think
that the server would need to support both XML and ASN.1.

For particular communities that wanted to do something closed,
they could mandate support for only one of the formats, but for the
open world, I would expect the server to bear the burden.

Regards,
Ambarish

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, November 15, 2000 10:51 AM
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: Should PKIX protocols support XML well
> 
> 
> Russ,
> 
> >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.
> >
> 
> That seems reasonable based on your examples, but how do you want to 
> translate this into a standards requirement? If we made support for 
> ASN.1 or XML formats mandatory and the other optional it would 
> disadvantage one class of clients or the other. We can have two 
> distinct standards and let vendors choose which one to support, but 
> do we do that for both clients and servers, or do we plave the burden 
> on servers to support both forms of requests and to generate both 
> forms of responses?
> 
> Steve
>