13 July 1998; Add CE and SB messages; add PG second message
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cryptography@c2.net
Subject: IETF building GAK into the PKI
Date: Mon, 13 Jul 1998 03:42:29 (NZST)
While everyone was busy criticising PGP Inc for its Corporate Message
Recovery "feature", the IETF has been quietly building GAK into its public key
infrastructure (PKI) design, which is probably going to become *the* PKI
blueprint used worldwide. This seems to have received zero attention outside
the small community of people working on the standards, and has now progressed
to the stage where two of the central drafts (CRMF and CMP) are at the final
call stage before becoming IETF standards. Although the intent is, like PGP,
to allow corporate key recovery (or whatever the justification for this stuff
is), the result will be that what is deployed is a fully GAK-ready PKI. For
example once CRMF-compliant software (see below) is deployed, all it will take
is a tiny law change ("In order to protect children and stop terrorists, a CA
can only certify keys which include the PKIArchiveOptions field") and the GAK
infrastructure which the USG has admitted it can't build will have been made
available for it by the IETF.
The rest of this message contains relevant excerpts from the drafts (available
from your local internet drafts directory), and an example of how one foreign
government has already tried to build a national GAK infrastructure using the
IETF PKI blueprint.
Excerpts
--------
CMMF (draft-ietf-pkix-cmmf-00.txt), PKI message formats, has:
>5.10 Key recovery Response
>
>For key recovery responses the following syntax is used. For some
>status values (e.g., waiting) none of the optional fields will be
>present.
>
> KeyRecRepContent ::= SEQUENCE {
> status PKIStatusInfo,
> newSigCert [0] Certificate OPTIONAL,
> caCerts [1] SEQUENCE SIZE (1..MAX) OF
> Certificate OPTIONAL,
> keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
> CertifiedKeyPair OPTIONAL
> }
CRMF (draft-ietf-pkix-crmf-01.txt), PKI certification requests, has:
>7.4 Archive Options Control
>
>The pkiArchiveOptions control enables subscribers to supply information
>needed to establish an archive of the private key corresponding to the
>public key of the certification request. It is defined by the following
>syntax:
>
>PKIArchiveOptions ::= CHOICE {
> encryptedPrivKey [0] EncryptedKey,
> -- the actual value of the private key
> keyGenParameters [1] KeyGenParameters,
> -- parameters which allow the private key to be re-generated
> archiveRemGenPrivKey [2] BOOLEAN }
> -- set to TRUE if sender wishes receiver to archive the private
> -- key of a key pair which the receiver generates in response to
> -- this request; set to FALSE if no archival is desired.
>
>EncryptedKey ::= CHOICE {
> encryptedValue EncryptedValue,
> envelopedData [0] EnvelopedData }
> -- import from [CMS]. The encrypted private key MUST be placed
> -- in the envelopedData encryptedContentInfo encryptedContent
> -- OCTET STRING. The envelopedData encryptedContentInfo
> -- contentType field MUST contain the id-data OID.
>
>EncryptedValue ::= SEQUENCE {
> encValue BIT STRING,
> -- the encrypted value itself
> intendedAlg [0] AlgorithmIdentifier OPTIONAL,
> -- the intended algorithm for which the value will be used
> symmAlg [1] AlgorithmIdentifier OPTIONAL,
> -- the symmetric algorithm used to encrypt the value
> encSymmKey [2] BIT STRING OPTIONAL,
> -- the (encrypted) symmetric key used to encrypt the value
> keyAlg [3] AlgorithmIdentifier OPTIONAL,
> -- algorithm used to encrypt the symmetric key
> valueHint [4] OCTET STRING OPTIONAL }
> -- a brief description or identifier of the encValue content
> -- (may be meaningful only to the sending entity, and used only
> -- if EncryptedValue might be re-examined by the sending entity
> -- in the future)
>
>KeyGenParameters ::= OCTET STRING
>
>An alternative to sending the key is to send the information about how
>to re-generate the key using the KeyGenParameters choice (e.g., for many
>RSA implementations one could send the first random numbers tested for
>primality). The actual syntax for this parameter may be defined in a
>subsequent version of this document or in another standard.
CMP (draft-ietf-pkix-ipki3cmp-08.txt) has:
>3.3.7 Key Recovery Request content
>
>For key recovery requests the syntax used is identical to the
>initialization request CertReqMessages. Typically, SubjectPublicKeyInfo
>and KeyId are the template fields which may be used to supply a
>signature public key for which a certificate is required (see Appendix B
>profiles for further information).
>
>See [CRMF] for CertReqMessages syntax.
>
>3.3.8 Key recovery response content
>
>For key recovery responses the following syntax is used. For some
>status values (e.g., waiting) none of the optional fields will be
>present.
>
> KeyRecRepContent ::= SEQUENCE {
> status PKIStatusInfo,
> newSigCert [0] Certificate OPTIONAL,
> caCerts [1] SEQUENCE SIZE (1..MAX) OF
> Certificate OPTIONAL,
> keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
> CertifiedKeyPair OPTIONAL
> }
The UK GAK Plan
---------------
In 1997 the UK published its plans for a GAK infrastructure based on the IETF
PKI blueprint. This didn't even pretend to be a PKI, but was referred to as a
CKI (Confidentiality Key Infrastructure), with CA's being replaced by CMA's
(Certificate Management Authorities) whose role differs from conventional CA's
in that their task is "the management of confidentiality keys". The sole
reason for this CKI was to allow government access to keys (or, more
correctly, covert access to keys, the whole thing being designed by GCHQ, the
UK equivalent of the NSA).
Included below are some relevant quotes from "Cloud Cover - Confidentiality
Key Infrastructure - Part 2: CKI Key Management Protocol", which show how GCHQ
plans to build a UK GAK infrastructure using the IETF PKI blueprint.
"119. This protocol uses the Internet PKI key recovery protocol exchange.
120. The use of this protocol exchange differs slightly from that defined in
the Internet PKI key recovery protocol exchange in that:
[...]
b. The client for this request is not the key user".
The client in this case is HM Government. Apart from that, the rest is taken
straight from the IETF drafts mentioned above.
Annex B, "Use of Internet PKI Protocol" contains further comments:
"II. PKI Management Model
B.6 Certificate Management Authority (CMA) is a special form of CA for the
management of confidentiality keys.
[...]
V. Data Structures
B.12 The overall PKI message and status information structures are used for
the CKI".
The rest of the protocol is just a profile of the IETF drafts for government
access to keys.
Summary, and a plea for reasoned debate
---------------------------------------
Unlike the PGP CMR field, which was seen as a potential future problem, the
PKI draft is not just a future problem but one which has already arrived. The
UK plan demonstrates how governments will turn the PKI into a CKI, whether its
designers intended it for this use or not.
I realise that this is a somewhat emotional issue for most people, so please
don't respond by flaming the people responsible for the design. I'm posting
this message to bring it to peoples attention since it seems to have slipped
by unnoticed until now, but I don't want to start a war over it.
One possible resolution to the problem is to remove the key recovery/proto-GAK
portions from the standard but allow a hole for user-defined additional
messaging, as PGP Inc. did by making the former CMR field a reserved field.
That way if anyone really wants "key recovery" they can add it themselves
without making it a part of the PKI architecture.
Peter.
Internet-Drafts directories are located at (October 1996):
Africa: ftp.is.co.za
Europe: nic.nordu.net
ftp.nis.garr.it
Pacific Rim: munnari.oz.a
US East Coast: ds.internic.net
US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-balenson-secure-email-00.txt".
Date: Mon, 13 Jul 1998 10:44:03 -0400 (EDT)
From: Carl Ellison <cme@clark.net>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
cc: cryptography@c2.net
Subject: Re: IETF building GAK into the PKI
For what it's worth, SPKI does not and will not include such
features. This is PKIX only.
- Carl
Carl M. Ellison cme@acm.org http://www.clark.net/pub/cme
PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2
``Officer, officer, arrest that man! He's whistling a dirty song.''
Jean Ellison (aka Mother)
To: pgut001@cs.auckland.ac.nz
cc: cryptography@c2.net
Subject: Re: IETF building GAK into the PKI
Date: Mon, 13 Jul 1998 10:59:39 -0400
From: Steve Bellovin <smb@research.att.com>
> GAK
> infrastructure which the USG has admitted it can't build will have been made
> available for it by the IETF.
Thanks for the heads-up on this. I would dispute, though, that all
of the practicality questions of a GAK infrastructure are answered by
the existence of this field.
The issue has never been the simple existence of a mechanism to leak
keys. There are obviously many ways to do that, starting with the
simplest: send the key in cleartext. From there, we can progress
to the Clipper LEAF field, the differential work factor used by Lotus,
and all the other schemes that have been proposed to let the governments
of the world look at nominally-private bits. The crucial problem --
and one that I and others claim is extremely difficult, and likely
impossible (see http://www.crypto.com/key_study/) is to design the
surrounding infrastructure so that it is both efficient and secure
against technical and non-technical attacks. Sticking a new field
in a certificate message doesn't do anything to change any of that.
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cryptography@c2.net, schear@lvcm.com
Subject: Re: IETF building GAK into the PKI
Date: Tue, 14 Jul 1998 10:02:52 (NZST)
>>I realise that this is a somewhat emotional issue for most people, so please
>>don't respond by flaming the people responsible for the design.
>Even if these designers arn't flamed, it would be useful for their names to
>be widely known (e.g., when those of us in hiring positions are considering
>their resumes). I can't believe they weren't aware of the consequences of
>their designs.
That may be taking things a bit far... I think the people who designed these
features genuinely weren't aware of how they would end up being (mis)used once
they were in place. I contacted some of the designers (twice) months ago and
expressed my reservations about the GAK-ready design, and also posted a
message to the PKIX list about a week ago, but never got a response - the
(highly politicised) cypherpunk types are used to seeing this sort of thing
coming from various GAK initiatives and can immediately see the dangers in the
design, but I suspect a lot of others genuinely couldn't see why it was a
problem. The PKIArchiveOptions capability is particularly nasty because
unlike, say, Lotus' differential workfactor encryption or similar per-message
backdoors pointed out by Steve Bellovin in a recent message, if use of
PKIArchiveOptions is made mandatory it'll be impossible to obtain an
electronic identity unless you hand over your keys at the same time. Again
using the UK as an example, I'll refer people to the UK requirement for
mandatory government licensing of TTP's (trusted third parties, a kind of CA
superset with GAK functionality built in) which were floated last year and
which are still around in a modified form.
(At some point I must write up a rant about creeping key escrow, it's scary how
many commercial products I'm seeing which are designed so that the keys will
be generated by a central authority, with a copy sent to the user. What's
worse is that the people who end up buying and using the products see this as
perfectly normal, and it often takes a fair bit of explaining for them to see
why this is a bad thing).
Peter.