[Bug 21880] New: Certificate management is underspecified

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

            Bug ID: 21880
           Summary: Certificate management is underspecified
    Classification: Unclassified
           Product: WebRTC Working Group
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebRTC API
          Assignee: public-webrtc@w3.org
          Reporter: martin.thomson@skype.net
                CC: public-webrtc@w3.org

The current specification is silent on how peer certificates are managed.

Current implementations appear to mint a new certificate for every new
connection.  This is good from a privacy perspective because it ensures that no
two sessions can be linked based solely on certificate contents.  Of course
that assumes that the certificate doesn't contain a DN that contains linkable
information.

Volatile certificates create a minor performance issue (certificate generation
is fast, but it's not that fast) and a major traceability issue.  If there is
no stability in certificates, then you lose the ability to audit sessions. 
It's not possible to determine if the peer you were talking to is really the
person you expected - they are probably unable to produce the certificate that
they used during the session because the certificate has since been destroyed.

This leads to a need for some degree of persistence, with certain constraints:
 1. Certificates cannot be the same across different origins, i.e., your
identity must be unlinkable across origins.
 2. It must be possible to use a different certificate when talking to
different people on the same site, i.e., your identity must be unlinkable
across peers.
 3. Certificates need to be destroyed when cookies are destroyed, i.e., you
must be able to control linkability over time.

Requirement 2 is the most interesting case because this implies that there
needs to be some interaction with the application to achieve this, not just the
browser.  Only the application has any hope of having prior knowledge of
identity such that this would be possible.

Note: A DTLS peer acting in the server role presents their certificate without
any prior knowledge of the identity of the peer, and a client presents their
certificate without actually verifying the server identity.

This implies that there needs to be some control surface to allow applications
to control certificate options.  This needs to be separate to the existing peer
identity constraints because these privacy protections are needed in the
absence of identity assertions.  In fact, anonymity cases are where these are
most needed.

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

Received on Tuesday, 30 April 2013 18:15:03 UTC