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

At 09:21 12/19/2000 -0800, Brian LaMacchia wrote:
>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.

Hi Brian, after our brief conversation we at least identified where the 
disconnect was with respect to defining these (X509Data, PGPData and 
SPKIData) element types. You could use one of these element types and an ANY 
child to do two do things:

1. "reserve" a name for definition by some other group. This doesn't make 
sense to me as they'd still have to create *normative* element types (can 
not be ignored) under their own namespace, so why do we need a wrapper in 
the dsig space with no meaning? KeyInfo itself has an ANY so there's no need 
to reserve. SPKIData was mentioned in this context and my view leads me to 
believe it should have fairly well defined content (like Canonical 
S-expressions) or it's meaningless.
2. provide a way to *non-normatively* extend (can be ignored) the elements 
that DSIG has already defined. So if a PGP WG defined more element types 
beyond dsig:PGPKeyID and dsig:PGPKeyPacket they could be used as a 
complement to those elements.

Now I didn't realize the ANY in PGPData was doing #2 (which I now 
understand); I thought it was another instance of #1 (which I disagree with, 
if a PGP WG defined an XML structure including their own pgp:PGPKeyID, 
pgp:PGPKeyPacket they should have their own root element as a child of 
KeyInfo.) Additionally, one could argue even #2 isn't the right way to do 
it, as people should use create their own namespace and schema under KeyInfo 
and use schema to equate pgp:PGPKeyID = dsig:PGPKeyID; but the state of 
schema implementation isn't quite there yet so this isn't the strongest 
argument...

Consequently, if this is what we are after I think each of the KeyInfo types 
we define need a normative definition (including SPKIData, it should be 
something such as Canonical S-expressions) then the ANY's in KeyInfo would 
be as follows:

KeyInfo
         ANY = key structures from external namespaces
         including those that are meant to be alternatives to the
         existing ones.
         PGPDATA, SPKIData, X509DATA
                 ANY=optional (ignorable) key structures from
                 external namespaces that complement existing
                 dsig:* structures.




__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 19 December 2000 18:49:11 UTC