IETF S/MIME to follow PGP in building in GAK?

You may recall the furor generated by PGP Inc adding a GAK enabling feature thus making it easier for governments to impose GAK on the deployed PGP 5.x user base. PGP Inc called this feature CMR (Corporate Message Recovery) or ARR (Additional Recipient Request). Over on IETF S/MIME, right now there is a thread which looks set to add an almost identifical feature to S/MIME (spooky how similar the feature is even). Most of the regular contributors on S/MIME work for GAK sell out companies anyway, so I figure this is pretty much a done deal. (S/MIME already has another form of GAK also, in that the X.509 key directory specs allow the directory to optionally keep _private_ keys also). I think the ARR mechanism is actually more dangerous than keeping locally escrowed copies of keys in PGP because of the web of trust model. (See: http://www.dcs.ex.ac.uk/~aba/cdr/ for my thoughts on this). In the S/MIME world where there is a more hierarchical approach to Certification, you can expect government run CAs which demand a copy of your private key also. (eg. the UK DTI document on crypto licensing proposals was talking about this method). For S/MIME, S/MIME style ARR seems fairly balanced in lethality to CAs which keep private keys. I wonder if Phil Zimmermann feels proud of himself now that S/MIME looks like it will adopt his CAK/GAKware design. You might be amused at this introductory remark from the proposer on S/MIME IETF: : As a side note, this is not a radically new concept as something very : similar has already been proposed and implemented by PGP. : : Flames welcome. The guy's proposal below. It was well received too. Someone else proposed adding it in as a core MUST S/MIME requirement to handle these additional recipient requests. (You can follow the thread on the hypertext archive at www.imc.org (look for IETF S/MIME mailing list, or by subscribing to ietf-smime@imc.org). Adam ====================================================================== Date: Fri, 23 Jan 1998 13:07:01 -0700 From: "Steve Russell" Subject: Corporate Key mechanism To: A new and somewhat radical thread.... Because I believe the following to be true: - Requiring key recovery is a bad thing (complexity, cost, implementation, etc.) - Companies do have a need to access mail encrypted to or encrypted by their employees (lost keys, legal investigations, etc) - We are all working on methods of satisfying US export requirements so that we can export a cryptographically useful product - The is a middle step between full key recovery and no hope of recovery which involves encrypting messages to a 'corporate key' in addition to a individual public key when sending a message. Basically, what is involved is changing the user certificate format to designate a field for a second certificate which represents the corporate public key appropriate for that user. An application intending to encrypt mail to that user MUST then encrypt the message to both the user key and the corporate key. By no means am I implying that everyone that implements S/MIME leave a back door into all of their messages. However, since most companies that are implementing secure messaging are setting up their own CA (Entrust, OnSite, Netscape, etc.) and they have control over what fields are populated and with what information, they are able to choose whether or not they need visibility into their own data. As a side note, this is not a radically new concept as something very similar has already been proposed and implemented by PGP. Flames welcome. Steve