[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Should PKIX protocols support XML well
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. 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----------------------------