Discussion Draft V.009
May 1996
Users of public-key technology have a number of data units that should be characterized as 'personal property' because
Chief among these data units are
Users must be able to transport this personal property securely and offline from one browser to another and one platform to another.
Our user, Alice, cannot accept being locked into only one machine or one browser make and model for cryptographic operations. Alice may spend hours at the office getting certificates, keys, and secrets on her office IBM-compatible machine with the 'Sinbad' browser; but then she needs to take them home--securely--to use on her home Macintosh with the 'Argonaut' browser. She should also be able to take them to a neighbor's house, to a mall, kiosk, and so on.
The following tables summarize our current knowledge
of the risks and protections attendant to online and offline transport
of keys, secrets, and certs and CRLs.
| |
|
|
| |
|
|
traffic analysis |
||
(out of scope of this document) |
hardware tokens (future) |
|
Online solutions, that is, retrieving personal property from a well known server whenever it is needed, is out of scope for this proposal. Offline transport will be needed for several years because online requires solution of fundamental security problems and because current physical infrastructure (wiring) is inadequate to ensure online access.
A large number of Web clients use telephone lines and modems, and these are probably at least as painful to the user as taking conscious action to transport data offline. The most secure offline transport is acknowledged to be in hardware tokens like smart cards. However, it will be years before standards are finalized and cards become ubiquitous. In the meantime, we must do the best we can with software. PFX formats will work for either hardware or software transports.
PFX is a way for clients to transfer personal data from one environment to another without online server intermediaries.
PFX has two modes of operation: public-key mode and password mode. Public-key mode has higher security, but requires prior key transport. Practically speaking, Alice has to remember to bring the public key of her home machine's PFX installation to the office to be able to encrypt the PFX bits. Password mode has lower security but does not require prior key exchange. Password security is lower because passwords, in practice, have low entropy and offline guessing attacks are relatively easy.
The diagrams below illustrate the two modes. Time increases downward in the diagrams.
In this mode, Alice takes a diskette containing her home machine's PFX public key-exchange key (PPKEK) to the office in the morning. This key--and its corresponding private key-- was generated when Alice installed the PFX system on her home machine. After logging Alice on, the office machine's PFX system allows Alice to encrypt her PFX data with the PPKEK, creating a PK-Enveloped PFX Bag. Alice can e-mail the Bag home or take it home on a diskette. This is standard public-key enveloping of Alice's personal effects, as used in many accepted secure protocols.
In this mode, Alice does not need her home machine's PPKEK. She creates a password (hopefully long, complex, and difficult to guess). The office machine's PFX system derives an ordinary, symmetric encryption key from Alice's user name and password and encrypts the PFX plain text bag with this key. Alice's system will only save password-encrypted PFX bits to files, and admonishes her not to send encrypted bits home via e-mail in this mode, since the system cannot assure the strength of her password. When Alice gets home, she types in the same user name and password, with which the home PFX system decrypts the bits.
Let us call the collection of Alice's confidential data, including her private keys, her Safe. Recall that certificates and CRLs, while not confidential individually, reveal private information about Alice's activities. So, Alice keeps them in her Safe.
The Safe has three compartments: private keys, certificates and CRLs, and assorted secrets. The safe also has an extension mechanism that allows the ASN.1 data grammar written today to accommodate additional compartments in the future.
Private keys merit special attention. They are always shrouded, meaning that neither Alice nor any other human can ever see or copy the plain text (within the limits of software security, at present). The Safe transports private keys from machine to machine. The rest of the contents of the Safe, on the other hand, is just encrypted, meaning that Alice can access the plain text after decryption.
In public-key mode, PFX creates
PKCS#7
EnvelopedData.
In password mode, PFX creates
PKCS#7
Encrypted Data
using methods from
PKCS#5
.
In public-key mode, the PFX private key-exchange key is needed to open the PFX EnvelopedData. We assume this key is under Alice's control, that it is never leaves the target machine, and that Alice's machines log her on (authenticate her) before allowing these keys to be used.
The public key-exchange key will be packaged in a self-signed data object syntactically like a certificate. Let us call this a pseudo-cert. This object allows the PKCS#7 RecipientInfos in the EnvelopedData to be syntactically well formed.
Implementations will encourage Alice to maintain physical security of merely encrypted data by making it difficult for her to send them over the wire. In other words, implementations will support only saving encrypted data to disk files. Of course, Alice can subvert the system by sending a disk file in e-mail, but implementations shall warn her that this is not wise.
The following scenario is just an example. This document does not aim to specify user interface or requirements on an implementation beyond a few security points.
To take her Personal Effects home from the office, Alice interacts with her Sinbad browser at the office in the following sequence of events:
All done.
When she gets home, she opens her e-mail and sees a MIME attachment icon containing her personal effects. The Argonaut browser supports PFX Importation by MIME type, so all she needs to do is double-click on the MIME attachment in the e-mail message. If she had chosen password mode, she would be prompted for the password.
Alice can now use all the data she had at the office at home. Also, if she had any preexisting data at home, it is preserved unless she specifically chose to overwrite it. She can do everything she could do at the office, plus everything she could previously do at home.
Alice may have multiple sets of private keys, distinguished by "Nickname" strings. Alice provides the nicknames. The default nickname is simply Null, so Alice need not be concerned with nicknaming key sets unless she has multiple key sets. A dialog will confirm her intention if Alice is about to overwrite a key set on importation.
OSI Object Identifiers, or OIDs, come from a single, global, universal name space managed by a central authority and its delegates. The value of an OID is unique in the world.
Safes are divided into compartments, some named with OIDs, others with nicknames. If Alice tries to import data into a compartment that already exists on her machine, another dialog solicits confirmation (Yes, Yes to All, No).
Certificates and CRLs are globally uniquely identified, so no overwriting problems arise.
In the remainder of this document, "environment" means "browser or platform-in-the-sense-of-machine-and-operating-system".
ASN.1 and DER encoding ensure environment-independence.
Commentary is in-line.
First, establish an ASN.1 module named "PFX" and note that its default ASN.1 tags are explicit.
PFX DEFINITIONS EXPLICIT TAGS ::= BEGIN
Next, import, in the ASN.1 sense, definitions from several standards and export all data types defined in this module.
IMPORTS ContentInfo FROM PKCS7 pkcs7
EncryptedPrivateKeyInfo FROM PKCS8 pkcs8
Name,
CertificateSerialNumber FROM X509 x509;
-- EXPORTS All;
The top-level definition is the PersonalEffectsExchange. This is the type for personal effects in a PKCS#7 ContentInfo whose contentType is either envelopedData or encryptedData.
PersonalEffectsExchange ::= ContentInfo
The plain text is of type SafeContents. It contains a globally unique identifier, pfxOID, registered with an appropriate authority. It will collide with no other OID. Version is an integer that serves to break backwards compatibility: software shall be written to abort if it does not explicitly handle the version in any given instance of this type. The remaining four items in the sequence are the meat. CertAndCRLBag, KeyBag, and SecretBag are self-explanatory. Extensions is a well known technique borrowed from the X.509 certificate standard to support forward and backward compatibility.
SafeContents ::= SEQUENCE {
pfxOID OBJECT IDENTIFIER -- Value TBD
version Version,
certAndCRLBag [0] IMPLICIT CertAndCRLBag OPTIONAL,
keyBag [1] IMPLICIT KeyBag OPTIONAL,
secretBag [2] IMPLICIT SecretBag OPTIONAL,
extensions [3] Extensions OPTIONAL
}
Version ::= INTEGER
A CertCRLBag contains certificates and CRLs.
When this specification is finalized, it should be written to
contain options for all standardized certificate formats. For
now, it contains an X.509 bag, an
LDAP
bag, and a
SDSI
bag, the
latter two being just examples.
CertCRLBag ::= SEQUENCE {
x509Bag [0] IMPLICIT X509Bag OPTIONAL,
ldapBag [1] IMPLICIT LDAPBag OPTIONAL -- this is just a sample
sdsiBag [2] IMPLICIT SDSIBag OPTIONAL -- another sample
-- etc.
}
An X.509 CertCRLBag is conveniently captured in a nested instance of a PKCS#7 ContentInfo, containing an empty SignedData and a NULL signature. This is explicitly allowed in the standard and is a common idiom.
X509Bag ::= ContentInfo
The following allows the current sample syntax to be complete:
LDAPBag ::= TBD SDSIBag ::= TBD TBD ::= ANY
A KeyBag is a sequence of
PKCS#8
PrivateKeyInfos,
each associated with
User Interface shall solicit confirmation if Alice attempts to overwrite an existing private key with another one with the same name. Alice controls her private-key nicknames and they are local to her environments.
KeyBag ::= SEQUENCE OF PrivateKey
PrivateKey ::= SEQUENCE {
assocCerts SEQUENCE OF IssuerAndSerialNumber,
nickname UniversalString,
pkcs8data PrivateKeyInfo
}
Issue: is UniversalString the right ASN.1 type for a key nickname, or is BMPString better?
The global ids of the certificates are in the form of an Issuer and a certificate serial number. Certificates are uniquely identified by the name of the CA that issued them and the serial number assigned by that CA. One of the responsibilities of a CA is to ensure that serial numbers it issues do not locally collide. The Names of CA's are globally controlled.
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber
}
Alice's personal secrets are contained in an instance of SecretBag, which, in turn, contains multiple compartments named with strings Alice assigns. User Interface shall solicit confirmation if Alice attempts to overwrite an existing compartment with another one with the same name. Compartment names are local to Alice's environments and under the control of her and her application software.
SecretBag ::= SEQUENCE OF SafeCompartment
SafeCompartment ::= SEQUENCE {
compartmentName UniversalString,
contents ANY -- defined by compartment name
}
PFX must allow extensibility. For example, protocol
secrets from well known, published protocols like
SET
can be labeled with OIDs and should be part of the Safe. Older
software must not break when it reads messages containing new
objects. It must, at least, ignore data it cannot interpret. The
mechanism for intentionally breaking this compatibility is the
top-level Version field in the PersonalEffectsExchange.
Older software is required to report error when reading a PersonalEffectsExchange
with a version it does not know.
PFX borrows extensibility mechanism from X.509. An Extension is a sequence of a globally unique extension identifier, assigned by a central authority; a flag indicating criticality, and a value. Software shall parse any extensions present in a PersonalEffectsExchange and behave as follows
-- Modeled after X.509
--
-- If the extnId is known
-- process the extnValue according to published specifications
-- else
-- if "critical" is true
-- error
-- else
-- ignore the extension
Extensions ::= SEQUENCE OF Extension
Extension ::= SEQUENCE {
extnId OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
}
Finally , PFX needs encryption algorithm identifiers.
The following are taken from
PKCS#1
, #5, and SET:
osi-impl-workshop OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)}
des-cbc OBJECT IDENTIFIER ::= {osi-impl-workshop 7}
secsig OBJECT IDENTIFIER ::= {osi-impl-workshop secsig(3)}
id-sha1 OBJECT IDENTIFIER ::= {secsig 2 26}
--
-- RSA encryption of OAEP'd KEK and SHA1 hash of the "Content", where
-- the "Content" is defined as with the signature digital operation.
--
rsa1 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549)}
pkcs-1 OBJECT IDENTIFIER ::= {rsa1 pkcs(1) 1}
pkcs-5 OBJECT IDENTIFIER ::= {rsa1 pkcs(1) 5}
pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} -- insecure; do not use
pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} -- proposed to RSA
pbeWithSHA1AndRC4 OBJECT IDENTIFIER ::= {pkcs-5 12} -- proposed to RSA
rsaEncryption OBJECT IDENTIFIER ::= {pkcs-1 1}
rsaOAEPEncryption OBJECT IDENTIFIER ::= {pkcs-1 6}
rsaOAEPEncryptionOfKeySHA1 OBJECT IDENTIFIER ::= {rsaOAEPEncryption 1}
-- missing: contentEncryptionValues for DES-CBC, RC2-CBC, RC4, and CDMF
Note that MD5 has been cryptanalyzed and is no longer secure (private communication). RSA will provide updated algorithm identifiers; we have proposed two.
This is the end of the entire PFX module.
END
typedef long int PFXERR; // PFX error code
#define PFXERR_NO_ERROR 0x00000000
#define PFXERR_WARNING_BUFFER_POINTER_NULL 0x00010001
#define PFXERR_ERROR_INSUFFICIENT_SPACE 0x00020001
#define PFXERR_ERROR_UNKNOWN_MODE 0x00020002
#define PFXERR_ERROR_INVALID_PKEK 0x00020003
#define PFXERR_ERROR_UNKNOWN_ALGID 0x00020004
typedef unsigned char BYTE; // should work on 8-bit byte machines
typedef unsigned short int WORD;
typedef unsigned long int DWORD; // should work on 32-bit machines
typedef struct s_PFX // Instances contain DER-encoded PFX
{ // (see the ASN.1 definition, above)
BYTE *pbPFX;
DWORD cbPFX;
} PFX;
typedef struct s_PKEK // Public Key-Exchange Key
{
BYTE *pbPKEK;
DWORD cbPKEK;
} PKEK;
#ifdef _UNICODE
typedef unsigned short int WORD;
typedef WORD WCHAR;
typedef WCHAR TCHAR;
#else
typedef char TCHAR;
#endif
typedef struct s_PWDAT // Password Data
{
TCHAR *szUserName;
TCHAR *szPassword;
} PWDAT;
typedef struct s_ALGID // PKCS#7 or #5 Algorithm Identifier
{
BYTE *pbAlgid;
DWORD cbAlgid;
} ALGID;
#define PFX_PASSWORD_MODE 1
#define PFX_PUBLIC_KEY_MODE 2
Implementations bear the responsibility for encoding and decoding the PFX binary.
To export an entire PersonalEffectsExchange from an environment-dependent store into a memory buffer, call this API:
PFXERR PFXExport (
DWORD dwModeInput,
PWDAT *pPWDATInput,
PKEK *pPKEKInput,
ALGID *pKeyEncryptionAlgidInput,
ALGID *pContentEncryptionAlgidInput,
PFX *pPFXOutput);
dwModeInput must be either PFX_PASSWORD_MODE or PFX_PUBLIC_KEY_MODE. If it is neither of these, then PFXExport returns PFXERR_ERROR_UNKNOWN_MODE.
If dwModeInput is PFX_PUBLIC_KEY_MODE, then pPKEKInput must point to a PKCS#7 ContentInfo of with contentType SignedData whose SignerInfos contains a self-signed X509 certificate containing the public key-exchange key of the receiving machine. Syntax errors or failure of the signature check results in PFXExport's returning PFXERR_ERROR_INVALID_PKEK.
If dwModeInput is PFX_PASSWORD_MODE, then pPWDATInput must point to an instance of PWDAT, which contains zero-terminated strings containing a user name and a password. The strings are conditionally in UNICODE format for ease of internationalization.
If both mode and certificate checks are valid, then the function next examines pAlgidInput. If in password mode, this must point to a DER-encoded OBJECT IDENTIFER value equal to pbeWithSHA1AndRC2-CBC or pbeWithSHA1AndRC4. If in public-key mode, pKeyEncryptionAlgidInput must point to the value rsaOAEPEncryption or rsaOAEPEncryptionOfKeySHA1 and pContentEncryptionAlgidInput must point to the value DES-CBC, CDMF, RC2-CBC, or RC4 (Issue: we must get real values for these).
Once the function validates the cryptographic inputs as above, it proceeds to validate the buffer pPFXOutput, and possibly fill it with content, according to the following caller-allocates logic.
Buffer Management for Export APIs
The application must allocate space for exported data. The API aids the application in allocating space with the following logic:
Applications are responsible for freeing allocated space after the data has been used.
The contents of the buffer may be written to a disk file or a MIME object for transport. MIME transport should be discouraged if private keys are being transported.
To import a package of certs and CRLs from a memory buffer into an environment-dependent store, call the following:
PFXERR PFXImport (
DWORD dwModeOutput,
PKEK *pPKEKInput,
ALGID *pKeyEncryptionAlgidOutput,
ALGID *pContentEncryptionAlgidOutput,
PFX *pPFXInput);
The application must provide the pseudo-certificate for import; the function uses this certificate to look up the corresponding private key for decryption. Since the PFXInput contains a self-describing encrypted data object, the function reports the PFX mode and encryption algorithms used in the parameters dwModeOutput, pKeyEncryptionAlgidOutput, and pContentEncryptionAlgidOutput. If any of these pointers are NULL, the function ignores them. For the encryption algorithm identifiers, the function employs caller-allocation buffer management discipline like that in 1.6.2. In other words, if the caller does not allocate enough memory, the function truncates copying and returns the amount needed. The caller reallocates and retries.
Applications will need finer control over an environment's certificate store, specifically to add, delete, search on a variety of keys, and to verify. Environment vendors shall supply their own solutions to these problems.
PKCS#8
and #5 explicitly provide encrypted data exchange
formats for single private keys. The PFX proposal in password
mode extends the symmetric key, password-based methods of PKCS#5
to cover transport of the entire Safe, including private keys.
Its specific algorithms are a bit dated, but we expect stronger
algorithms to be registered with RSADSI in the near future. We
are proposing pbeWithSHA1AndRC4
and pbeWithSHA1AndRC2-CBC for inclusion in the next revision.
PKCS#5 encryption is symmetric. The password implies the key. The user provides the password at encryption time and again at decryption time. PKCS#5 and the present standard have no provisions for managing the secret key or the password: that is the user's responsibility. Vendors shall supply prudent user interface or wizards to help users avoid mistakes.