100077 - Implement client-side key-recovery

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, enhancement, P2)

Description

[Bob Lord]

A CA can be configured to escrow the client's encryption key as a precondition
for cert issuance.  The escrow process comes complete with UI to get the user's
permission to perform this action.

The client now needs key recovery capabilities.  There should be a way for the
client to authenticate itself to the CA and request the automatic fetching of
the client's own cert and key.
This process should be no more difficult than the initial enrollment.

Comment 1

[Stephane Saux]

P2 
Target 2.2
So if a ca has an ldap enrollment with key escrow, it would make sense for them
to have a ldap key recovery.

However wouldn't this make the compromise of an account worse because not only
could an unauthorized person obtain a new cert under the compromized account
name, he could also get older certs/keys to decrypt old messages.

What would be an appropriate thing to do for CAs that separate the request and
issuance steps (to allow for the validation of the data provided during the
request)? 

For such CA's the enrollment allows the browser to load the cert because the
browser has the private key.

but for key recovery, they would not want to have the browser load the cert +
private key without the same kind of scrutiny they used during enrollment, but
it's harder to ascertain that the browser loading the key/cert is the
"authorized" browser.

Comment 2

[Bob Lord]

The CA should decide the level of verification it requires to hand over a cert
and private key. That includes the choice between real-time recovery (more
scalable) vs. manual verification (potentially more secure).  I would recommend
that CAs require a great deal of verification, but it's up to them.

Comment 3

[John Unruh]

Since it's been a year since the last comment, setting to Future.

Comment 4

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Mass change "Future" target milestone to "--" on bugs that now are assigned to
nobody.  Those targets reflected the prioritization of past PSM management.
Many of these should be marked invalid or wontfix, I think.

Comment 6

[timeless]

what sort of UI/API does the Browser need to provide?