[2938] in cryptography@c2.net mail archive
IETF building GAK into the PKI
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Mon Jul 13 10:31:19 1998
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cryptography@c2.net
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
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.
