RE: revised XML signature syntax from Oslo

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.

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

(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.)

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

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

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

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

> 3) Should there be an attribute field in each resource?

For convenience - YES. I don't feel that we should forbid them.

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

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

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

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

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

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


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

>

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.


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

Received on Tuesday, 20 July 1999 15:56:21 UTC