Re: revised XML signature syntax from Oslo

Richard,

Thanks for the comments, my thoughts inline below; although I think
we're generally in sync.

Richard D. Brown wrote:
> 
> David,
> 
> Please see comments inserted below.
> 
> >
> > <SigBlock>
> >   <Manifest>
> >     <Resource>
> >       <location/>
> >       <C14N-alg/>
> >       <hash-alg/>
> >       <hash-value/>
> >       <attributes/>
> >     </Resource>
> >        .
> >        .
> >        .
> >   </Manifest>
> >   <Signatures>
> >     <Signature>
> >       <SigInfo>
> >         <KeyingInfo/>
> >         <C14N-alg/>
> >         <sig-alg/>
> >         <attributes/>
> >       </SigInfo>
> >       <SigValue/>
> >     </Signature>
> >        .
> >        .
> >        .
> >   </Signature>
> > </SigBlock>
> 
> OK, this just reflects the syntax as it appeared on the slide. However,
> before people get used to this syntax description, I urge that we adopt an
> element and attribute naming convention. We should not mix
> upper-case-separator and underscore (i.e. SigInfos vs. sig-alg) and should
> either adopt or ban contractions.

No problem - I think we agreed on this before.  The next revision will
adopt stricter conventions.

> > A signature is calculated by:
> > - canonicalizing the manifest and siginfo blocks (including the start
> > and end tags)
> > - hashing the concatenation of the two (see open question 6)
> > - calculating the signature from the hash.
> 
> I do not want to start the signature/hash battle again, but I would rather
> not refer to a signature as the encryption of a digest. A signature is
> produced by a signature algorithm and there are signature schemes that make
> use of a one-way hash function during computation. Therefore, the previous
> paragraph should be:
> 
> - canonicalization of the Manifest and SigInfo blocks (...) - this shall
> result in the production of two octect-strings.
> - calculation of the signature value from the concatenation of the canonical
> representations of the Manifest and SigInfo elements.

Agreed.

> (Alternatively, we could promote the concatenation of the Manifest and
> SigInfo elements, canonicalization of the two, and signature of the
> canonical representation. To ensure adequate XML nesting, which could be
> required by the canonicalizer, we may have to encapsulate the two elements
> in a common root element.)

I like the first proposal better.  I think the second (making the
calculation sign(wrap(canon(manifest, siginfo) ) is unnecessary.

> >
> > The signature is validated by:
> > - canonicalizing the manifest and siginfo blocks as before (checking
> > against the C14N alg ID in the sigInfo)
> > - hashing the concatenation of the two blocks using the hash algorithm
> > in the siginfo block
> 
> Refer to previous comment.

OK.

> > Canonicalization issues
> > ...
> > - inclusion of attributes in the sigBlock will require defining
> > canonicalization for each attribute type
> 
> Does this mean that you would like to restrict the type of the attributes
> that could be inserted into a sigBlock?
> Personally, I would strongly argue against such limitation.
> 
> Canonicalization is conceivable only if we limit attribute values to basic
> data-types (defined by the specs) or a sequence of such basic data-types.
> Alternatively, we can promote the use of xml data-types (a.k.a. DCD) and
> adopt a data-type-awared canonicalizer.

What I think we might need to do is indicate that for guaranteed
interoperability, the must implement set would be limited to basic
types.  If an application wanted to insert more complex attributes at
this level (rather than as resources), they would risk
interoperability.  Further we could recommend that, in general,
attributes should be treated as resources. 

> >
> > Open questions (with possible directions in parens)
> > 1) Should the algorithm/value pairs for hash and signature be grouped
> 
> YES. From a data model standpoint, the digest (the pair hash-algo-id, digest
> value) is a well-defined property of a Resource. Conversely, the hash
> algorithm by itself is NOT.

Once we agree on the content, we can sort out the best grouping, but I
agree with both this and Peter's comments about logically grouping
elements into aggregates.

> > 2) Should there be an attribute field in SigInfo?
> 
> YES - If not, it would make almost no sense to group several signatures into
> a single SigBlock. Adding a signing-time to a signature would require the
> creation of an independent signing-time-attribute resource, which should be
> referred by the Manifest of the signature. Thence, each signature would
> require its own Manifest.

I think there's strong consensus on attributes in SigInfo.  Though see
also my comment to your general issue below [For those who don't want to
scroll, I agree that limiting the structure to one signature per
SigBlock makes a lot of sense.]

> > 3) Should there be an attribute field in each resource?
> 
> For convenience - YES. I don't feel that we should forbid them.

I don't really see the need for this (other than content type), but if
there's consensus for allowing them, I don't have any strong objection.

> > 4) If there is an attribute field, should it be a single
> > bucket or a set of type/value pairs?
> 
> What do you mean by single bucket?
> 
> I would suggest that Attributes be of ANY type and that we define a set of
> 'reserved' attribute types in the XMLDSIG DTD (i.e. SigningTime,
> ContentType, ContentEncoding, ContentLanguage...)

Just a structural question of whether <Attributes/> is a a collection of 
<Attribute/> of which each is a type/value (i.e. ANY) pair or whether
there's some intermediate level of aggregation.  My preference is a
simple collectin of Attribute.  I agree with your latter point.

> > 5) What should the structure of keyingInfo be and what mandatory types
> > should be supported?
> 
> Exactly like attributes. I suggest that KeyInfo be of ANY type and that we
> define a set of 'reserved' types.
> 
> > (proposal is a type/value pair with initial supported types being
> > keyID/name and issuerSerial)
> 
> I think that we should distinguish between signer and relying party
> credential or key. If not, this will preclude the use of DH-like algorithms.
> Also, I suggest that we keep the KeyAgreementAlgorithm element proposed
> previously.

I agree with the structure; however this is one place that I believe we
must have mandatory to implement options and the two I'd propose are
name/keyID and issuer-serial.  As to whether signer and RP credentials
are visible at the top level, or as part of the ANY definition, is I
think still open.  My strong feeling is that it should be part of the
ANY definition since the relation between the two, the structure, etc.
are all quite algorithm/context specific and by nesting it, we allow
both flexibility in the structure and simplicity for those who don't
need to deal with key agreement scenarios.

> > 6) Rather than concatenating the manifest and sigInfo, should
> > we include
> > the hash(C14N(Manifest)) as an attribute in sigInfo?
> > (this potentially simplifies calculation if there are multiple
> > signatures)
> 
> if you use a Resource instead of the digest, you get back to the original
> proposal that contained only one resource element and proposed a Resources
> for grouping purposes only. In such circumstances, the signature element
> applies to a single element value, which could be a list of resources. I
> really feel that this approach keeps the data model very simple and should
> easily translate into RDF (see general comment at the end).

I don't think I understand your comment; however, in light of the
comment above about general signature vs explicity hash and the possible
simplification with a single signature, I think we can drop
the idea of carrying the hash in an attribute.

> > 7) What should the validation rules be for multiple signatures?
> 
> Should be left to the application level. In fact, this is the application
> level that should indicate the signature value or values to be verified.

Yes (as I'd said in the original note), but see below.

> > 8) Do we need or want any special support for signed
> > receipts, or can it be handled as an application issue?
> 
> An application of XMLDSIG on its own.

Again, as in the original note, I agree.

> > 9) Which elements should contain ID and/or type info?
> 
> Counter-signature will require at least an ID on the Signature element. BTW,
> notice that the counter-signature will apply to the Signature element, which
> does not encapsulate nor refer to the Resource(s) being signed - The
> Signature is supposed to be nested in a SigBlock that contains the Manifest
> element (see general comment at the end).

I think we still need some more work on the ID linkages.

> > 10) Are there other generally useful types we should define (e.g.
> > certificate, algorithm ID, ...)?
> > (we should probably define a way to move bags of certs, CRLs, and ACs
> > around; definitely need to agree on a way to represent cryptographic
> > algorithm IDs and parameters)
> 
> What's about mixing Joseph proposal (use of a URL) and the previous
> Algorithm definition.
> This would lead to something like:
> 
> <!ELEMENT dsig:Algorithm (dsig:Parameter*)>
> <!ATTLIST dsig:Algorithm
>   xmlns:dsig CDATA   #FIXED %xmldsig.dtd;
>   xml:link   CDATA   #FIXED 'simple'
>   id         ID      #IMPLIED
>   href       CDATA   #REQUIRED
> >
> 
> <!ELEMENT dsig:Parameter ANY>
> <!ATTLIST dsig:Parameter
>   xmlns:dsig CDATA   #FIXED %xmldsig.dtd;
>   type       CDATA   #REQUIRED
> >
> 
> > 11) Should we have provisions for one-pass processing?
> 
> I think this might be wise if we want to support small-footprint devices.
> However, I would suggest that we investigate usage of a PI instead (cf.
> comment #99061601) of the dsig:eval global attribute.

I don't have any strong feelings on this, I'd like to hear other
thoughts?

> 
> General comment:
> ----------------
> 
> More I think about it, less I am convinced of the benefit derived from
> grouping multiple signatures in a SigBlock. This complicates a lot the data
> model without providing any obvious benefit. Conversely, I think that
> regrouping originator and recipient info in a single KeyInfo element is
> wise.

I've come to the same conclusion.  As I tried to construct rules for
dealing with multiple signatures in a SigBlock, I realized the best bet
was not to do it (instead have multiple SigBlocks).  From an application
standpoint, this seems much cleaner rather than having to somehow tell
the validator what to do and which signature to process.  If there's no
strong suggestions, I'd suggest we move forward for now with a single
signature element (actually just drop the <Signatures> wrapper.

> Richard D. Brown
> Software Architect - R&D
> Globeset, Inc. Austin, TX - U.S.

Dave

Received on Tuesday, 20 July 1999 17:48:12 UTC