RE: KeyInfo

-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Friday, January 12, 2001 4:24 PM
To: Brian LaMacchia
Cc: Donald Eastlake; lde008@dma.isg.mot.com
Subject: RE: KeyInfo


At 09:30 1/12/2001 -0800, Brian LaMacchia wrote:
>This is the issue on which I am confused: why do you believe we have to
>prohibit X509Data/PGPData/SPKIData elements that contain only children
from
>an external namespace?  Thinking about it more, I really don't see why
we
>should ban structures like this:
>
>         <PGPData>
>            <MyPGPNS:foo>barbaz</MyPGPNS:foo>
>         </PGPData>

Because I want to strongly discourage this! If someone is going to have 
something from MyPGPNS, what's the benefit/meaning of having this
included 
in our namespace qualified PGP element? 

[bal] Because if I build a lightweight parser the knows I only care
about <SPKIData> stuff, I can skip over everything between <PGPData> and
</PGPData>.  That is, when I place the new element MyPGPNS:foo under the
<PGPData> ... </PGPData> element I'm declaring a small piece of
metadata, namely that MyPGPNS:foo is of the same class of data as other
things in PGPData.  If I don't care about PGPData at all I can skip over
everything.  It allows extensibility within the model defined within
XMLDSIG.  It also makes it easier to write & maintain code concerned
with particular subtypes of KeyInfo.

This is meaningless to parsers and schema validators. 

[bal] Why do you say this?  It can be parsed, it can be schema
validated, and when I get the nod structure back from the parser and
start analyzing for semantic content, I can semantically qualify the
extension elements.

How would they define their own schema such that children 
are going to get used from their namespace in our context (and away from

their own parent)? 

[bal] The same way you do this for any other extensible schema element?
Why is this any different?

This approach of ANY (trying to hack an extensibility 
mechanism when schema provides a very nice one) pretty much destroys
schema 
classes and the meaning between the elements. It also makes it unlikely
that 
if a useful construct is built, it will be useable to others.

[bal] I don't believe this for a second.  How likely do you think it
will be for mutiple products to recognize KeyInfo extensions that don't
fall inside X509Data/PGPData/SPKIData?  My guess is that they'll be
dropped on the floor. 

--

<ds:PGPData>
   <ds:PGPKeyID>foo</ds:PGPKeyID>
</ds:PGPData>

Is well defined and can be strictly schema validated, and used as a
class 
elsewhere.

--

<ds:PGPData>
   <ds:PGPKeyID>foo</ds:PGPKeyID>
   <mypgp:GreatElement>bat</mypgp:GreatElement>
</ds:PGPData>

Is confusing. What's the relationship between PGPData's and
GreatExtension? 
GreatExtension had a parent, but now it's just been plucked from it's
schema 
and stuck in PGPData, maybe in its schema, it was never intended to be
used 
alone like this (because of the definition of its parent), but now it
is! 
You've advocated the need for this for extension capabilities in the
short 
term because schema isn't a REC yet, and I've budged. However, any other

KeyStructure standards that are written expecting to be used like this I

would object to.

[bal] OK, so how do I extend KeyInfo then?  What you seem to be implying
is that the W3C Schema religion does not allow extensible data
structures at all!  That can't possibly be true, can it?  It Schema
really so brain damanged that extensibility mechanisms must be put into
string values?

Plus, if the above instance ended up being a useful structure, others
can't 
extend it themselves as a class. It's a mule (donkey+horse) and unable
to go 
further.

[bal] I don't understand this.  Are you saying, "well, they can't
redefine the schema for ds:PGPData so they're stuck."  But that schema
allows an <any...> so they can plug in there?

--
<ds:PGPData>
   <mypgp:PGPData>
     <mypgp:BetterPGPKeyID>foo</mypgp:BetterPGPKeyID>
     <mypgp:GreatElement>foo</mypgp:GreatElement>
   </mypgp:PGPData>
</ds:PGPData>

Has the unique characteristic of being ambiguous (relationship between
the 
two PGPData's) and when disambiguated (requires human) redundant! It
should 
be under KeyInfo.

[bal] Why is this ambiguous?  You've defined two different tag types;
there's no implied relationship between ds:PGPData and mypgp:PGPData
because they're namespace qualified.

--

<mypgp:PGPData>
   <mypgp:PGPKeyID>foo</mypgp:PGPKeyID>
   <mypgp:GreatElement>foo</mypgp:GreatElement>
</mypgp:PGPData>

with the schema declaration:

<complexType name="PGPData">
  <complexContent>
   <extension base="ds:PGPData">
    <sequence>
     <element name="GreatExtension" type="string"/>
    </sequence>
   </extension>
  </complexContent>
</complexType>

Is clean! A parser knowns that any instance of mypgp:PGPData is just
like 
ds:PGPData but with a new element!

[bal] I'm not familiar with <extension...>, so how does that define
where the new element goes in the already-defined PGPData?  How do I
merge the constructs defined in PGPDataType with the new construct
defined here in the extension?  And won't I end up having to transport
the new schema everywhere I transport the new KeyInfo blob?  And if I do
this, any V1 code that isn't schema-aware will not be able to do
anything with this element at all.

>but could we just do that with a minOccurs="1" on a sequence, like
this:
>
>    <complexType name="PGPDataType">
>      <choice>
>        <sequence minOccurs="1">
>          <element name="PGPKeyID" type="string" minOccurs="0"/>
>          <element name="PGPKeyPacket" type="ds:CryptoBinary"
minOccurs="0"/>
>
>          <any namespace="##other" processContents="lax" minOccurs="0"
>           maxOccurs="unbounded"/>
>        </sequence>
>      </choice>
>    </complexType>
>
>Is that allowed?  This would also work nicely for X509Data & SPKIData.

My main concern in an editorial capacity has been to clarify any
ambiguities 
in the spec. In discovering/understanding your need for this extension
hack, 
we've moved towards deploying the ANYs consistently in the limited
context 
of complementing/extending elements from the dsig namespace. BUT I'm
opposed 
to going so far as to allow them to sit alone as you suggest. If we go 
there, I want to take it back to the WG and the schema reviewers. In
fact, 
we've made enough tweaks we need to post this to the WG regardless --
and 
I'm thinking it might be useful to move this thread to the WG (including

this email, if you'd like to forward your first one?)

[bal] So you do not consider extension elements to PGPData to be
first-class children of PGPData -- only PGPKeyID and PGPKeyPacket are
first-class children.  

[bal] In summary, it sounds like what you want is a spec that requires
schema-aware XML parsers in order to handle any extensions to the base
data types defined in XMLDSIG.  I am not at all convinced that is a good
thing for lightweight devices.  If it becomes impossible to use XMLDSIG
in private-label operations without bundling in a whole bunch of schema
stuff I fear we will drive off a whole boatload of potential customers.

__
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, 16 January 2001 18:24:46 UTC