Re: XML certificate ...

Hi,

From:  Ken Goldman <kgold@watson.ibm.com>
Date:  Wed, 10 May 2000 09:39:19 -0400
Message-Id:  <200005101339.JAA38778@alpha.watson.ibm.com>
To:  w3c-ietf-xmldsig@w3.org
In-reply-to:  <3918A80D.5D1B785C@aurora.rg.iupui.edu> (message from Gunther
	     	Schadow on Tue, 09 May 2000 19:06:37 -0500)
References:   <3918A80D.5D1B785C@aurora.rg.iupui.edu>

>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.

Certificates are frequently huge, not due to encoding questions, but
to verbose "policy" text whose utility and efficacy is not universally
accepted.

>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?

Why, for the certificate application, would you use a certificate as
KeyInfo?  Why not just issuer and serial number? Or omit the KeyInfo
entirely and encode signer information elsewhere in the XML
certificate.  This seems like a good example of the need for
flexibility in the format and optional presence of KeyInfo.

>> 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.

I am not sure if it is what you mean but you do not avoid the
complexities of implementation by translating the surface presentation
foramt of these other certificates to XML.  For example, you could
transalate the fields of an X.509 certificate to an XML syntax in an
information preserving manner.  Given such XMLized X.509 certificates,
you might even be able to do some certficiate chain or policy
validation entirely on the XML representation.  But when you get to
actually cryptographically verifying the signature in such a
certificate, you must re-create the exact byte stream that was signed.
In otherwords, you would always have to actually re-generate the
exact original ASN.1 encoding that was signed.

A few times during the work of the XMLDSIG WG a few individuals, in
public or private, have expressed shock, consternation, etc, over the
fact that XMLDSIG did not just adopt a thin XML frame around their
favorite binary signature (PGP, PKCS, whatever).  But it is only
because the SignedInfo data that is actually signed in XMLDSIG is XML
encoded that the result of the XMLDSIG WG deserves to be called an XML
signature.

>> 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

Donald

Received on Wednesday, 10 May 2000 14:32:31 UTC