- From: <rhimes@nmcourt.fed.us>
- Date: Fri, 09 Apr 1999 11:01:39 -0700
- 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 UTC