Internet Draft Narayan Raghu
IBM Global Services India ltd.
Expires in 6 months Sept. 1998
ATOMIC CERTIFICATES
<draft-raghu-atomic-certificates-00.txt>
Status of this Memo
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 inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast),
or ftp.isi.edu (US West Coast).
ABSTRACT
The existing PKI has a few inherent limitations like:
1. It is implicitly assumed that the two trading parties have ONE
mutually trusted third party that can attest ALL of each
party's attributes. It provides no mechanism to separate out the
fields in a certificate for attestation by different Certification
Authorities.
2. This standard in no way gives the flexibility to expose only
certain fields of a certificate to the other party.
Narayan Raghu [Page 01]
INTERNET-DRAFT Atomic Certificates Sep 1998
This memo proposes a model which, while working well within the
X.509v3 framework, overcomes these limitations by
breaking up a certificate into pre-signed "unit attestations"
referred to as "Atomic Certificates" and packaging them in the
X.509v3 format only at the time of sending the certificate to the
other party.
1. INTRODUCTION
The X.509 certificates and the PKI as described in RFC 1422 are
aimed at IDENTIFYING an entity, rather than ATTESTING TO AN ATTRIBUTE
OF an entity. This view of the PKI was taken, since RFC 1422 relies
heavily on the "Distinguished Name" concept, as defined in the
directory system (X.500). For most parts of on-line
commerce however, what is really needed is an attested attribute of an
entity quite often not even leading to the complete "identification"
of the entity as we know it.
However, moving away from the X.509 standard would mean huge effort
in terms of re-coding large parts of existing software, and would
certainly be unacceptable.
This memo describes a system that eliminates the inherent
disadvantages of the X.509 certificates and the existing PKI, while at
the same time sticking to the standards so that little changes are
required in the existing software.
1.1 ORGANIZATION OF THIS MEMO
This memo starts with identifying the underlying problems in the
existing PKI, and goes into the root of those problems.
It then defines the various terms to be used in the Memo, in section
3. Section 4 explains the concept of Atomic Certificates.
Section 5 gives implementation details. The draft closes with section
6, listing out some of the advantages of this system, and section 7
touching upon compatibility issues.
2. LIMITATIONS OF THE EXISTING PKI
The inherent limitations of the existing PKI are :
1. It is implicitly assumed that the two trading parties have ONE
mutually trusted third party that can attest ALL of each
party's attributes. It provides no mechanism to separate out the
fields in a certificate for attestation by different Certification
Authorities. It does NOT acknowledge the fact that TRUST is always
Narayan Raghu [Page 02]
INTERNET-DRAFT Atomic Certificates Sep 1998
WITH RESPECT TO something.
In short, there is no means to associate a CA with an attribute, and
designate that CA as the Root ONLY for THAT attribute.
2. This standard in no way gives the flexibility to expose only
certain fields of a certificate to the other party.
3. Going by the existing setup encourages the client to
maintain a disproportionately large number of certificates,
and considering that certain implementations force the use of a
new key pair for each new certificate, the client is forced to
maintain multiple key-pairs in addition to multiple certificates.
4. This standard almost implicitly imposes the usage of a sort of
globally managed system in X.500 directories for storage of
certificates.
2.1 Root Cause of these limitations: A question of Perspective
The current view of a certificate is that it is primarily an
identifying document which can also be used to attest to a few
attributes of the entity if so desired.
- Since it's all about identification, no methods were built in to get
different CAs to attest to different attributes, since Attributes
are, really work-arounds to make Attribute-Assertions to an already
existing concept of identification. This leads to the first problem.
- Certificates are about Identification. Internet users require a
degree of Anonymity. But certificates are to be Published.
This is really a paradox, since the requirement of Anonymity clashes
with the requirement for identification imposed by certificates.
This leads directly to the second problem listed.
The Certification management described in RFC 1422 relies heavily on
the Directory System, which really forces identification of the
entity. The introduction of v3 extensions, and options to include only
certain RDNs and exclude the others are really a desperate attempt to
solve the problems that wouldn't have been there in the first place if
the PKI had been designed around ATTRIBUTE-ASSERTIONS rather than
IDENTIFICATION.
This Memo sees Certificates as a collection of Attribute-Assertions,
which may or may not aid in identifying the entity that has been
certified.
Narayan Raghu [Page 03]
INTERNET-DRAFT Atomic Certificates Sep 1998
This view is really more general, since the "Distinguished Name" is
also an attribute of the entity, along with other attributes it might
have. So, in that one sense, the PKI as we know today is in effect
a special case of the more general case of Atomic Certificates.
3. DEFINITION OF TERMS
Certificate Holder - An entity which applies for and gets an
Atomic Certificate from a Certification Authority
Certificate Verifier - An entity that needs to know, with certainty,
the Attribute-Values of another entity.
Attribute - Information of a particular type.
Certification Authority (CA) - An authority trusted by one or more
Certificate Verifiers to attest to the Value of a particular attribute
of a Certificate Holder.
Atomic Certificate - The public key of a Certificate Holder, together
with one attribute-value pair rendered unforgeable by encipherment
with the private key of the Certification Authority which issued it.
Certificate - a collection of (one or more) Atomic Certificates.
4. ATOMIC CERTIFICATES
This concept proposes to break up the Certificate into chunks of
Unit Attestations, and then put them together whenever required, in
any combination required. These Unit Attestations are referred to here
as "Atomic Certificates", since they cannot be broken down further.
Each attestation can be made by a different Certification Authority,
as required by the Certificate Verifier. The Certificate Holder can
have chunks of unit attestations on his client machine, which he can
mix-n-match before sending to the Certificate Verifier.
On the Certificate Holder's machine, this is what the scenario would
look like:
PubKey1 -- "ColorOfHair=Black" -- attests CA1
PubKey1 -- "emailID=r1naray@in.ibm.com" -- attests CA2
PubKey1 -- "CityOfResidence=Bangalore" -- attests CA3
Narayan Raghu [Page 04]
INTERNET-DRAFT Atomic Certificates Sep 1998
PubKey1 -- "Employer=IBM" -- attests CA4
Pubkey2 -- "ShoeSize=9" -- attests CA5
pubkey2 -- "DateOfBirth=31101974" -- attests CA6
The Certificate Holder can use the first four certificates in any
combination, but will not be able to use them alongside the last
two, for implementation reasons. The Certificate Holder can mix and
match the first four, and also add more attestations to the PubKey1,
in order to increase the number of combinations that can be made. This
in effect encourages having a single key-pair but multiple
attestations associated with a person.
5. IMPLEMENTATION OF ATOMIC CERTIFICATES
5.1 High level description
The Atomic Certificate can be realized by constructing an
X.509v3 certificate with the "Subject Name" field blank and adding
exactly one extension, with criticality bit set to TRUE.
All other aspects of the X.509v3 certificate including the CA Name
can remain as it is. Chaining can be implemented if required.
These Atomic Certificates can be put into a "Packaging Certificate".
The Packaging Certificate is essentially a SELF SIGNED X.509v3
Certificate that contains NO CA Name OR Subject Name and that
contains all the Atomic Certificates as v3 extensions. Since the
Packaging Certificate is self signed, the Certificate Holder can
prepare it just before sending it to the Certificate Verifier,
depending upon which attributes the Certificate Verifier requires,
and which root CAs he trusts.
The verifier can verify the signature on the Packaging Certificate,
and then attempt to verify each of the Atomic Certificates
by traversing up to each of their trusted roots separately.
If all of them are OK, the Verifier can then proceed with the
transaction.
Note that the negotiation as to which atomic certificates are needed
by the verifier is the responsibility of the hand-shaking part of the
protocol that uses these certificates, and hence is outside the scope
of this memo.
Narayan Raghu [Page 05]
INTERNET-DRAFT Atomic Certificates Sep 1998
PACKAGING Certificate
(X.509v3 self signed certificate)
_______________________________________
| _____________________________ |
| | | |
| | Cert Num, Date, etc. | |
| |_____________________________| |
| |
| v3 Extensions: |
| _____________________________ |
| | | |
| | AtomicCert1 (X.509v3) | |
| | AtomicCert2 (X.509v3) | |
| | AtomicCert3 (X.509v3) | |
| | AtomicCert4 (X.509v3) | |
| |_____________________________| |
| |
|_______________________________________|
5.2 ASN.1 formats
ASN.1 Structure of Atomic Certificates and the Packaging Certificate
Attention is drawn to the differences between Atomic Certificates and
normal X.509v3 certificates by a "--note".
IMPORTS
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier, GeneralizedTime, Name
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
AtomicCertificate ::= SEQUENCE{
tbsCertificate TBSAtomicCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
TBSAtomicCertificate ::= SEQUENCE {
version [0] EXPLICIT Version3 -- note
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
Narayan Raghu [Page 06]
INTERNET-DRAFT Atomic Certificates Sep 1998
validity Validity,
subject NoName, -- note
subjectPublicKeyInfo SubjectPublicKeyInfo,
extension [3] EXPLICIT Extensions -- note
}
Version3 ::= INTEGER {2} -- note
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
NotBeforeTime Time
NotAfterTime Time }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
NoName ::=SEQUENCE{}
subjectPublicKeyInfo ::= SEQUENCE{
algorithm AlgorithmIdentifier
subjectPublicKey BitString }
Extensions ::= SEQUENCE SIZE(1) OF EXTENSION -- note
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN TRUE -- note
extnValue OCTET STRING }
PackagingCertificate ::= SEQUENCE{
tbsCertsPackage TBSCertsPackage,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
TBSCertsPackage ::= SEQUENCE {
version [0] EXPLICIT Version -- note
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer NoName,
validity Validity,
subject NoName, -- note
subjectPublicKeyInfo SubjectPublicKeyInfo,
Narayan Raghu [Page 07]
INTERNET-DRAFT Atomic Certificates Sep 1998
extension [3] EXPLICIT Package -- note
}
Package ::= SEQUENCE{
number NumberExtension
SIZE (1..MAX) OF AttributeExtension
SIZE (1..MAX) OF ACertExtension
}
NumberExtension ::= SEQUENCE{
extnID NumberOfAttributesCertified,
critical IsCritical,
extnValue OCTET STRING } -- integer value
NumberOfAttributesCertified ::= OID
AttributeExtension ::= SEQUENCE{
extnID UnitAttribute,
critical IsCritical,
extnValue OCTET STRING } -- Attribute Name
UnitAttribute ::= OID
ACertExtension ::= SEQUENCE{
extnID AtomicCertificate,
critical IsCritical,
extnValue OCTET STRING } -- The Atomic Certificate
AtomicCertificate ::= OID
IsCritical ::= BOOLEAN (TRUE)
6. ADVANTAGES OF ATOMIC CERTIFICATES
6.1 Only the relevant attestations are exchanged, thus reducing the
transmission overhead. In the existing setup, a large record
consisting of both relevant and irrelevant information is retrieved
and transmitted. Further Atomic Certificates would keep information on
a need-to-know basis.
6.2 The applications are more scaleable on the client side - one can
easily add and delete Atomic Certificates to one's collection
at the client end, and send any combination of them as necessary to
Narayan Raghu [Page 08]
INTERNET-DRAFT Atomic Certificates Sep 1998
the other party. This by default permits the client to "hide"
certain fields of the certificate, in the sense that the client can
simply omit to send the information over. Also, this system
eliminates the need to manage multiple key-pairs.
6.3 The applications are more scaleable on the Server side - if the
server's policy changes, and a new attestation is required, or an
an existing attestation is to be dropped, the clients do not need to
be issued new certificates. Just the newly required attestation
can be made as an atomic certificate, and be integrated with the
system.
6.4 Servers can be configured to trust different CAs for different
Attributes - making trust attribute specific.
6.5 In several cases, more than one attribute about a person might be
required to be attested, and the same Certification Authority might
not be in a position to certify both these attributes. In such cases,
normal X.509v3 certificates fail miserably, and Packaged Atomic
Certificates are the only way out.
6.6 The concept of Atomic Certificates drastically reduce the number
of Certificates that need to be issued and maintained. If an entity
has "n" attributes that need to be attested, and if information is to
be kept on a need-to-know basis, the entity has to store one
certificate containing each of the possible combinations of these
attributes.
This number would be :
__
num_of_certs = \ { n!/(n-r)! r!}
/_
r=1 to n
= { n!/(1)! (n-1)!} + { n!/(2)! (n-2)!} + { n!/(3)! (n-3)!}
..... .. { n!/(n-1)! 1!}
In case of Atomic Certificates, the number would be "n" (plus,
ofcourse the self-signed packaging certificate that is generated
on the fly, and needn't be stored)
For a simple case of n = 3,
The number of Certificates that need to be issued and maintained
with the existing system = 7,
and the number with Atomic Certificates = 3.
Narayan Raghu [Page 09]
INTERNET-DRAFT Atomic Certificates Sep 1998
6.7 Related chunks of information can be stored in databases
registered with each other. This could help the growth of a setup
akin to the DNS. The databases could query each other and cache each
other's information to give the client the required information in the
most efficient manner. For instance, all the servers maintaining
attestations of "emailID" could query each other to get the
information to the client that queries any one of these servers.
Similar setup could be maintained for other "domains".
Given the rate at which the net is growing, it is not too difficult to
see that distributed systems like the DNS are proving to be better
bets than single, centralized servers.
7 COMPATIBILITY ISSUES
Since Atomic Certificates are mearly a different
implementation of the same standard, they can co-exist with the
Directory Certificates, and needn't replace them in toto.
Software that work with X.509 Certificate can be modified to use
Atomic Certificates along with the Directory Certificates.
Hence, implementing this will cause no disruption to the current
systems, but will open up several other possibilities that could
not have been possible with just the Directory Certificates. Further,
the crucial overlap time can be provided, when software's need to
implement both the old and the new standard for the sake of
compatibility.
8. Security Considerations
The entire document is about security
9. Author's Address:
Narayan Raghu
IBM Global Services India ltd.
3rd Floor, Golden Enclave
Airport Road, Bangalore
India 560 017
Email : r1naray@in.ibm.com
Narayan Raghu [Page 10]
INTERNET-DRAFT Atomic Certificates Sep 1998