"Note on XML Encryption" and Property

Two quick comments on [1].

>In the first case, reference directions (i.e., content-encryption keys to 
>encrypted contents or the reverse) are not serious because both are in the 
>same package. In the second case, contents encrypted with certain 
>content-encryption keys should reference them because an originator 
>encrypts contents with content-encryption keys held by specific recipients. 
>In the last case, contrarily, content-encryption keys should reference 
>contents encrypted with them because a recipient who has certain 
>content-encryption keys tries to get contents encrypted with them. 
>Considering these scenarios, content-encryption keys and contents encrypted 
>with them should be able to reference each other.

XML Signature uses a simple URI-reference to identify referants. However the 
scenario above presents a situation that doesn't appear in any MANDATORY 
feature of Signature: bi-directional links. (It only happen in Signature 
where one is signing a Signature Property, which points to the Signature it 
applies to). However, given XLinks subsequent maturity and the potential of 
XLink processing [2], might Extended Links be of use to us?

>[Definition: An extended link
>is a link that associates an arbitrary number of resources. The participating
>resources may be any combination of remote
>and local.]
>The only kind of link that is able to have inbound and third-party arcs
>is an extended link. Typically, extended linking elements are stored 
>separately
>from the resources they associate (for example, in entirely different 
>documents).
>Thus, extended links are important for situations where the participating
>resources are read-only, or where it is expensive to modify and update them
>but inexpensive to modify and update a separate linking element, or where
>the resources are in formats with no native support for embedded links (such
>as many multimedia formats).
>http://www.w3.org/TR/xlink/#extended-link

As an aside, I'm glad your not touching time stamps and such, but providing 
a bucket. But for parallelism with Signature since we will likely have 
instances of both these element types together (though SignatureProperties 
is one of my least favorite element types <smile>) should you use 
EncryptionProperties and EncryptionProperty?

[1] 
http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/att-0002/01-note.html
[2] http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0005.html

__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Friday, 27 October 2000 19:17:49 UTC