|
|
The GNU Crypto project |
GNU Crypto Project C. Marshall
draft-marshall-gnu-keyring-00 September 2003
Expires: March 2004
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 . . . . . . . . . . . . . . . . . . . . . . XX
1.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . XX
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . XX
2. Magic Bytes/Version Number . . . . . . . . . . . . . . . XX
2.1. Ring Usage . . . . . . . . . . . . . . . . . . . . . . . XX
3. Packets . . . . . . . . . . . . . . . . . . . . . . . . . XX
3.1. Properties . . . . . . . . . . . . . . . . . . . . . . . XX
3.1.1 Property Packets . . . . . . . . . . . . . . . . . . . . XX
3.2. Envelope Types . . . . . . . . . . . . . . . . . . . . . XX
3.2.1. Encrypted . . . . . . . . . . . . . . . . . . . . . . . . XX
3.2.2. Password-Encrypted . . . . . . . . . . . . . . . . . . . XX
3.2.3. Authenticated . . . . . . . . . . . . . . . . . . . . . . XX
3.2.4. Password-Authenticated . . . . . . . . . . . . . . . . . XX
3.2.5. Compressed . . . . . . . . . . . . . . . . . . . . . . . XX
3.3. Extension Values . . . . . . . . . . . . . . . . . . . . XX
3.4. Primitive Types . . . . . . . . . . . . . . . . . . . . . XX
3.4.1. Trusted Certificates . . . . . . . . . . . . . . . . . . XX
3.4.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . XX
3.4.3. Private Keys . . . . . . . . . . . . . . . . . . . . . . XX
3.4.4. X.509 Certificate Paths . . . . . . . . . . . . . . . . . XX
3.4.5. Binary Data . . . . . . . . . . . . . . . . . . . . . . XX
3.4. Properties . . . . . . . . . . . . . . . . . . . . . . . XX
draft-marshall-gnu-keyring-00 [Page 1]
Marshall The GNU Keyring File Format September 2003
3.4.1. Property Set . . . . . . . . . . . . . . . . . . . . . . XX
3.4.2. Property Type . . . . . . . . . . . . . . . . . . . . . . XX
4. Required Layouts . . . . . . . . . . . . . . . . . . . . XX
4.1. Read-only Layouts . . . . . . . . . . . . . . . . . . . . XX
5. GNU Raw Codec . . . . . . . . . . . . . . . . . . . . . XX
5.1. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . XX
5.2. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . XX
5.3. Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . XX
6. Parsing Methodology . . . . . . . . . . . . . . . . . . XX
7. Other Formats . . . . . . . . . . . . . . . . . . . . . . XX
Security Considerations . . . . . . . . . . . . . . . . XX
References . . . . . . . . . . . . . . . . . . . . . . . XX
Authors' Addresses . . . . . . . . . . . . . . . . . . . XX
Full Copyright Statement . . . . . . . . . . . . . . . . XX
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.
draft-marshall-gnu-keyring-00 [Page 2]
Marshall The GNU Keyring File Format September 2003
1.1. Data Types.
Data read and written to keyrings will be one of the following types:
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 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.
draft-marshall-gnu-keyring-00 [Page 3]
Marshall The GNU Keyring File Format September 2003
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
(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].
draft-marshall-gnu-keyring-00 [Page 4]
Marshall The GNU Keyring File Format September 2003
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.
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
draft-marshall-gnu-keyring-00 [Page 5]
Marshall The GNU Keyring File Format September 2003
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.
draft-marshall-gnu-keyring-00 [Page 6]
Marshall The GNU Keyring File Format September 2003
3. Packets.
The keyring shall then contain one or more packets, all of which,
aside from a few exceptions, have the following form:
uint8 Content-type.
os Properties.
os Packet data.
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.
Unknown or unsupported content types do not necessarily mean that
parsing should stop, especially in the case of packets marked
OPTIONAL in this
3.1. Properties.
Every packet begins with a set of ``properties'' -- a series of name-
value pairs. These properties have a variety of uses, from naming
packets to defining the algorithms used in encoding packets.
Property packets are the only exception to the packet encoding rule
above.
3.1.1. Property packets.
The data of the ``properties'' field in packets is a sequence of one
or more of the following packets:
u8string Property name.
u8string Property value.
Property names are treated case-insensitively, while property values
are not, unless specified otherwise.
Different types of packets require certain properties to be defined
in the packet. These properties will be described along with the
description of that packet.
draft-marshall-gnu-keyring-00 [Page 7]
Marshall The GNU Keyring File Format September 2003
3.2. 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
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.
draft-marshall-gnu-keyring-00 [Page 8]
Marshall The GNU Keyring File Format September 2003
3.2.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.2.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.
The encrypted data field is the encoded contained packets encrypted
with the cipher.
Encrypted packets require the following properties, whose values are
treated case-insensitively:
cipher -- This is the name of the cipher algorithm. At minimum,
implementations must recognize the value "AES", which means the
Advanced Encryption Standard cipher, described in [AES]. The
key length for this cipher is 128 bits.
mode -- This is the name of the mode that the cipher is used in.
Implementations must be able to support the "OFB" and "CBC"
modes, which correspond to the Output Feedback mode and the
Cipher Block Chaining mode.
keylen -- The length of the key passed to the cipher, in bytes.
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 % bs) == 1
02 02 if (L % bs) == 2
...
16 16 ... 16 if (L % bs) == 0
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.
draft-marshall-gnu-keyring-00 [Page 9]
Marshall The GNU Keyring File Format September 2003
3.2.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.
The required properties are the same as in `GKR_TYPE_ENCRYPTED', with
the following additional properties:
salt -- This is a random eight-byte value, encoded as a
hexadecimal string. That is, the string "0123456789ABCDEF" is a
valid value. This property is case-insensitive.
Conformant applications MUST be able to parse password encrypted
envelopes, and it is the default mode of protection.
Two values are derived from the password, a key for the cipher, and
an initialization vector. The length of the derived key is the value
of the "keylen" property, and the IV length is the cipher's block
size.
(dk,iv) = PBKDF2 (UTF8(password), salt, 1000, dkLen + bs)
draft-marshall-gnu-keyring-00 [Page 10]
Marshall The GNU Keyring File Format September 2003
3.2.3. Authenticated.
#define GKR_TYPE_MAC 2
Authenticated enveloped types run a keyed message authentication code
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.
The required properties for authenticated envelopes are:
mac -- The name of the MAC algorithm to use. Required values for
this property are "HMAC-MD5" and "HMAC-SHA-1". The HMAC is
described in [RFC2104], MD5 is described in [RFC1321], and
SHA-1 in [RFC3174].
maclen -- The length of the MAC.
The authenticated data field is structured as follows:
byte[n-maclen] The to-be-authenticated data.
byte[maclen] The MAC of the preceding.
The value `n' is equal to the length of the packet data octet
sequence.
This type, like the `GKR_ENCRYPTED' type, is OPTIONAL, and the same
rules apply to this packet type.
draft-marshall-gnu-keyring-00 [Page 11]
Marshall The GNU Keyring File Format September 2003
3.2.4. Password-Authenticated.
#define GKR_TYPE_PBMAC 3
Password-authenticated enveloped types use a password KDF in similar
fashion as password-encrypted enveloped types, but with a keyed
message authentication code. Like that packet type, there is an
additional required property "salt".
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
================ =====
HMAC-MD5 16
HMAC-SHA-1 20
3.2.5. Compressed.
#define GKR_TYPE_COMPRESSED 4
Compressed envelope types compress their contents with a standard
compression algorithm.
Compressed envelopes require the following property:
algorithm -- The name of the compression algorithm to use. The
only required value for this property is "DEFLATE", which is
described in [RFC1951].
Conforming implementations MUST be able to decompress DEFLATE-
compressed envelopes.
3.3. Extension values.
Packet types not defined in this document are reserved for future
use. They MUST NOT appear in version 1 keyrings.
draft-marshall-gnu-keyring-00 [Page 12]
Marshall The GNU Keyring File Format September 2003
3.4. Primitive Types.
Primitive types contain a single cryptographic entity. All primitive
types require the following properties:
alias -- A non-empty string that uniquely identifies the entry.
Alias names need only be unique across a single type, e.g. a
private key entry and a certificate path entry can share the
same alias.
creation-date -- The date that this entry was created, measured in
milliseconds since 00:00:00 GMT, January 1, 1970. The value is
written as a decimal string.
Conforming implementations MUST be able to parse all primitive types
described in this section.
3.4.1. Trusted Certificates.
#define GKR_TYPE_CERT 5
This value denotes a ``trusted certificate entry''. The packet data
is the encoded form of the certificate. These packets require the
following property:
type -- The type of certificate that is encoded. This can be, for
example, "X.509", which will denote X.509 certificates encoded
as a DER-encoded ASN.1 sequence, as described in [RFC3280].
3.4.2. Public Keys.
#define GKR_TYPE_PUBLIC_KEY 6
This value denotes an asymmetric public key. The required property
for these packets is:
type -- The type of key, and its encoding method. Required values
include "RAW-DSA", "RAW-RSA", "RAW-DH", and "X.509". The "RAW"
encodings are described in section 5. The "X.509" encoding
denotes a DER-encoded SubjectPublicKeyInfo ASN.1 structure, as
described in [RFC3280].
3.4.3. Private and Secret Keys.
#define GKR_TYPE_PRIVATE_KEY 7
This value denotes an asymmetric private key, or a symmetric secret
key. The required property for these packets is:
draft-marshall-gnu-keyring-00 [Page 13]
Marshall The GNU Keyring File Format September 2003
type -- The type of key, and its encoding method. Required values
include "RAW-DSA", "RAW-RSA", "RAW-DH", and "PKCS8". The "RAW"
encodings are described in section 5. The "PKCS8" encoding
denotes a DER-encoded PrivateKeyInfo ASN.1 structure, as
described in [PKCS8].
3.4.4. X.509 Certificate Paths.
#define GKR_TYPE_X509_PATH 8
This value denotes an X.509 certificate path, which typically
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.
There are no additional properties required for this type. The packet
data is simply the concatenation of one or more DER-encoded X.509
certificates, which are described in [RFC3280].
3.4.5. Binary Data.
#define GKR_TYPE_BINARY_DATA 9
This value denotes a generic way to encode arbitrary binary data in
the keyring. No processing of these packets is required by
implementations, and their data may be discarded if not needed by the
implementation.
There are no additional required properties, but the following
property MAY be included in the packet:
content-type -- A valid content type descriptor (e.g.
"text/plain") that defines the type of data encoded in the
packet data field.
draft-marshall-gnu-keyring-00 [Page 14]
Marshall The GNU Keyring File Format September 2003
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
(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.
draft-marshall-gnu-keyring-00 [Page 15]
Marshall The GNU Keyring File Format September 2003
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
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.
draft-marshall-gnu-keyring-00 [Page 16]
Marshall The GNU Keyring File Format September 2003
5.3. Diffie-Hellman
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.
draft-marshall-gnu-keyring-00 [Page 17]
Marshall The GNU Keyring File Format September 2003
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,
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.
When and if an unsupported packet is encountered, such as an
unrecognized encoding scheme, the parser SHOULD continue to parse the
rest of the keyring, but not decode the packet data. This goes for
OPTIONAL envelopes described above.
Packet types not defined in this document should raise a fatal error.
draft-marshall-gnu-keyring-00 [Page 18]
Marshall The GNU Keyring File Format September 2003
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
of these algorithms here weakens them unduly. It is possible, though
unlikely, that our introduction of unenciphered data before
enciphered data in the encrypt-then-MAC 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.
draft-marshall-gnu-keyring-00 [Page 19]
Marshall The GNU Keyring File Format September 2003
References.
[AES] Federal Information Processing Standards (FIPS) 197:
Specification for the Advanced Encryption Standard (AES),
November 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[DESIGN] P. Gutmann, ``PFX - How Not to Design a Crypto
Protocol/Standard''.
http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html
[ORDER] H. Krawczyk, ``The order of encryption and authentication
for protecting communications (Or: how secure is SSL?)'',
June 2001. http://eprint.iacr.org/2001/045/
[PKCS8] RSA Laboratories, PKCS #8: Private-Key Information Syntax
Standard, Version 1.2. November 1993.
ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-8.asc
[PKCS12] RSA Laboratories, PKCS #12: Personal Information Exchange
Syntax, June 1999.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf
[RFC1321] R. Rivest, RFC 1321: The MD5 Message-Digest Algorithm,
April 1992. http://www.ietf.org/rfc/rfc1321.txt
[RFC1951] P. Deutsch, RFC 1951: DEFLATE Compressed Data Format
Specification version 1.3, May 1996.
http://www.ietf.org/rfc/rfc1951.txt
[RFC2104] H. Krawczyk, M. Bellare and R. Canetti, RFC 2104: Keyed-
Hashing for Message Authentication, February 1997.
http://www.ietf.org/rfc/rfc2104.txt
[RFC2119] S. Bradner, RFC 2119: Key words for use in RFCs to Indicate
Requirement Levels, March 1997.
http://www.ietf.org/rfc/rfc2119.txt
[RFC2315] B. Kaliski, RFC 2315: PKCS #7: Cryptographic Message
Syntax, Version 1.5. March 1998.
http://www.ietf.org/rfc/rfc2315.txt
[RFC2898] B. Kaliski, RFC 2898: PKCS #5: Password-Based Cryptography
Specification, Version 2.0. September 2000.
http://www.ietf.org/rfc/rfc2898.txt
draft-marshall-gnu-keyring-00 [Page 20]
Marshall The GNU Keyring File Format September 2003
[RFC3174] D. Eastlake 3rd and P. Jones, RFC 3174: US Secure Hash
Algorithm 1 (SHA1), September 2001.
http://www.ietf.org/rfc/rfc3174.txt
[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.
http://www.ietf.org/rfc/rfc3280.txt
Authors' Addresses
Casey Marshall
email: rsdio@metastatic.org
draft-marshall-gnu-keyring-00 [Page 21]
Marshall The GNU Keyring File Format September 2003
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,
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 22]
Return to GNU's home page.
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
Please send comments on these web pages to webmasters@gnu.org, send other questions to gnu@gnu.org.
Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
Last Modified: $Date: 2004/01/28 02:57:45 $ $Author: rsdio $