- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Tue, 28 Nov 2000 15:21:31 -0500
- To: david.solo@citicorp.com, MARUYAMA@jp.ibm.com, hal@finney.org
- Cc: xml-encryption@w3.org
A nice solution would be if you could nest these things and just unwrap them: <Signature> <Encrypted> <Signature/> <Encrypted/> </Signature> However, since we permit detached Signatures and Encryption we might need some sort of attribute that describes which processing level you are in. (layer="0" type decorations happen which is ugly...) So Hiroshi recommended (1) process signatures first and always decrypt all elements unless a SignatureProperty says not to. Hiroshi mentioned this really isn't a transform and could perhaps be represented as a SignatureProperty, but I think it is a transform of sorts. There's an implicit transform added to the Transforms semantic to always try to decrypt first unless one is told not to. I have concerns about this because it alters the semantics of Transform (implicit meaning, countered in a SignatureProperty) which means a change to the Signature spec, chasing these fragments/links, and the data model can get pretty complex. Hal suggested that Signatures over data to be encrypted also be encrypted (I presume this is the case for document for which only parts of which are encrypted). Any time a Signature is visible in an instance, it can be validated without concern for encryption. I think I like this. (Does this mean the Signature is part of that EncryptedData under the same key, or there are two EncryptedDatas under the same key (or even different keys?)). My concern is that it seems to disallow arbitrarily complex assertions, but then again, that's probably a positive for many reasons.... As an aside, I was thinking along the line of an inverse of Hiroshi: always process Signature first and decrypt only where instructed to. Unfortunately, subsequent encryption will invalidate the Signature. If the author wishes to ensure that this does not happen, he needs to provide a decrypt transform. If someone other than the author wants to encrypt, he violates the Signature and things get confusing from what I can see. Regardless here examples under the policy that (1) do Signatures first and any of the decryptions they specify and then (2) decrypt all others. <!-- XML Instance --> <eg:root ns:eg="http://example.org/instance"> <eg:a>...</eg:a> <eg:b>...</eg:b> <eg:c>...</eg:c> <eg:e>...</eg:d> </eg:root> <!-- author: encrypt b then sign root and encrypted element via enveloped signature --> <!-- consumer: validate signature then decrypt --> <eg:root ns:eg="http://example.org/instance" ns:xmlenc="http://www.w3.org/2000/11/xmlenc#" ns:xmldsig="h&dsig;> <eg:a>...</eg:a> <xmlenc:EncryptedData> ab323432c.... </xmlenc:EncryptedData> <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo> <eg:c>...</eg:c> <eg:e>...</eg:d> <dsig:Signature > <dsig:SignedInfo> <dsig:Reference URI=""> <dsig:Transforms> <dsig:Transform Algorithm="&dsig;enveloped-signature"/> </dsig:Transforms>... </dsig:SignedInfo>... </dsig:Signature> </eg:root> <!-- author: sign root then encrypt b --> <!-- consumer: validate signature which automagically decrypts b in order to restore the root as signed --> <eg:root ns:eg="http://example.org/instance" ns:xmlenc="http://www.w3.org/2000/11/xmlenc#" ns:xmldsig="h&dsig;> <eg:a>...</eg:a> <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"> ab323432c.... </EncryptedData> <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo> <eg:c>...</eg:c> <eg:e>...</eg:d> <dsig:Signature ns:xmldsig="h&dsig;"> <dsig:SignedInfo> <dsig:Reference URI=""> <dsig:Transforms> <dsig:Transform Algorithm="&xmlenc;decrypt"> <xmlenc:Decrypt data="#b"/> </dsig:Transform> <dsig:Transform Algorithm="&dsig;enveloped-signature"/> </dsig:Transforms>... </dsig:SignedInfo>... </dsig:Signature> </eg:root> <!-- author: encrypt b, sign root, encrypt e --> <!-- consumer: validate signature which automagically decrypts e, decrypt b --> <!-- this means any subseqent encryptions need to be part of the signature, kind of stinks --> <eg:root ns:eg="http://example.org/instance" ns:xmlenc="http://www.w3.org/2000/11/xmlenc#" ns:xmldsig="h&dsig;> <eg:a>...</eg:a> <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"> ab323432c.... </EncryptedData> <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo> <eg:c>...</eg:c> <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"> ab323432c.... </EncryptedData> <xmlenc:EncryptionInfo Id="e">...</xmlenc:EncryptionInfo> <dsig:Signature ns:xmldsig="h&dsig;> <dsig:SignedInfo> <dsig:Reference URI=""> <dsig:Transforms> <dsig:Transform Algorithm="&xmlenc;decrypt"> <xmlenc:Decrypt data="#e"/> </dsig:Transform> <dsig:Transform Algorithm="&dsig;enveloped-signature"/> </dsig:Transforms>... </dsig:SignedInfo>... </dsig:Signature> </eg:root> <!-- author: encrypt b, sign root, encrypt e, sign root --> <!-- consumer: validate signature which automagically decrypts b, validate signature which automagically decrypts e --> <!-- Again, this demonstrates a counterintuitive fact that it's the subsequent encryptions that have to be represented in the signature --> <eg:root ns:eg="http://example.org/instance" ns:xmlenc="http://www.w3.org/2000/11/xmlenc#" ns:xmldsig="h&dsig;> <eg:a>...</eg:a> <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"> ab323432c.... </EncryptedData> <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo> <eg:c>...</eg:c> <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"> ab323432c.... </EncryptedData> <xmlenc:EncryptionInfo Id="e">...</xmlenc:EncryptionInfo> <dsig:Signature ID="first" ns:xmldsig="h&dsig;> <dsig:SignedInfo> <dsig:Reference URI=""> <dsig:Transforms> <dsig:Transform Algorithm="&xmlenc;decrypt"> <xmlenc:Decrypt data="#e"/> </dsig:Transform> <dsig:Transform Algorithm="&dsig;enveloped-signature"/> </dsig:Transforms>... </dsig:SignedInfo>... </dsig:Signature> <dsig:Signature ID="second" ns:xmldsig="h&dsig;> <dsig:SignedInfo> <dsig:Reference URI=""> <dsig:Transforms> <dsig:Transform Algorithm="&xmlenc;decrypt"> <xmlenc:Decrypt data="#e"/> </dsig:Transform> <dsig:Transform Algorithm="&xmlenc;decrypt"> <xmlenc:Decrypt data="#b"/> </dsig:Transform> <dsig:Transform Algorithm="&dsig;enveloped-signature"/> </dsig:Transforms>... </dsig:SignedInfo>... </dsig:Signature> </eg:root> __ Joseph Reagle Jr. W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/People/Reagle/
Received on Tuesday, 28 November 2000 15:23:24 UTC