W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

Re: Revised syntax proposal

From: David Solo <david.solo@citicorp.com>
Date: Thu, 12 Aug 1999 08:44:47 -0400
Message-ID: <37B2C1BF.1DEE349D@citicorp.com>
To: rdbrown@Globeset.com
CC: dsolo@alum.MIT.EDU, w3c-ietf-xmldsig@w3.org
Richard,

Replies below...

Richard D. Brown wrote:
> 
> Dave,
> 
> >  <!ELEMENT signature (signedInfo, keyInfo?, sigValue)>
> >  <!ATTLIST signature
> >          id     ID      #IMPLIED>
> >
> 
> 1.1- Adopt a naming convention.
> Why signedInfo if sigValue? idem for signedAttributes and sigAlg.
> So, what do you think about sigValue, sigAttributes, sigAlg, and sigInfo.
> Notice, btw, that I was happy so far with Attributes and Value...

I have no allegiance whatsoever to particular names for elements or
attributes.  Whatever consensus is, I'm happy with.  Once the structure
is more or less stable, we can make a pass and harmonize the names.

> 1.2- I still argue that there is no obvious benefit to keep the KeyInfo
> element outside the scope of the signature. Conversely, there are known
> attacks on the signature when the KeyInfo is not protected. Among others, if
> a party is issued a plurality of certificates for a same key but different
> attributes, you can substitute one certificate for another without impairing
> signature verification. Probably some will argue that it is a flaw in X509
> (actually true for a large majority of the certificate-based infrastructures
> in place) and that the key alone should prevail. Unfortunately, the world is
> the way it is, and for the forseeable future I feel that we should
> accomodate with it and its flaws.

While I think we could do it either way, my preference is to have it
outside the sigInfo.  If an application wants to bind the certificate
(or other keyInfo) selected under the signature, then it can add a
signedAttribute (ala CMS); however if you move the keyInfo into sigInfo,
and an application doesn't want the binding, there isn't an option. 
Moving it into sigInfo implies to me an expectation that base validation
rules would do something with it, and I think we've ruled that out.

> >  <!ELEMENT signedInfo (algorithms, (object|reference),
> > signedAttributes?)>
> 
> 2.1- I think that we can do without the algorithms element and expand
> c14nAlg and sigAlg at this level. There is nothing wrong (from a data model
> standpoint) to say that these two elements are direct properties of the
> signature.

I flipflopped on this a couple times and don't have any strong
preference.  If there's no objection, we can promote them.

> 2.2- I would not distinguish between obejct and reference at this level.
> >From a model standpoint, the signature is applied to a resource, which one
> can be given by reference or by value. The distinction should be done
> further down the tree.

I think this is the biggest issue we need to debate.  If validation
always stops with the encapsulated item then I agree we only need one
type here.  The challenge is how to handle the usage scenarios where the
signature element is added to the thing its signing:

<package>
  <signedthing/>
  <signature/>  (with ref, including digest, to signed thing)
</package>

The goal of the reference type (and the processing rule you comment on
in point 17) is to try to accomodate the expectation that the default
behavior of a detached sigature (or non-encapsulating signature) will
actually check the digest over the thing begin pointed to (i.e. validate
the integrity and authenticity of the signed thing, not just the ref). 
While I continue to agree with the assertion in Boston and Oslo that we
don't recurse for links/resources in manifests and other documents; I
think we need to address this particular case.

> 2.3- Considering prior comments I would propose (disregard the order):
> <!ELEMENT sigInfo (c14nAlg?, sigAlg, keyInfo, resource, attributes)>
> 
> <!ELEMENT resource (reference | value)>

Just curious, why wouldn't you promote (reference|value) to sigInfo?

> <!ELEMENT reference (locator, digest)>
> 
> Alternatively, we might propose (from a model standpoint I like the previous
> one better)
> 
> <!ELEMENT resource ((locator, digest) | value)>
> 
> >
> >  <!ELEMENT keyInfo ANY>
> >  <!ATTLIST keyInfo
> >          type CDATA #REQUIRED >
> 
> 3.1- To follow XML common practices, might be should we turn all type
> attributes into a URL (at least URI). If so, the keyInfo element (as well as
> others) should be turned into simple xlinks (though never used as a link).

As I said in the issues section of the note, I'm deferring on this ( and
points 4-7) to the group as to the preferred way to reference these
items.  This was a placeholder for now.

> <!ELEMENT keyInfo ANY>
> <!ATTLIST keyInfo
>      xml:link   CDATA   #FIXED   'simple'
>      href       CDATA   #REQUIRED
> >
> >  <!ELEMENT sigValue (#PCDATA)>
> >  <!-- base64 encoded signature value -->
> >
> >  <!ELEMENT algorithms (c14nAlg, sigAlg)>
> >
> 
> 4.1- see comment 2.1 above.
> 
> >  <!ELEMENT c14nAlg ANY>
> >  <!ATTLIST c14nAlg
> >          type CDATA #REQUIRED >
> 
> 5.1- see comment 3.1 above.
> 
> >
> >  <!ELEMENT sigAlg ANY>
> >  <!ATTLIST sigAlg
> >          type CDATA #REQUIRED >
> >
> 
> 6.1- see comment 3.1 above.
> 
> >  <!ELEMENT digestAlg ANY>
> >  <!ATTLIST digestAlg
> >          type CDATA #REQUIRED >
> >
> 7.1- see comment 3.1 above.
> 
> >  <!ELEMENT signedAttributes (attributeData+)>
> >  <!-- must be at least one attributeData or omit the element-->
> >
> >  <!ELEMENT attributeData ANY>
> >  <!ATTLIST attributeData
> >          type CDATA #REQUIRED >
> 
> 8.1- I propose that you adopt a single model for algorithm parameters and
> attribute values. Either you allow ANY at the top level or you add an
> intermediary element for type identification.

I think in all cases I took the <xxx type="typeref"> ANY </xxx>
approach.  What is the problem with this?

> Option A: ANY top level
> 
> <dsig:c14nAlg type='http://xfdl.org/algorithms/c14n'>
>   <xfdl:exclude>
>     <xfdl:field href='comment'\>
>     ...
>   </xfdl:exclude>
> </dsig:c14nAlg>
> <dsig:attributes>
>   <dsig:SigningTime>1998-10-29T13:26-0500</dsig:SigningTime>
> </dsig:attributes>
> 
> Option B: With type element
> 
> <dsig:c14nAlg type='http://xfdl.org/types/alg/c14n'>
>   <dsig:parameter type='http://xfdl.org/types/prm/c14n'>
>     <xfdl:exclude>
>       <xfdl:field href='comment'\>
>       ...
>     </xfdl:exclude>
>   </dsig:parameter>
> </dsig:c14nAlg>
> <dsig:attributes>
>   <dsig:attribute type='http://w3.org/xmldsig/types/attr/sigtime'>
>     <dsig:date>1998-10-29T13:26-0500</dsig:date>
>   </dsig:attribute>
> </dsig:attributes>
> 
> To some extents, I like the first approach better for its compactness.
> BTW, notice that I prefer to encapsulate the datetime in a specific element.
> This provides for a stronger prototyping when use in parallel with an xml
> schema. This will also help canonicalization of basic data types.
> 
> >
> >  <!ELEMENT reference (resource)>
> >
> >  <!ELEMENT object (c14nAlg, content)>
> >
> 
> 9.1- Why should we specify a c14n algorithm? The content being encapsulated
> into the sigInfo element, it is implicitly processed during canonicalization
> of the sigInfo element.
> 
> I understand that an embedded content may have particular c14n requirements.
> But, allowing a different c14n algorithm within the sigInfo means that you
> have to define how you transition from one canonicalizer to the other or the
> way you expect to pipe the result of one into the other (without breaking
> the first one).

I don't like this either, but I still don't see a way around it. 
Perhaps the c14n crowd and suggest a solution, but I didn't see a way to
reconcile the content specific c14n and the general c14n of the
signature.  

> >  <!ELEMENT content ANY>
> >  <!ATTLIST content
> >        type CDATA #IMPLIED>
> >
> 
> 10.1- I suggest that you provide an encoding attribute. Also, we could have
> share the same definition between content, sigValue, digestValue...
> 

Why do you think we need flexibility in encoding?  I had hoped that we
could define a single encoding for all our top level items.

> >  <!ELEMENT resource (location, c14nAlg, digestAlg, digest)>
> >  <!ATTLIST resource
> >        type CDATA #IMPLIED>
> >
> 
> 11.1- This description does not make any sense from a data model. c14nAlg
> and digestAlg are not direct properties of a resource. A resource element
> should be limited to a locator and a digest (though we could have add
> attributes). c14nAlg, digestAlg are properties of the digest element:
> 
> <!ELEMENT resource (location, digest)>
> <!ELEMENT digest (c14nAlg, digestAlg, value)>
> 

OK.

> >  <!ELEMENT location (#PCDATA)>
> 
> 12.1- Location should rather be an xlink.
> 

OK - See comment to 3.1 above.

> <!ELEMENT location EMPTY>
> <!ATTLIST location
>      xml:link CDATA  #FIXED 'simple'
>      href     CDATA  #REQUIRED
> >
> 
> >
> >  <!ELEMENT digest (#PCDATA)>
> >  <!-- base64 encoded digest value -->
> >
> 
> 13.1- see comment 11.1 above

I'm not sure which point you're making.  My expectation is that we can
define a single encoding/representation for signature/digest values and
that it should be a base64 encoding of the algorithm defined value.

> >  <!ELEMENT manifest (resource+)>
> >  <!-- the manifest may be used as an object, or referred to by a
> >       reference; but is not part of the core signature syntax -->
> >   <!ATTLIST manifest
> >          id     ID      #IMPLIED>
> >
> 
> 14.1- May not have to be defined by this specification. Whoever needs
> something like that could reuse the resource element definition.
 
I expect that this should move into a "useful types" section in the
larger document along with bag-o-certs and other things.

> > 4. Example
> >
> > <signature id="foo">
> >    <signedInfo>
> >       <algorithms>
> >          <c14nAlg type="identity"/>
> >          <sigAlg type="rsaWithSHA-1"/>
> >       </algorithms>
> >       <object>
> >          <c14nAlg type="identity"/>
> >          <content type="manifest">
> >             <manifest id="bar">
> >                <resource>
> >                   <location> syntax.txt </location>
> >                   <c14nAlg type="identity"/>
> >                   <digestAlg type="sha-1"/>
> >                   <digest> a23bcd43 </digest>
> >                </resource>
> >             </manifest>
> >          </content>
> >       </object>
> >       <signedAttributes>
> >          <attributeData type="signingTime">Its midnight
> > here</attributeData>
> >       </signedAttributes>
> >    </signedInfo>
> >    <keyInfo type="keyName"> 3 </keyInfo>
> >    <sigValue> dd2323dd </sigValue>
> > </signature>
> >
> > 5) Processing:
> > Validation of an XML signature consists of the following steps
> 
> > a) canonicalization of the signed object based on c14n algorithm ID in
> > the object element.
> > b) c14n of the signedInfo element based on the c14n algorithm ID in
> > the algorithms element.
> 
> 15.1- the second canonicalization might actually break restrictions imposed
> by the first one unless you encode the embedded object. Consider the
> following:

See reply to 9.

>    xml-canon( ... | identity(xml-object) | ... )
> 
> > c) obtain the validation keying info from keyInfo or externally.
> > d) validate the sigValue based on the sigAlg ID in the algorithms
> > element and the key obtained in step c.
> >   - Digest calculation is performed over the canonicalized signedInfo
> >     element including start and end tags.
> >   - All signedAttributes are treated as opaque with respect to
> >     processing.
> 
> 16.1- If an xml schema is available, it might be interesting to canonicalize
> the attribute values... But this is a canonicalization problem and should
> not be addressed here.

The point is intended to be semantic, not c14n oriented.  The issue is
that the default behavior of the validation logic is to treat the
signedAttributes as a blob semantically and not interpret any of the
values/types (i.e. signedAttributes have no impact on default validation
processing).

> >   - If a reference element is present, recalculate digest on item
> 
> 17.1- In contradiction with what we have agreed upon in Boston...

See reply to 2.2 above.

> 17.2- Verification may happen in an environment that does have network
> connectivity...
> 
> >     referenced and compare to digest value in resource element.
> >
> 
> Sincerely,
> 
> Richard D. Brown
> Chief Software Architect - R&D
> Globeset, Inc. Austin, TX - U.S.

Dave
Received on Thursday, 12 August 1999 08:45:53 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT