RE: Some strawman ideas for a minimum DSig profile

Sorry for not responding last week. Things have been a little crazy recently.

It is certainly possible to encapsulate information in the PI into a new XMLDSig2 element. For example, it may be sufficient to specify the canonicalization and hash URI as attributes on the SignedInfo element so that hashing and canonicalization can start immediately.

I don't know if we can require applications to bundle a detached signature with an XML document in a minimum profile. I think a minimal profile would have uses beyond signing XML documents.

Kelvin


-----Original Message-----
From: Sean.Mullan@Sun.COM [mailto:Sean.Mullan@Sun.COM]
Sent: Thursday, August 21, 2008 10:23 AM
To: Kelvin Yiu
Cc: public-xmlsec@w3.org
Subject: Re: Some strawman ideas for a minimum DSig profile

Hi Kelvin,

In the proposal below, you write:

 > Konrad suggested using a PI at the F2F, and after looking at the
 > situation it is the only approach we could come up with that would
 > allow us to add semantics to the existing XMLDSIG schema without
 > breaking it.

However, in the examples below, the only time you would potentially
violate the XMLDSig schema is the insertion of the instruction between
the Signature and the SignedInfo element, which as you suggest is not
strictly necessary, and I agree. The other PIs are defined outside the
Signature element. Could the other PIs instead be encapsulated in a new
XMLDSig2 element?

It also occured to me that many of these minimal processing and
verification issues could be solved if the xml signature was always
stored in a separate xml document, and somehow safely associated or
packaged with what it is signing (like a zip file). Then a validator
could first parse/verify the signature, authenticate the signer, and
then validate the reference digests in the document(s) in a streaming
manner. Has anyone thought about that and making this a requirement for
a minimal profile?

--Sean

Received on Tuesday, 26 August 2008 01:00:59 UTC