Re: XMLP/XMLE Use cases and processing models

Hi David, thank you very much for this!

On Wednesday 06 February 2002 00:07, David Orchard wrote:
> Use case #1: SOAP decrypting intermediary
> The steps that the soap decrypting node might go through - assuming that
> every step passes validation - are:
> 1. Receive the message.
> 2. Validate the message with the encrypted content.
> 3. Decrypt the encrypted content.
> 4. Forward the message to the ultimate receiver.

For my own info, since the SOAP spec doesn't permit schema validation to be 
"imposed" on any SOAP node, do you think schema validation will be an 
integral part of SOAP processing in the near term?

> Questions
> ----------
> 1. I have anticipated that the intermediary has to know about the
> receiver schema and must expose the "merged" schema or a schema without
> the unencrypted credit card info to senders.  There is tight coupling
> there, but how else would the intermediary know which messages and which
> portions to decrypt?  Is this valid or does XMLE expect that a SOAP
> encrypting/decrypting intermediary would not know about the receiver
> schemas nor would it expose a "merged" schema?  This assumes the first or
> second solution in the processing requirements (3.2.2) [1].

I'd be interested in some of the xenc implementors thoughts on this since 
they best know how they want to process the data. However, given my 
ignorance I could see a few options:

1. The namespace is changed to indicate the change of the instance. This 
means you will have to have a namespace for every encrypted variant. This 
is probably fine for some applications (e.g., they know they only care 
about encrypting the credit-card data and nothing else so creating a new 
namespace and schema isn't very difficult.) Others may care less about 
validation and more about flexibility.
2. One "pre-scan's" the document looking for xenc:* elements. For example, 
during parsing (e.g., XNI [1]) one could flag such instances that trigger 
subsequent action.
3. The encryption is "baked" in to the application context. For instance, 
if you know that you'll be sending credit card data over an open network 
there needn't be choice between the credit card data in the plain and the 
encrypted form. The credit card is *always* sent encrypted and the 
recipient is always decrypted at the other end.
4. Meta-data is used to indicate the some of the data has been encrypted. 
For instance, to make option 3 a little more flexible, one could create a 
SOAP confidentiality header that indicates a decryptor actor with 
mustUnderstand="1".

In these options there are two issues: (1) how to know if parts of the 
document have been encrypted, (2) how to know which agent is supposed to do 
the decryption.

[1] http://xml.apache.org/xerces2-j/xni.html

> 2. Should the encrypted message use the same namespace name as the
> unencrypted message IF the schema does not allow the encrypted content? 
> I tend to think no, as URIs in namespace names tend to include versions
> and be very specific.  That means that there should be different
> namespace names for the encrypted versus unencrypted content.  In the
> processing requirements, 3.2.1,  there is no mention of whether
> preserving the original definitions namespace name should or should not
> be done.

This is an option, however I think changing the namespace (knowing what the 
new namespace would be) would have to be done by the app: it knows what the 
new namespace would be. In xenc we have specified that the xmlenc 
application in its "decryptor" role SHOULD support the ability to replace 
the EncryptedData with its decrypted form (the application MUST support 
this) in the original document but at this level we are only doing XML 1.0 
character replacement. The WG has been insistent that it's not up to the 
encryption application to do validation [2], nor any other Infoset cleanup 
-- in fact xenc doesn't address Infoset at all. xenc is [XML 1.0] based.

[2] 
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-Processing-Decryption
  4.3. The decryptor SHOULD support the ability to replace the
  EncryptedData element with the decrypted 'element' or element 
 'content' represented by the UTF-8 encoded characters. The
  decryptor is NOT REQUIRED to perform validation on the result
 of this replacement operation. 

  The application supplies the XML document context and identifies
  the EncryptedData element being replaced. If the document into which
  the replacement is occurring is not UTF-8, the decryptor MUST transcode
  the UTF-8 encoded characters into the target encoding.

However, this could pose problems for [3], that permits one to use xmldsig 
and xenc together such that you can create a signature that says, "in order 
to validate me decrypt all xenc:EncryptedData's except these {foo,...}." We 
haven't specified a way to say, "in order to validate me decrypt the 
xenc:EncrpytedData's first and also change my namespace." Also, if I have 
multiple encryptions in a compound document, there'd potentially a whole 
history of namespace I'd have to roll-back as I do the processing.

[3] http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html

> 4. Given the first solution in the processing requirements 3.2.2, a
> problem emerges.  The first recipient REQUIRES the encryption to be in
> force, and that the second recipient REQUIRES the credit card.  Yet the
> schema allows both.  Could the XMLE give guidance on when to use the
> first solution versus the second solution (separate schemas)?  Maybe this
> is one area where an XMLP/XMLE liaison could give guidance, ie "when
> using intermediaries and multiple validation phases, provide 2 separate
> schemas"

As I indicated in my option 3 above, *if* one was changing the namespace 
and creating a new schema, I'd prefer that there be two namespaces with two 
schemas instead of a single scheme that permits a choice between the 
plaintextform and encrypted form.
1. Two namespaces/schemas are unambiguous, this helps indicate what 
processing is expected.
2. If the structure of the data itself is important, one can keep the 
plaintext form of the schema in a secure zone of processing.

> 2.1 - the Name/ should be /Name.

Thanks, fixed in:
  http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
  $Revision: 1.128 $ on $Date: 2002/02/06 16:21:05 $


-- 

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

Received on Wednesday, 6 February 2002 11:58:04 UTC