revised XML signature syntax from Oslo

Here's a quick summary of the proposed revised XML signature syntax from
this week's Oslo meetings along with some of the related open questions
(some from the meeting, others from subsequent discussion).  The goal
from that meeting is to create a document describing the core
signature syntax and processing rules and a companion document(s)
specifying attributes, usage scenarios, algorithms, etc.  These might be
re-integrated once stable.

Based on discussion here, the plan is to produce a concise draft that
focuses on describing the core syntax and processing rules.  The syntax
in this note is as it appeared on the slide, we'll clean it up for the
draft.

<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>

Processing
The manifest element contains zero or more resource elements.
The signatures elements contains one or more signature elements.

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.  

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
- obtaining the validation key(s) based on the KeyingInfo field (note:
issues of key suitability, trust management, certificate validation, and
time context are all external to the core specification.  Attributes may
be defined to carry timestamps, additional semantics, etc.; however,
their processing is not part of the core specification.)
- validating the signature (process based on algorithm in sigInfo field)
- the manifest is otherwise treated as an opaque block
- all attributes are, by default, treated as opaque

Canonicalization issues
- should have a default algorithm for canonicalizing the manifest and
siginfo blocks (as contrasted with multiple algorithms for
canonicalizing the resources identified in the manifest)
- inclusion of attributes in the sigBlock will require defining
canonicalization for each attribute type

Open questions (with possible directions in parens)
1) Should the algorithm/value pairs for hash and signature be grouped
(e.g. <hash> <hash-alg/> <hash-value/> </hash> vs <hash-alg/>
<hash-value/>)? 
(leave as separate elements)
2) Should there be an attribute field in SigInfo? 
(strong preference for yes)
3) Should there be an attribute field in each resource? 
(uncertain preference - but if not there should be a content type
somewhere)
4) If there is an attribute field, should it be a single bucket or a set
of type/value pairs? 
(set of type/value pairs)
5) What should the structure of keyingInfo be and what mandatory types
should be supported? 
(proposal is a type/value pair with initial supported types being
keyID/name and issuerSerial) 
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)
7) What should the validation rules be for multiple signatures?
(probably OK if any is OK, subject to how one chooses a signature;
perhaps an application issue where application chooses a signature)
8) Do we need or want any special support for signed receipts, or can it
be handled as an application issue? 
(treat as an application issue)
9) Which elements should contain ID and/or type info? 
(manifest and signature; perhaps sigBlock)
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) 
11) Should we have provisions for one-pass processing?

Received on Monday, 19 July 1999 07:23:33 UTC