[Bug 28468] New: Protected Document Exchange spec is broken, suggests only document encryption instead of using signatures (using the Authors Private Key, not the Servers) inside encryption to prevent Content altering

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28468

            Bug ID: 28468
           Summary: Protected Document Exchange spec is broken, suggests
                    only document encryption instead of using signatures
                    (using the Authors Private Key, not the Servers)
                    inside encryption to prevent Content altering
           Product: HTML WG
           Version: unspecified
          Hardware: PC
               URL: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec
                    /Overview.html#protected-document
                OS: Linux
            Status: NEW
          Keywords: erratum
          Severity: critical
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: obscurity0072@gmail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

In my honest opinion it is risky to solely trust on a TLS Connection to achieve
full transport layer security. Imagine an Attacker gathers access to the
Servers Domain / DNS-Entries, Server Hardware (the content signing Private Keys
SHOULD NEVER BE placed directly on the Server to lower a complete Security
Breach) or successfully executes a similar Attack. Exchanged Document SHOULD BE
signed by the author and verified by the requesting Party. The Signature (using
the servers own Private Key) SHOULD BE added to the Plaintext, otherwise
(adding it outside the encryption) it may be manipulated when the connection is
compromised.

Allow me to suggest the following Procedural Improvements:

Server
1. Content is signed with the Authors Private Key and available on the server,
ready to be further processed
2. A random one-time encryption key is ... 
... generated ...
... signed using the servers Private Key ...
... and encrypted with the User Agents Public Key
2. Content and Signature are encrypted using the previously generated one-time
encryption key resulting as the Ciphertext
3. Signed & encrypted one-time encryption Key and Ciphertext are sent to the
User Agent via TLS

User Agent
1. Receives Signed & encrypted one-time encryption Key and Ciphertext
2. User Agent decrypts one-time encryption Key and verifies Signature (Servers
Public Key)
3. Try to decrypt the Ciphertext with the previously decrypted key, when the
signature verification (Authors Public Key) was successful
4. Verify signature found in the Ciphertext - Continue ONLY, when verification
was successful
5. Display Document

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Sunday, 12 April 2015 07:18:30 UTC