I see, but I have a question about the following sentence:
>If this signature does not verify
>with the ciphertext still encrypted it should be considered tampered with
>(although at a later date it may be untampered through the removal of the
>encryption).
According to [1], encryption after signing requires signature value to be
encrypted. If doing so, we don't have to try to verify signature. This is
because we can see whether signature contains encrypted data by examining
whether signature value is encrypted.
Anyway, this solution raises another problem. If signature contains
multiple encrypted data, how do we distinguish encrypted data before
signing and ones after signing? This can be solved by placing
EncryptedReference element defined in [2] in ds:Signature element. [2]
says as follows, but I believe this element may appear within
ds:SignatureProperty element not within ds:Reference element.
>3.7 The EncryptedReference element
>
>The EncryptedReference element provides a way to indicate
>that data, over which an XML Digital Signature (xmlns:ds) has
>been computed, was encrypted. In essence, it indicates the data
>should not be decrypted prior to signature verification.
>This element may only appear within a ds:Reference element
>within a ds:Signature element. ...
[1] http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0072.html
[2]
http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html
Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com
From: "Joseph Ashwood" <jashwood@arcot.com>@w3.org on 2001/01/25 04:05 AM
Please respond to "Joseph Ashwood" <jashwood@arcot.com>
Sent by: xml-encryption-request@w3.org
To: <xml-encryption@w3.org>
cc:
Subject: Re: Signing and Encryption
From: "Takeshi Imamura" <IMAMU@jp.ibm.com>
> Joseph,
>
> >The attached signatures are a different matter, it needs to be verified
> >that the granularity of the encryption is such that if the data to be
> >signed is signed at a higher level the encryption needs to take place at
> >the higher level. The lower level case we don't need to concern
ourselves
> >with, we will afterall be encrypting the signature along with it
> >(provided it is attached).
>
> Sorry, but I didn't follow these sentences. Could you explain what
"higher
> level" and "lower level" mean with examples?
Certainly I can, you can easily consider them as outer and
inner.Specifically I meant (I am using encrypted and signed tags because I
feel they are clear in this context):
<Level 1>
<Encryption Key data>...</Encryption Key data>
<encrypted>
<signed>
</signed>
</encrypted>
</level 1>
Is clear because the signature tags cannot be viewed before decryption, so
there is no ambiguity.
On the contrary:
<level 1>
<signed>
<encryption key data></>
<encrypted>
</encrypted>
</signed>
</level 1>
May or may not be a tampered system. It is not as clear because the
contents
of the encrypted tags may have been encrypted before or after the signature
took place. I do not consider this ambiguous because the presence of the
encrypted key data tags shows that the intent was for the encrypted data to
be signed (as opposed to the clear data). If this signature does not verify
with the ciphertext still encrypted it should be considered tampered with
(although at a later date it may be untampered through the removal of the
encryption).
Further
<level 1>
<encryption key data></>
<signed>
<encrypted>
</encrypted>
</signed>
<level 1>
Is an ambiguous state. Because of the issues with unsigned encryption keys
governing signed ciphertext, this state should be considered invalid, and I
believe it should be noted as such. The other possibility of having a
partial signing before partial encryption is completely ambiguous, and the
creation of such a beast would (I think) violate the signature spec making
the signature invalid.
I suppose we could simply set the rule that if signature tags are visible
they take precedence. I think that would be a simple enough convention, and
would remove all ambiguity.
Joe