From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: cryptography@c2.net Subject: IETF building GAK into the PKI Date: Mon, 13 Jul 1998 04:42:29 +0100 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.