Re: Decryption Transform processing question

r/reagle@w3.org/2002.06.06/13:21:22
>On Tuesday 04 June 2002 11:58 am, Takeshi Imamura wrote:
>> I don't think that using an explicit Type attribute value is a good
>> proposal.  It is not an encryptor but a signer that decides whether an
>> EncryptedData element should be decrypted.  
>
>Instead of a type, how about a specific parameter (e.g., &decrypt;#super) 
>(BTW: Do you accept the proposal that we support &decypt;bnary and 
>&decrypt;XML?)

A signer cannot predict how encryption will be performed so
it cannot specify that superdecryption should occur. This
is similar to my (bad) XMLType proposition.

The signer uses Except to specify what was encrypted when
it generated the signature, and thus what it expects to
remain encrypted during verification.

After this point, it is up the encryptor to make sure that
things stay in shape. Or, the encryptor neither knows nor
cares, and if things go wrong, the signature fails and the
document is tossed.

There are two options:

1) Automatic superdecryption

   The encryptor mindlessly encrypts data. By mindless, I mean
   that it is pays no mind to, or is ignorant of, any signature(s)
   over the data.

   The verifier recursively decrypts unexcepted EncryptedData,
   subject to the hack that barename XPointer exceptions get
   dereferenced into these recursive node sets, and the knowledge
   that if the encryptor has mindlessly encrypted data that
   require document-relative or external same-document references
   to evaluate, or has encrypted data that are the target of
   a full XPointer or signature reference, decryption will fail.

   This is compatible with my last proposal. Just add recursion
   text and eliminate the SuperEncrypted Type for EncryptedData.

2) Encryptor-specified superdecryption

   a) The encryptor mindlessly encrypts data but never encrypts
      existing EncryptedData, avoiding the superdecryption
      problem. This is indifferent to 1.

   b) The encryptor encrypts data, but is mindful to only
      super-encrypt exceptional EncryptedData. These will
      not then be recursively decrypted.

   c) The encryptor super-encrypts unexceptional EncryptedData,
      mindful of the potential problems. It indicates this by
      using the SuperEncryptedData Type, and utilizing
      mechanisms to overcome the problems if necessary.

      i) Reform the EncryptedData to operate in its new
         context.
      ii) Use encryption properties to identify how
         references from internal data will resolve out
         to the original parent document.
      iii) Use encryption properties to identify how
         references from external data will resolve into
         the internal data.
      iv) Do nothing and hope for the best.

      These mechanisms are not practical in the general case.
      However, my assertion is that this type of operation
      won't be arbitrarily performed; it will be performed
      by a security-conscious application in a specific
      context.

So our options boil down to: 1) dumb encryptor, things may go
wrong, blah happens. 2) smart encryptor, things may go wrong
but there are potential mechanisms to overcome this.

There are fine, defensible arguments either way.

Merlin

Received on Thursday, 6 June 2002 14:00:28 UTC