Re: XML certificate ...

The size issue will have to be evaluated. I know it's not irrelevant.
Just a few thoughts: 

- the real issues with ASN.1/BER are not just that it is hard to read
  but also that it has so much overhead. (See Peter Guttman's writings
  about this subject.)

- if size where very critical, BER or DER would not be the encodings 
  of choice either (as they are known to be inefficient, according
  to Marshall T. Rose's "The Open Book")

- if size is critical, deflate compression will go a long way (probably
  3:1,) more will have to be seen

- one can safely say that in the future on-card memory will increase

- no, an XML cert does not need to contain more parts of the chain
  than an X509 cert if that is what is desired. The structure can
  be made quite flexible

If there is some interest, this is the way I would approach it:

1 use UML models to reverse engineer X509, SPKI, and PGP certs and
  cert-related structures

2 develop an abstract UML model to which X509, SPKI and PGP can all
  be mapped

3 transform that abstract UML model to an XML DTD or Schema

4 document the differences in semantics and policy of the various
  existing approaches, i.e., X509 and PGP: identity cert; SPKI:
  attribute cert.

5 document the detailed mapping rules of the XML cert from and to
  X509, SPKI and PGP certs.

6 done.

7 encapsulating certificates (a la Satoshi Hada's proposal) can also 
  be considered however the value of XML encapsulation of X509 seems 
  not very compelling to me. But I may have misunderstood Hada-san
  no proposal. I'm just saying that I would not like to see this 
  walking down an encapsulation path. I see no point of redoing MIME
  in XML.

I have some experience with model-based design and harmonization
of different similar standards, and from my knowledge of X509, SPKI,
and PGP, I believe that this is -- technically -- not a terribly
difficult job. However, I see there may be political issues, which
I expect can all be buffered, if we identify what they are: turf-battles.
A W3C cert wg can set an inclusive reconciliative interoperability
against that.

If the signature WG has a fixed charter where certs don't belong
I do suggest to keep thinking about opening a new xml-cert wg, although
this seems somewhat inefficient to me to split signature, encryption
and certs over 3 wgs. May be one can think about consolidation?
The advantage of consolidation is that it avoids all three inherently
related WGs to walk down three different paths.

regards,
-Gunther


Ken Goldman wrote:
> 
> 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