[479] in WWW Security List Archive
Keyring file format.
daemon@ATHENA.MIT.EDU (Phillip M. Hallam-Baker)
Tue Feb 28 20:39:39 1995
To: www-security@ns2.rutgers.edu
cc: hallam@dxal18.cern.ch
Date: Tue, 28 Feb 1995 20:25:46 +0900
From: "Phillip M. Hallam-Baker" <hallam@dxal18.cern.ch>
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
Before coding away I thought I might put this up for comments. The point is we
need some file formats for storing certificates. It would be very handy if these
could be shared. The browsers and servers can all sing from the same songsheet.
This is a combination of ideas from PGP, RIPEM and RFC-822. I'm doig the API as
a separate module so that non libwww/shen people can retrofit. Comments anyone?
Draft-RFC: Public Key Ring File format.
HTTP Security Working Group
Expires in six months.
Hallam-Baker
February 28 1995
DRAFT-RFC: PUBLIC KEY RING FILE FORMAT :REVISION 5.
draft-hallam-http-keyring-00.html
Note that the format of this note is slightly non-standard because I have
not yet found the famous html to rfc converter.
Status of this Memo
This document is a submission to the IP Security Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted to the
www-security@ns2.rutgers.edu.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its Working
Groups. Note that other groups may also distribute working documents as
Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months, and
may be updated, replaced, or obsoleted by other documents at any time. It
is not appropriate to use Internet Drafts as reference material, or to cite
them other than as a ``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
This draft is also avaliable as hypertext at
http://dxal18.cern.ch/WWW/Security/Documentation/rfc-keyring.html
Introduction.
Certificate management is a key issue in any public key based security
system. Lack of common standards makes interoperation of different security
products difficult. In addition existing formats lack certain features
required by graphical interface clients.
Permit greater flexibility than supported by systems developed for use
with email based systems.
Be interoperable with other packages especially PGP and RIPEM.
Support extended trust attributes.
Be compatible with maintenence via a Web server.
Allow icons to be associated with certificates permitting a visual
indication of the source of a document.
Be distributable.
EXAMPLE:
In the following example the author has two private keys and two public
keys. The first private key is for routine use is is valid only for
signatures, the second has a certificate which specifies it may be used to
sign contracts. The details of these restrictions are not included in the
key ring itself. Icons to asist in the correct choice of seal are however.
Default: root=http://wit.w3.org/Certificates/hallam;
digest-alg=MD5
Private: signature.prv; cert=signature.pub; alias="hallam";
icon=myseal.gif
Private: moneysig.prv; cert=moneysig.pub; alias="hallam";
icon="mycash.gif"
Public: http://www.w3.org/Certificates/timbl.pub;
alias="timbl@w3.org"; digest="qwQWdklweWeiwqeg==";
icon="tim.gif"
Public: http://www.whitehouse.gov/Certificates/clinton.pub;
alias="clinton@whitehouse.gov";
digest="wekjWjEiwWjgWEhhw=="; icon="bill.gif"
Key-Ring: pgp_keys; application=pgp
Key File Format.
The file format conforms to RFC 822 with the exception that lines may be
terminated using CRLF, CR or LF. this is to permit editing with a standard
editor.
Agent=name Name of the agent which originated the header. This
attribute may be used to construct audit trails.
Alias=name Specifies an alias for the given certificate name.
This alias is used to map internet names onto X.500
distinguished names.
Application=name Specifies an application
Certificate=URI Used to specify the location of a certificate
asscociated with a private key for applications that
do not store public key information in private key
files.
Digest=Hex[value] Specifies a digest value for the referenced object.
Although this field could be encoded more compactly
using base64 encoding, hexadecimal is used since it is
widely used for exchange of digest values.
Digest-Object Allows specification of the part of an object a digest
relates to. This is required since the digest value
is often given for the key info value alone and not
for the certificate relating to the key info.
Digest-Alg=Algid Defines the digest algorithm used to create the
digest. Possible values include RSA-MD5 and RAS-MD2.
Digest-Limit=octets Specifies a size for a digest protected object. This
is for use with dynamic append-only objects and allows
the file to be extended without rendering the digest
value invalid for previously validated objects.
Domain=[URNset] Specifies a set of URNs.
Guarantor=CertId Specifies the identifier of a certificate used to
validate the object prior to inclusion in the keyring.
This attribute may be used to mark the inclusion of
the object for review should the bonafides of a
guarantor be considered suspect at a later date.
Icon=URI Specifies the URI of an icon to be associated with the
use of the given name.
Root=URI Specifies the root to be used for relative URIs. If no
root is specified the default is the URI of the file
itself.
Serial-Number=Hex[Value]
Specifies the serial number of a certificate.
Trust=[Trust Attribute]
Defines the trust attributes granted to the object.
URN=[URN] Specifies the URN associated with the given
certificate. For an X509 certificate this would be the
URN corresponding to the X509 distinguished name.
DEFAULT: [ATTRIBUTES]
The default header permits default values to be specified for common
attributes.
Digest-Alg The default digest algorithm.
Root The default root to be used to resolve partial URLs
The following attributes are defined.
PUBLIC: URI [ATTRIBUTES]
The following attributes are defined.
Digest, Digest-Alg, Digest-Limit, Guarantor
For verifying the authenticity of the certificate
Alias, Serial-Number, Icon
For identification and indexing purposes.
Trust For sepcifying the trust attributes associated with
the certificate.
PRIVATE: URI [ATTRIBUTES]
Specifies the location of a private key file. A private key file may
optionaly incorporate certificate information. Alternatively the location of
certificate information associated with a file may be specified separately.
The following attributes are defined:
Digest, Digest-Alg, Digest-Limit, Guarantor
For verifying the authenticity of the certificate
Alias, Serial-Number, Icon
For identification and indexing purposes.
Trust For sepcifying the trust attributes associated with
the certificate
REVOKE: URI [ATTRIBUTES]
Specifies that any preceeding occurrence of the object corresponding to the
given URI should be ignored. Note that the implementation of this tag
prevents partial parsing of a keyring. This is not considered a significant
problem since the limitations of sequential files are best dealt with by
employing fast access indicies.
This tag permits a certificate to be marked as revoked by simply appending
to the keyfile. This is to asist automatic keyring management in
envrionments where multiple agents may potentialy attempt to update the
keyfile simultaneously. The use of revoke headers also permits a
conservative approach to certificate management wherby certificates are
invalidated agressively without information being lost. Another advantage is
that it permits the digest limit tag to be used.
KEY-RING: URI [ATTRIBUTES]
Specifies an external keyring to be used. The keyring may optionaly be in a
different format such as RIPEM or PGP.
Domain Specifies the range of names refered to by the keyring
Digest, Digest-Alg, Digest-Limit, Guarantor
for verifying the authenticity of the key-ring
Alias, Serial-Number, Icon
For identification and indexing purposes.
Note that the digest authentication of a dynamic item may be problematic. It
might be preferable to employ some scheme whereby a specific portion of the
file might be verifie
SIGNATURE: ALGORITHM, CERT-ID, VALUE
The signature header is used to incorporate a signature within the keyring.
The use made of signature information is application specific.
CACHE: URI [ATTRIBUTES]
Specifies the location of a cache directory used to store certificates. The
format of such a cache directory is not defined by this specification.
Consequently conforming implementations must specify the application
attribute.
Application Name of the application specific cache format.
X-attribute Extension attributes as defined by the application.
These attributes may specify parameters associated
with the caching scheme such as maximum size. Cache
scheme developers are encouraged to store this
information within the cache structure itself wherever
possible however.
Key file format
The default key file formats are described below. This specification permits
compatibility with RIPEM which is based on the PEM and PKCS standards.
PUBLIC KEYS
Public keys are stored as a sequence of RFC822 conformant headers with
BASE64 encoded values. This format permits certificates to be passed out of
band via email and avoids problems associated with byte order when using
networked files on multiple platforms. The following tags are defined:
User: Username The username associated with the public key in
internet format.
PublicKeyInfo: value The public key info value encoded in ASN.1 DER format
using the format defined in PKCS #1, PKCS #3 and
X.509.
MD5OfPublicKey: Hex[value]
The MD5 value of the public key info value
UserDistinguishedName: DistinguishedName
The ASN.1 distinguished name of the object in ASCII
form.
CertificateInfo: Base64[value]
The X.509 or PKCS #6 certificate value.
Example:
User: hallam@dxal18
PublicKeyInfo:
MFkwCgYEVQgBAQICAgADSwAwSAJBAO6edGIcp2iLHu7CQU9Wo5wpagMmIqh/p7Y1
eHPEkBRnECXwAloBJk8yQe9woY+3gTOKl8cj3aFESMIl/rMvAlECAwEAAQ==
MD5OfPublicKey: 5B828C28C185F3B09C02F63C7C4D3391
UserDistinguishedName: CN = hallam@dxal18, OU = Persona Certificate, O = RSA Da
t
a Security, Inc., C = US
CertificateInfo:
MIIBwDCCAWoCEFyvuORNzRfKCdw4KyEMCqEwDQYJKoZIhvcNAQECBQAwZTELMAkG
A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRYwFAYDVQQDFA1oYWxsYW1AZHhhbDE4
MB4XDTk1MDIxNDEzNDkxMFoXDTk3MDIxMzEzNDkxMFowZTELMAkGA1UEBhMCVVMx
IDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJz
b25hIENlcnRpZmljYXRlMRYwFAYDVQQDFA1oYWxsYW1AZHhhbDE4MFkwCgYEVQgB
AQICAgADSwAwSAJBAO6edGIcp2iLHu7CQU9Wo5wpagMmIqh/p7Y1eHPEkBRnECXw
AloBJk8yQe9woY+3gTOKl8cj3aFESMIl/rMvAlECAwEAATANBgkqhkiG9w0BAQIF
AANBADz5WeMKGTsjiXx1o8kZJ7GaEVo77u4zWDQ2V3VF6h0HHmS3OLPEjGwdMGBx
l2Pix8KAmbfK6oa19FhvqPo+Mcc=
PRIVATE KEYS
The format for the private key is based on the PKCS #5 and PKCS #8 formats.
The following tags are defined:
User: Username The username associated with the public key in
internet format.
EncryptedPrivateKeyInfo: Base64[value]
The private components of the public key encoded in
PKCS #8 format then encrypted using the PKCS #5
password based encryption standard.
Example:
User: hallam@dxal18
EncryptedPrivateKeyInfo:
MIIBgDAaBgkqhkiG9w0BBQMwDQQIB7nhEIy9ezUCAWQEggFgn1NMRT5At55jn2k1
s123CHoiYl9DwDVtYkovIkoPWAMoBPEnlhZ1MQl34wUCS0eIAEduA8xN9ccwLEx1
1ShZgXt4TbP5mMDlh4uKyE0Fw44US9N7fRXdZjyqv2dZAvlBNFsvmrtageUQJPG3
oUTzYk1nu8va3PhOO/zwGKGy/Q5S5rYAbSX2Yy3nJXABbUKdUskhGIQttFe3ymVZ
pnPT17Hatv0O/7Thu5ST/wDk0bpQpc68nAdd0pxienUodZ0baTBMVsml2CPHE7wZ
T9urJcyHU2pv8XJYxpQnk7OtSdEu16rlrb174a+GGkliYaqKImJ7cayFsCDeEZt0
ZZy0JMCNuG5Gvd0jgexuWscKhEJM87avLnvyXC5f7KQ0I4DlEi6LNxn5IjDXd68W
yzYF5RUbX+gUrSncWBeq1DjngFpxXwMR+zD8TQYtb+3xrKa0uLAa+AyjYI45iHPo
sgq7vw==
RIPEM COMPATIBILITY.
For compatibility with RIPEM, public and private key components must be
stored separately encapsulated as shown bellow. Implementations may chose to
store both public and private components of the key in the same file and
omit the encapsulation however.
Public Keys
-----BEGIN PUBLIC KEY-----
... Data as before omitted ...
-----END PUBLIC KEY-----
Private Keys
-----BEGIN PRIVATE KEY-----
... Data as before omitted ...
-----END PRIVATE KEY-----
Operations Guide
INDEX STRUCTURE.
Access to the key ring file may be optimised by creation of aseparate access
index. Note that such structures should be designed so as to permit partial
indexing of the file. Programs employing the index should always scan any
unindexed portion of the file to detect revokation headers appended after
the index was constructed.
MANUAL MAINTENENCE
The file format is intended to be editable using a standard editor. Thus the
file format is ASCII based. It is essential that implementations accept CR
and LF as equivalent to CRLF in order to permit maximum interoperability.
AUTOMATIC MAINTENENCE.
The keyring may also be used to cache the results of key verification
operations. This avoids the need to validate certificate chains for every
operation.
In a high performance implementation certificate chain validation might be
performed offline at an interval consistent with the security policy of the
site.
Security Considerations.
This whole document is about security.
Glossary and definition of terms
The following terms are used:
Public Key The half of a public keypair which may be made public.
Private Key The half of a public key pair which is kept secret.
Key Certificate A certificate which relates to the authenticity of a
public key
Certificate Any object bearing a signature attesting to the
authenticity of a relationship between an object and a
set of attributes.
Certificate chain A certificate chain consists of a sequence of
certificates such that each successive element in the
series is authenticated by its predecessor.
Asymmetric Encryption Algorithm.
An encryption algorithm in which the keys used for
encryption and decryption are different. If for a
given algorithm it is computationaly infeasible to
determine one of the keys from another that algorithm
is a public key encryption algorithm.
Public Key Encryption Algorithm
An asymmetric encryption algorithm in which it is
computationaly infeasible to determine one of the keys
from another.
Symmetric Encryption Algorithm.
An encryption algorithm in which the same key is used
for encryption and decryption.
NB: The definition of certificate here differes from that used in the PEM
specifications where all certificates are key certificates.
References.
Ok.. I'll do them sometime, just that I want to send this out tonight so I
can get comments and the shops close in 10 minutes.
Authors Address.
Phillip. M. Hallam-Baker.
Hallam@w3.org
