RE: Comments on "XML-Signature Syntax and Processing"

> -----Original Message-----
> From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
> Sent: Tuesday, December 19, 2000 7:06 AM
> To: Brian LaMacchia
> Cc: muraw3c@attglobal.net; w3c-ietf-xmldsig@w3.org; Karl Scheibelhofer
> Subject: RE: Comments on "XML-Signature Syntax and Processing"
> 
> >   We went a further step to define some of the PGP sub-structure
> >(based on advice from members of the OpenPGP WG).  I think the ANYs
should
> >be present both for PGPData and SPKIData.
> 
> However, I was going to ask even if that what was intended, should it be
so 
> now? SPKIData is provided for a particular a non XML representation, "The 
> content of this element type is expected to be a Canonical S-expression."
As 
> is PGPData: PGPKeyID and PGPKeyPacket are of type string and
ds:CryptoBinary 
> respectively.

I think you're mis-interpreting what was meant by "is expected to be a
Canonical S-expression".  As the draft was being produced we talked with
Carl Ellison about generating a pure XML representation of the contents of a
SPKI certificate.  Carl seemed to think this would be pretty
straightforward, but there are a couple of ways to do it.  (You could
generate new schema from scratch, you could just Base64 encode the
pre-existing binary representation of the SPKI cert, etc.)  So our intent
was to define the top-level tag where SPKI would plug in, but we left the
definition of the internal contents of that element to the SPKI WG.

> Given our philosophy of extensibility and the use of XML I'd think that if

> WGs created actual XML structures, they should have their own root element

> that sits under KeyInfo under their own namespace. 

Well, yes, except that the WG chose to define the root elements for the
three types of certificate-like data supported by IETF WGs: X509, PGP and
SPKI.  Recall that one of our primary goals was to keep KeyInfo as neutral
as possible with respect to particular technologies for making statements
about public keys.  An alternative, rejected by the WG, was to punt all
definitions for X509Data, PGPData and SPKIData from the XMLDSIG spec.

> Under my understanding, 
> the following namespaces had well specified meanings:
> [1] http://www.w3.org/2000/09/xmldsig#X509Data
>          X509 is fairly extensive
> [2] http://www.w3.org/2000/09/xmldsig#PGPData
>          encoding of KeyID and KeyPacket
> [3] http://www.w3.org/2000/09/xmldsig#SPKIData
>          SPKIData for S expressions
> and if someone supports any of these, it's clear what it means. Having ANY

> within these structures still requires the use of an external namespace,
but 
> makes the ability to say, "I support [1,3]" ambiguous.

It's not a matter of "supporting" any of these; these types identify the
content of data retrieved remotely via a RetrievalMethod directive.  They
bind, one-for-one, to XML structures defined within the XMLDSIG spec.  The
fact that those structures are extensible doesn't matter; if you retrieve
something that claims to be X509Data, then it better be derived from
X509Data schema.

					--bal

Received on Tuesday, 19 December 2000 13:34:34 UTC