W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

Re: Signing and Encryption

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Thu, 25 Jan 2001 15:37:06 +0900
To: "Joseph Ashwood" <jashwood@arcot.com>
Cc: <xml-encryption@w3.org>
Message-ID: <OF7DF23F1C.4A5B28EC-ON492569DF.001EFFCB@LocalDomain>

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

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

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>
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
> >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
> 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>
</level 1>

Is clear because the signature tags cannot be viewed before decryption, so
there is no ambiguity.

On the contrary:
<level 1>
        <encryption key data></>
</level 1>

May or may not be a tampered system. It is not as clear because the
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

<level 1>
    <encryption key data></>
<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.
Received on Thursday, 25 January 2001 01:37:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:01 UTC