W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

Re[4]: MIME Blobs

From: <rhimes@nmcourt.fed.us>
Date: Fri, 09 Apr 1999 11:01:39 -0700
Message-Id: <9904099236.AA923677337@nmcourt.fed.us>
To: <w3c-xml-sig-ws@w3.org>
Cc: <xml-dsig@globeset.org>
     
     Thanks, Richard, this approach pulls me out of the bog.  If there is 
     unfinished business, it is whether to recommend this solution for the 
     anticipated XML S/MIME packaging effort.
     
     Rich

______________________________ Reply Separator _________________________________
Subject: RE: Re[2]: MIME Blobs  
Author:  <rdbrown@GlobeSet.com> at ~Internet
Date:    4/8/99 5:20 PM


Rich,
     
Please see comments below.
     
>
> By "we" are you referring to the DSig workgroup? 
>
     
By "we" I meant the XML/Internet/... community. My feeling is that XML-based 
S/MIME-like packaging is one of the many potential applications of the 
forthcoming XML-DSIG standard. Therefore, this may have to be addressed 
separately. However, it may be worth considering the problem (not 
necessarily the solution exposed before) as we (Dsig WG) work on the 
specifications.
     
> However, in order to authenticate the
> signature, either the original document of the originator
> would have to be URI-addressable ... or an unencoded copy could 
> be created locally and rehashed.
     
If we were to promote the solution exposed before, validation of the message 
would consist of verifying the signature that is applied to the Manifest 
(XML-DSIG standard) and then verifying that for each resource element 
contained in the manifest it exists a package element of origin equals to 
"the location reference of the resource" and value such that its digest 
after adequate decoding equals the digest value attached to the resource 
element being considered (application layer).
     
>  If this
>      is the case, and if I understand the problem, it shouldn't be
>      difficult to add an attribute to the hash specifying that it is 
>      performed on the unencoded blob rather than an XML-based
> hash.
     
Actually, it is not that simple. What would be the meaning of this attribute 
in a broad sense? Recall that resources are not limited to package elements. 
They may also refer to external resources or other XML elements. So, what 
would be the "unencoded blob" of an element of type X or an external PDF 
file. Does this mean that XML-DSIG should consider the package element 
differently? I do not really know and will probably argue that it should not.
     
     
>  BTW,
>      is the content of the <resource> elements below the 
> document or the
>      hash?
     
This is the hash of the raw material (external unparsed entity).
     
Sincerely,
     
Richard D. Brown
Software Architect -R&D
GlobeSet, Inc. Austin TX - U.S.
     
     
Received on Friday, 9 April 1999 13:02:42 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 11:28:03 EDT