Re: XML certificate ...

Also new to the list.

ASN.1 is hard to read because it is so compact while XML is easy to
read because it's verbose.

For certificates, there is a big advantage to compactness, as they
often have to be stored on limited memory devices like smart cards.

I'd like to see a size comparison.  On a smart card, 100 bytes can be
very important.

Also, if the certificate is signed using a DSIG signature, including
the KeyInfo, which itself has a certificate, does this now require the
entire certificate chain to be included in each certificate?

> Date: Tue, 09 May 2000 19:06:37 -0500
> From: Gunther Schadow <gunther@aurora.rg.iupui.edu>
> 
> I have just joined this list. I'm not sure whether this has been discussed
> here, but cursory searches have not exactly hit me with obvious results.
> So here goes:
> 
> As the world reinvents everything using XML, might it not be time to do
> the same with certificates?  I think the world of certificates could 
> use a big shake-up.  Getting rid of X509 and ASN.1 would be a huge 
> reduction of burdon on any security implementation. It would make 
> certificate generation and interpretation a snip of a finger. 
> Compatibility with X509, SPKI, and PGP certificate products could be
> provided through XMLifying translators.  The goal would be to have one
> generic syntax that can support the approaches of X509, SPKI and PGP all
> without these stupid hassles that come with the different presentation 
> formats.
> 
> Isn't there any such activity ongoing already? If not I'd be happy to
> hammer out a DTD that would cover X509, SPKI and PGP semantics. I just
> have to do this in order to not go insane over this ASN.1 business.
> 
> The XML certificate specification could be using XML signature and
> XML canonicalization. However, canonicalization isn't exactly a
> requirement.


-- 
Ken Goldman   kgold@watson.ibm.com   914-784-7646

Received on Wednesday, 10 May 2000 09:39:22 UTC