Re: [egov] "Dry" and "Wet" signatures - A definition

[Duane Nickull <dnickull@adobe.com>]

Anders et al:

I will suggest you may want to think about this differently.  Many 
signature mechanisms work in a way that mitigate the problem you are 
hinting at without having to make this distinction.  Attempting to make 
two classes of signature for mutable vs. immutable content is flawed IMO 
since you would have to fully understand every possible way a document 
or content *might* be modified.  This is simply beyond the grasp of any 
group of people since there are so many variables (metadata changes, 
versions, file names etc.) plus you are relying on third party vendor 
statements to be 100% accurate.

A better methodology is to stipulate that at the time of signing, a hash 
is made of the exact content using state of the art algorithms and if 
the content later changes, the signature block is flagged to indicate 
that there have been changes since it was signed and let the actor 
decide how they want to proceed.  Adobe Acrobat's signature method works 
this way.  If for any reason, any of it changes, the signature 
presentation is flagged to indicate such.  This method was perfected by 
Adobe, RSA, Entrust, VeriSign, GeoTrust, and ActivCard.  There is a lot 
of information available on this from our website:
http://www.adobe.com/security/digsig.html

The attached file was signed, then changed to demonstrate this.  If you 
go to the signature field, you can click on the triangle symbol by the 
green check mark.  It will open a dialog window that tells you the 
document is still the same, but the values themselves have been altered 
since (this is important to distinguish between).  If you select 
"signature properties", you get even more information.

Under the summary, the window will note any changes.  If you select the 
"document" tab, a modification details window appears.  There is a 
button that allows you to generate a change log to compute modifications 
subsequent to signing the document.  You can also select 'View Signed 
Version' to see the version that was signed and compare the two documents.

I agree that mutability detection algorithms are complex.  Our mechanism 
was the result of numerous companies collaborating with customers to 
ensure all legal and technical problems were solved.  This was a 
somewhat lengthly process.

Best wishes.

Duane

Anders Rundgren wrote:

> Dear list,
> In a previous posting where I referred to some discussions concerning 
> a possible Web Sign standards effort within OASIS, "Dry" and "Wet" 
> signatures were mentioned.  Several off-list messages indicate that 
> these terms need a proper explanation.
>
> This comes to no big surprise as these terms have actually been coined 
> by myself in the absence of an established terminology in this 
> actually rather virgin field.
>
> *"Wet" web-signatures
> *An editable document, be it an MS Word document or an HTML form with 
> edit fields, radio buttons etc. is filled-in and signed by the user 
> and then sent to the service provider.
>
> *"Dry" web-signatures*
> The user is (after an arbitrary interactive process with a service 
> provider), presented, a static (read-only) document and is requested 
> to sign it in order to indicate "acceptance".  Since the document 
> actually comes from the service provider, the result sent to the 
> service provider is typically only a detached signature of the shown 
> document.
>  
> *Further comments*
> These schemes represent two different schools, one which tries to 
> mimic the existing paper form world, while the other scheme is more 
> aligned with how the web is currently used.
>  
> *Implications*
> Superficially these schemes may appear similar, but that is indeed not 
> the case; there is probably a 10-to-1 difference in complexity unless 
> you restrict "Wet" signatures to only support a single document 
> format.  The reason for this increase in complexity is that each 
> document format has its own native signature format (or has no defined 
> signature format at all), as well as its own input data validation 
> scheme.  Using "Dry" detached signatures, you can achieve the same 
> thing as S/MIME does, namely document format independence with respect 
> to the signature process (except for some trivial canonicalizations).  
> Possible input data validation is assumed to have been carried out in 
> earlier phases of a web session, using standard web methodology.  
> There are numerous other implications as well concerning the use of 
> "Wet" and "Dry" signatures, but these are far outside the range of an 
> e-mail posting.
>  
> Anders Rundgren
> Working for a major US computer security company but here acting as an 
> individual

Despatch-Advice-w-Button-signed.pdf