GNU Crypto Project C. Marshall draft-marshall-gnu-keyring-00 Independent Expires: March 2004 September 2003 The GNU Keyring File Format Status of this Memo This document is a ``rough draft,'' and should not be considered a fixed format. The values and structures described below are subject to change without notice. This is not an Internet-Draft, and is not associated with or endorsed by the Internet Engineering Task Force. We use the format of Internet-Drafts and RFCs for convenience and familiarity. Abstract This is a proposal for a new keyring format, to be used by GNU Java implementations (Classpath, GCJ, GNU Crypto) as the official ``keystore'' format for those platforms. It need not be limited to Java platforms, however, as it is flexible enough a format to accommodate different applications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Magic Bytes/Version Number . . . . . . . . . . . . . . . 4 2.1. Ring Usage . . . . . . . . . . . . . . . . . . . . . . . 4 3. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Envelope Types . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Encrypted . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Password-Encrypted . . . . . . . . . . . . . . . . . . . 7 3.1.3. Authenticated . . . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Password-Authenticated . . . . . . . . . . . . . . . . . 8 3.1.5. Compressed . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.6. Additional Envelope Types . . . . . . . . . . . . . . . 9 3.2. Extension Values . . . . . . . . . . . . . . . . . . . . 9 3.3. Primitive Types . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Trusted Certificates . . . . . . . . . . . . . . . . . . 10 3.3.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . 10 3.3.3. Private Keys . . . . . . . . . . . . . . . . . . . . . . 11 3.3.4. X.509 Certificate Paths . . . . . . . . . . . . . . . . 11 3.3.5. Additional Primitive Types . . . . . . . . . . . . . . . 12 3.4. Properties . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Property Set . . . . . . . . . . . . . . . . . . . . . . 13 draft-marshall-gnu-keyring-00 [Page 1] Marshall The GNU Keyring File Format September 2003 3.4.2. Property Type . . . . . . . . . . . . . . . . . . . . . 13 4. Required Layouts . . . . . . . . . . . . . . . . . . . . 13 4.1. Read-only Layouts . . . . . . . . . . . . . . . . . . . 14 5. GNU Raw Codec . . . . . . . . . . . . . . . . . . . . . . 14 5.1. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Diffie-Hellmann . . . . . . . . . . . . . . . . . . . . 15 6. Parsing Methodology . . . . . . . . . . . . . . . . . . . 15 7. Other Formats . . . . . . . . . . . . . . . . . . . . . 16 Security Considerations . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . 18 1. Introduction. The GNU Keyring file format is a proposed standard file format for the long-term storage of cryptographic data, such as private keys and digital certificates. This format is being designed with the following goals: * Protection of trusted credentials, through the use of a password- based MAC (message authentication code) over these credentials. * Protection of secret credentials, through the use of a password- based MAC over the data, which is encrypted with a strong, password-based cipher. * Management of disparate types of cryptographic data, such as different types of digital certificate. * Extensibility. It should be possible to extend the file format when new requirements arise, without undo breakage of existing applications. * Compatibility with the JDK. This means that it should be possible to use this format as a keystore, so GNU implementations of the Java platform can provide the same functionality as the JDK. An implementation of this format is included in the Free Software Foundation's GNU Crypto project, a cryptographic library written in Java. The full copyright of GNU Crypto is included at the end of this document. 1.1. Data Types. Data read and written to keyrings will be one of the following types: draft-marshall-gnu-keyring-00 [Page 2] Marshall The GNU Keyring File Format September 2003 uint8 An unsigned byte. uint16 An unsigned two-byte integer, in big-endian byte order. unit32 An unsigned four-byte integer. uint64 An unsigned eight-byte integer. octet sequence (os) An arbitrary byte array, stored as 1. the length of the byte array, encoded in a uint8. 2. the bytes themselves. extended octet sequence (eos) An arbitrary byte array, stored as 1. the length of the byte array, encoded in a uint32. 2. the bytes themselves. u8string A sequence of UTF-8 bytes, stored as the a uint16 length field, then that many bytes. (see java.io.DataOutput.writeUTF) bigint An arbitrary-precision signed integer, stored as 1. the length of the byte array, encoded in a uint32. 2. the minimum number of bytes in two's complement notation. byte[l] A fixed-length byte array, stored without length. 1.2. Notation. When defining constants in this document, we shall use the following style, similar to the C preprossesor: #define CONSTANT_NAME VALUE When showing the format of packets, we use the following form, assuming that fields are concatenated from top to bottom: type1 Description of field 1. type2 Description of field 2. ... To show the intended structure of compound types, we will use the following Lisp-like notation: (level-1 draft-marshall-gnu-keyring-00 [Page 3] Marshall The GNU Keyring File Format September 2003 (level-2 (level-3) ) ) By this we mean that the entity named `level-1' contains the entity named `level-2', which in turn contains the entity named `level-3', which is a primitive type and contains no other sub-types. Numbers are written in base 10, unless they are prefixed by `0x', when they will be written in base 16. Thus, the value `0x0123457' would mean the decimal value `1193047'. The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and ``OPTIONAL'' in this document are to be interpreted as described in [RFC2119]. 2. Magic Bytes/Version Number. To identify keyrings by content, and to protect against incompatibilities when the format evolves, all keyrings will begin with the following bytes: byte[3] The bytes ``GKR''. uint8 Version number. The current version number shall be 1. Thus keyrings described in this document shall begin with the value 0x474b5201. In magic(5) parlance, this would be: 0 string GKR GNU keyring file >3 byte x version %d 2.1. Ring Usage. Immediately following the four-byte magic and version data will be a one-byte ``ring usage'' field. The presence of set bits in this byte shall declare what may be stored in this keyring. The currently defined bits, from least-significant up, are: Bit Meaning --- ------- 0 Private keys may be stored in this keyring. 1 Personal certificate chains and public keys may be stored in this keyring. draft-marshall-gnu-keyring-00 [Page 4] Marshall The GNU Keyring File Format September 2003 2 Trusted certificates may be stored in this keyring. The remaining bits are undefined for this version of GNU keyrings, and MUST be ignored. The layout for particular keyring types are described in section 4, Required Layouts. Conformant implementations MUST be able to read keyrings with the following usage fields: * With only trusted certificates (bit 2). * With only private keys and personal certificate chains or public keys (bits 0 and 1). These two types correspond to ``trusted credentials'' and ``personal credentials'', respectfully. Since these two are the most common uses of key storage -- one way to securely store trusted credentials such as CA certificates, and one way to securely store public and private keys -- these types of keyrings are the ones REQUIRED by this format. 3. Packets. The keyring shall then contain one or more packets, constructs of the following form: uint8 Content-type. eos Properties. byte[n] Data, dependent upon content-type. n is not inherently fixed for a particular content-type, and may be zero. At the top level, following the magic bytes, there must be only a single packet. As such, the packet appearing first in the file is typically an envelope type, which contains some number of primitive types. The properties field is described in section 3.4. 3.1. Envelope Types. Envelope types contain other types, usually to transform their contents. The types are encoded by merely concatenating multiple types together, with the end of the sequence corresponding to the end of the octet sequence. All envelope types MUST contain a property "alias-list", the value of which will be composed of the concatenation of the following for each draft-marshall-gnu-keyring-00 [Page 5] Marshall The GNU Keyring File Format September 2003 of the contained types, separated by a single semicolon (';', Unicode value 0x003B): 1) The value of the "alias" property if the entry is a primitive type (primitive types are described in section 3.2). 2) The value of the "alias-list" property if the entry is an envelope type. That is, the recursive list of contained aliases will be flattened into a single, top-level list. 3.1.1. Encrypted. #define GKR_TYPE_ENCRYPTED 0 Encrypted enveloped types transform their enclosed types with a strong block cipher and an external key (for encipherment based on a password, see Section 3.1.2). The form of the key and the IV is not handled in this document; it is imagined as coming from a device that ensures secure production of a given array of bytes. uint8 GKR_TYPE_ENCRYPTED eos Properties. uint8 Encryption algorithm identifier. eos Encrypted data. The encrypted data field is the encoded contained packets encrypted with the cipher. The cipher algorithms are: #define GKR_CIPHER_AES_128_OFB 0 #define GKR_CIPHER_AES_128_CBC 1 `GKR_CIPHER_AES_128_OFB' denotes the AES cipher with a 128-bit key in output feedback mode, with 128-bit blocks. `GKR_CIPHER_AES_128_CBC' denotes the AES cipher with a 128-bit key in cipher block chaining mode. The padding for these ciphers shall be the same as that in [PKCS7]. That is, if the plaintext is L bytes long, the padding will be 01 if (L % 16) == 1 02 02 if (L % 16) == 2 ... 16 16 ... 16 if (L % 16) == 0 draft-marshall-gnu-keyring-00 [Page 6] Marshall The GNU Keyring File Format September 2003 The AES is described in [AES]. This type of envelope is OPTIONAL in conformant applications. It is included for completeness in the specification, and MAY be used in applications where password-based encryption is not appropriate. Implementations that cannot or do not want to use this type of ``raw'' encryption MUST still be able to parse these packets, but their contents may be discarded or ignored. 3.1.2. Password-Encrypted. #define GKR_TYPE_PBE 1 Password-encrypted enveloped types use a combination of a password key-derivation function and a block cipher. The key derivation function is always KDF2 as described in [RFC2898] with HMAC-SHA-1 as the PRF, and the iteration count will fixed at 1000. uint8 GKR_TYPE_PBE eos Properties. byte[8] Salt. uint8 Encryption algorithm identifier. eos Encrypted data. The cipher definitions are the same as in `GKR_TYPE_ENCRYPTED', except the key and the IV are generated with the KDF, using a password read by the application, the salt, and the iteration count. Conformant applications MUST be able to parse password encrypted envelopes, and it is the default mode of protection. The password is typically read as a string input by a human operator; to process the password as bytes for input to the PRF, we use the UTF-8 encoding scheme. Thus a key and IV is derived from the password, salt, and iteration count with: (dk,iv) = PBKDF2 (UTF8(password), salt, 1000, 32) The length of the derived key for the AES ciphers defined here is 16 bytes, and the IV is also 16 bytes long. 3.1.3. Authenticated. #define GKR_TYPE_MAC 2 Authenticated enveloped types run a keyed message authentication code draft-marshall-gnu-keyring-00 [Page 7] Marshall The GNU Keyring File Format September 2003 over their enclosed types, appending the hash to the end of the packet. As with the encryption types described earlier, this form is meant to be of generic use, and applications will likely use the password-based alternative described in the next section. uint8 GKR_TYPE_MAC eos Properties. uint8 Hash-based MAC identifier. eos Authenticated data. The authenticated data field is structured as follows: byte[n] The to-be-authenticated data. byte[l] The MAC of the preceding. The lengths of the two fields are context-dependent. The `GKR_HMAC_MD5_128' produces a 16-byte MAC, so `l' above would be 16 for that algorithm. `n' would be the total length of the field minus 16. The currently defined MAC algorithms are: #define GKR_HMAC_MD5_128 0 #define GKR_HMAC_SHA_160 1 #define GKR_HMAC_MD5_96 2 #define GKR_HMAC_SHA_96 3 These MAC algorithms are hash-based MACs as described in [RFC2104], in combination with the MD5 [RFC1321] and SHA-1 [RFC3174] message digests. The *_96 variants are truncated to 96 bits. This type, like the `GKR_ENCRYPTED' type, is OPTIONAL, and the same rules apply. 3.1.4. Password-Authenticated. #define GKR_TYPE_PBMAC 3 Password-authenticated enveloped types use a password KDF in similar fashion as encrypted enveloped types, but with a keyed message authentication code. uint8 GKR_TYPE_PBMAC eos Properties. byte[8] Salt. uint8 Hash-based mac identifier. eos Authenticated data. draft-marshall-gnu-keyring-00 [Page 8] Marshall The GNU Keyring File Format September 2003 The format of the authenticated data field and the supported algorithms is the same as `GKR_TYPE_MAC'. Conformant applications MUST be able to parse password authenticated envelopes, and it is the default mode of authentication. The MAC key is derived from the password in the same fashion as with password-encrypted types, and the length of the derived key shall be equal to the untruncated length of the HMAC's hash function, so: HMAC dkLen ================ ===== GKR_HMAC_MD5_128 16 GKR_HMAC_SHA_160 20 GKR_HMAC_MD5_96 16 GKR_HMAC_SHA_96 20 3.1.5. Compressed. #define GKR_TYPE_COMPRESSED 4 Compressed envelope types compress their contents with a standard deflate algorithm. uint8 GKR_TYPE_COMPRESSED eos Properties. uint8 Compression algorithm identifier. eos Compressed data. The following compression algorithms are supported: #define GKR_COMPRESS_DEFLATE 0 The format of the encoded data is described in [RFC1951]. The compression is handled independently for each compressed envelope. Conforming implementations MUST be able to decompress DEFLATE- compressed envelopes. 3.1.6. Additional Envelope Types. GNU Keyrings may also contain the additional envelope type `GKR_TYPE_PROPERTY_SET', but this type is not a generic envelope and is described in section 3.4. 3.2. Extension values. Values not defined in this document are reserved for future use. They draft-marshall-gnu-keyring-00 [Page 9] Marshall The GNU Keyring File Format September 2003 MUST NOT appear in version 1 keyrings. 3.3. Primitive Types. Primitive types contain a single cryptographic entity. Primitive types MUST contain a property "alias", which MUST have a non-empty string that identifies the entry. Entries of different types MAY have the same alias, to allow for referring to public and private credentials by the same name. Entries of the name type in a keyring MUST have different aliases. Conforming implementations MUST be able to parse all primitive types described in this section. 3.3.1. Trusted Certificates. #define GKR_TYPE_CERT 5 This value denotes a ``trusted certificate entry''. uint8 GKR_TYPE_CERT eos Entry properties. uint64 Entry creation date. uint8 Encoding identifier. eos Encoded certificate. The following encoding identifier has been defined: #define GKR_CERT_X509_DER 0 X.509 certificates must be stored as a raw DER sequence. The ASN.1 structures for encoding X.509 certificates is described in [RFC3280]. The creation date field, as used in this and all other primitive types, is the date this entry was created, measured in milliseconds since January 1, 1970, 00:00:00 UTC. 3.3.2. Public Keys. #define GKR_TYPE_PUBLIC_KEY 6 This value denotes an asymmetric public key. uint8 GKR_TYPE_PUBLIC_KEY eos Entry properties. uint64 Entry creation date. uint8 Encoding identifier. draft-marshall-gnu-keyring-00 [Page 10] Marshall The GNU Keyring File Format September 2003 eos Encoded key. The following encoding identifiers have been defined: #define GKR_PUBLIC_KEY_DSA_RAW 0 #define GKR_PUBLIC_KEY_RSA_RAW 1 #define GKR_PUBLIC_KEY_DH_RAW 2 #define GKR_PUBLIC_KEY_X509_DER 3 RSA, DSA, and DH keys are stored in the ``RAW'' codec used by GNU Crypto, which is described in Section 5. `GKR_KEY_X509_DER' denotes keys stored in a DER-encoded SubjectPublicKeyInfo ASN.1 structure, as described in [RFC3280]. 3.3.3. Private Keys. #define GKR_TYPE_PRIVATE_KEY 7 This value denotes an asymmetric private key, or a symmetric secret key. uint8 GKR_TYPE_PRIVATE_KEY eos Entry properties. uint64 Entry creation date. uint8 Encoding identifier. eos Encoded key. The following encoding identifiers have been defined: #define GKR_PRIVATE_KEY_DSA_RAW 0 #define GKR_PRIVATE_KEY_RSA_RAW 1 #define GKR_PRIVATE_KEY_DH_RAW 2 #define GKR_PRIVATE_KEY_RAW 3 #define GKR_PRIVATE_KEY_PKCS8_DER 4 RSA, DSA, and DH keys are stored in the ``RAW'' codec used by GNU Crypto, which is described in Section 5. `GKR_PRIVATE_KEY_DH_RAW' is stored as a raw octet sequence, and is not processed any further. `GKR_KEY_PKCS8_DER' denotes keys stored in a DER-encoded PrivateKeyInfo ASN.1 structure, as described in [PKCS8]. 3.3.4. X.509 Certificate Paths. #define GKR_TYPE_X509_PATH 8 draft-marshall-gnu-keyring-00 [Page 11] Marshall The GNU Keyring File Format September 2003 This value denotes an X.509 certificate path, which compliments a private key with the same alias name. Each private key should have a corresponding certificate chain, but this is not required by the format. uint8 GKR_TYPE_X509_PATH eos Entry properties. uint64 Entry creation date. uint8 Chain encoding identifier. eos Encoded certificate chain. The following encodings are defined: #define GKR_X509_PATH_PKIX_DER 0 `GKR_X509_PATH_PKIX_DER' is merely stored as an ASN.1 SEQUENCE type of one or more certificates. The first certificate in the path must be the certificate corresponding to the private key, and each subsequent certificate MUST be the issuer of the preceding. The root certificate SHOULD NOT be included in this chain. The encoding used in PKCS #7 is not used here, for it does not preserve the order of certificates. 3.3.5. Additional Primitive Types. GNU Keyring files may also contain the primitive type `GKR_TYPE_PROPERTY', but they may only appear in certain places and may only contain certain values, and is described in the next section. 3.4. Properties. Primary entry types (certificates and private keys) may also contain an optional properties list, which is nothing more than a series of (name, value) pairs. How these properties are interpreted is application-dependent, but some properties and their meanings will be defined in this document. Unsupported properties must not be cause for stopping the parsing of a keyring; properties are intended to give additional information about a particular entry, but they should not be considered crucial. There are, as of this writing, only two REQUIRED properties: "alias" -- this is a textual label that refers to the entry. This property MUST appear in all primitive types, except for packets of type `GKR_TYPE_PROPERTY'. draft-marshall-gnu-keyring-00 [Page 12] Marshall The GNU Keyring File Format September 2003 "alias-list" -- this is a list of all aliases that an envelope type contains. This property MUST appear in all envelope types, except for packets of type `GKR_TYPE_PROPERTY_SET'. 3.4.1. Property Set. #define GKR_TYPE_PROPERTY_SET 9 This is an additional envelope type that must only contain packets of the GKR_TYPE_PROPERTY type, and, naturally, does not contain a properties field. uint8 GKR_TYPE_PROPERTY_SET eos One or more GKR_TYPE_PROPERTY packets. 3.4.2. Property Type. #define GKR_TYPE_PROPERTY 10 uint8 GKR_TYPE_PROPERTY u8string Property name. u8string Property value. 4. Required Layouts. The layout for keyrings that contain trusted certificates (ring usage bit 2) is as follows: (GKR_TYPE_PBMAC (GKR_TYPE_COMPRESSED (... zero or more certificates and public keys.) ) ) The layout for keyrings that contain private keys and personal public credentials (ring usage bits 0 and 1) is as follows: (GKR_TYPE_PBMAC (GKR_TYPE_COMPRESSED (... zero or more private keys, public keys, or certificate chains.) ) ) Furthermore, entries of type `GKR_TYPE_PRIVATE_KEY' must be encoded as follows: (GKR_TYPE_PBMAC draft-marshall-gnu-keyring-00 [Page 13] Marshall The GNU Keyring File Format September 2003 (GKR_TYPE_PBE (GKR_TYPE_PRIVATE_KEY) ) ) Above, we usually assume that the MAC and encipherment use the same password, but different salts. Implementations are not required to handle encrypted and MAC'd packets with different passwords or keys, but they are not forbidden. In these constructions the password-based entries may be replaced by their raw-key variants. 4.1. Read-only Layouts. Constrained clients that need to be able to read trusted certificates (such as, for example, a `cacerts' keyring for keeping a static set of certificate authority certificates), but do not necessarily need to read personal keyrings or add new certificates. In this case, it is sufficient to be able to read only keyrings with usage bit 2 set. 5. GNU Raw Codec The primary encoding format of public and private keys in GNU Keyrings is the ``RAW'' codec used by GNU Crypto. 5.1. DSA DSA public keys are encoded as: uint32 The value 0x47014450. uint8 Version, currently 1. bigint p bigint q bigint g bigint y And private keys as: uint32 The value 0x47014470. uint8 Version, currently 1. bigint p bigint q bigint g bigint x 5.2. RSA draft-marshall-gnu-keyring-00 [Page 14] Marshall The GNU Keyring File Format September 2003 RSA public keys are encoded as: uint32 The value 0x47015250. uint8 Version, currently 1. bigint Modulus. bigint Public exponent. And private keys as: uint32 The value 0x47015270. uint8 Version, currently 1. bigint The prime p. bigint The prime q. bigint The public exponent e. bigint The private exponent d. 5.3. Diffie-Hellmann Diffie-Hellman public keys are encoded as: uint32 The value 0x47014850. uint8 Version, currently 1. bigint The prime modulus p. bigint The generator g. bigint The public value y. And private keys as: uint32 The value 0x47014870. uint8 Version, currently 1. bigint The prime divisor of p-1. bigint The prime modulus p. bigint The generator g. bigint The private exponent x. 6. Parsing Methodology. This format has been structured such that it is almost able to be parsed in one-pass; the only limit on this is for private keys that are contained in an MAC-then-encrypted envelope, when the key needed to decrypt and authenticate the packet may not be immediately available. Keyrings that only contain trusted certificates do not have this restriction, and can be parsed in a single pass. This limitation is imposed by the API of the java.security.KeyStore class, where a password is supplied to load the keystore from its external representation, and a password is supplied to retrieve a private key. Applications that do not need to adhere to this API can, draft-marshall-gnu-keyring-00 [Page 15] Marshall The GNU Keyring File Format September 2003 of course, obtain both required passwords and therefore parse personal keyrings in one pass. While the KeyStore API allows access to both trusted and personal credentials, the separation of these two in GNU keyrings (via the two REQUIRED ring usage types) obviates this; that is, one can access trusted credentials, or one can access personal credentials, but not both, at least not from the same file. There are few, if any, standard Java APIs that require the access of both types of data from a single file, so this requirement should not break any applications. 7. Other Formats. The need for a new file format for the storage of cryptographic data is not immediately apparent; there are, for example, a number of formats already being used as ``keystores'' in Java environments. Common formats include the JKS (Java Key Store), PKCS #12, and JCEKS (Java Cryptography Extension Key Store). JKS and JCEKS are proprietary, and should be avoided in favor of open standards. PKCS #12 [PKCS12] is an open standard, but is rather too complicated and badly designed. The format is basically the BER (basic encoding rules) of a group of ASN.1 (abstract syntax notation one) structures. BER as a transport format makes little sense; if the data types are well-defined enough (as the ones in this document are) then the simple rules of reading and writing such as described in this document should suffice. A compelling argument against PKCS #12 is found in [DESIGN]. Security Concerns. As the primary goal of this format is to preserve the integrity of sensitive cryptographic data, the methods with which these data are protected must be cryptographically secure, and the way in which they are used in this format must not weaken or undermine the security of the algorithms used. The recommended encryption/MAC scheme is the ``encrypt then MAC'' scheme, which is believed to be secure and has not shown the weaknesses found in alternative schemes, as [ORDER] points out. The AES, MACs based on MD5 and SHA, and KDF2 are currently accepted as secure, and as such we also assume that the most efficient way to forge or steal data from a GNU Keyring is a brute-force search of possible passwords, since we see no reason to believe that our usage draft-marshall-gnu-keyring-00 [Page 16] Marshall The GNU Keyring File Format September 2003 of these algorithms here weakens them unduly. It is possible, though unlikely, that our introduction of unenciphered data before enciphered data in the MAC-then-encrypt structure (such as that defined in section 4) can weaken the MAC, we believe that there is no evidence that this enables an attack. It is HIGHLY RECOMMENDED that applications enforce restrictions on the length and content of passwords, and recommend that passwords be at least eight characters long and contain at least one digit and one non-alphanumeric character. References. [AES] Federal Information Processing Standards (FIPS) 197: Specification for the Advanced Encryption Standard (AES), November 2001. [DESIGN] P. Gutmann, ``PFX - How Not to Design a Crypto Protocol/Standard''. [ORDER] H. Krawczyk, ``The order of encryption and authentication for protecting communications (Or: how secure is SSL?)'', June 2001. [PKCS8] RSA Laboratories, PKCS #8: Private-Key Information Syntax Standard, Version 1.2. November 1993. [PKCS12] RSA Laboratories, PKCS #12: Personal Information Exchange Syntax, June 1999. [RFC1321] R. Rivest, RFC 1321: The MD5 Message-Digest Algorithm, April 1992. [RFC1951] P. Deutsch, RFC 1951: DEFLATE Compressed Data Format Specification version 1.3, May 1996. [RFC2104] H. Krawczyk, M. Bellare and R. Canetti, RFC 2104: Keyed- Hashing for Message Authentication, February 1997. [RFC2119] S. Bradner, RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, March 1997. draft-marshall-gnu-keyring-00 [Page 17] Marshall The GNU Keyring File Format September 2003 [RFC2315] B. Kaliski, RFC 2315: PKCS #7: Cryptographic Message Syntax, Version 1.5. March 1998. [RFC2898] B. Kaliski, RFC 2898: PKCS #5: Password-Based Cryptography Specification, Version 2.0. September 2000. [RFC3174] D. Eastlake 3rd and P. Jones, RFC 3174: US Secure Hash Algorithm 1 (SHA1), September 2001. [RFC3280] W. Ford, R. Housley, W. Polk and D. Solo. RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. April 2002. Authors' Addresses Casey Marshall email: rsdio@metastatic.org Full Copyright Statement. Copyright (C) 2003 Casey Marshall. Verbatim copying and distribution of this entire document is permitted in any medium, provided that this notice is preserved. GNU Crypto copyright (C) 2001,2002,2003 The Free Software Foundation, Inc. GNU Crypto is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU Crypto is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to the Free Software Foundation Inc., 59 Temple Place - Suite 330, draft-marshall-gnu-keyring-00 [Page 18] Marshall The GNU Keyring File Format September 2003 Boston, MA 02111-1307 USA Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. draft-marshall-gnu-keyring-00 [Page 19]