[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                           Narayan Raghu
                                        IBM Global Services India ltd.
Expires in 6 months                                         Sept. 1998

                           ATOMIC CERTIFICATES

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).


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

  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.


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.


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.


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

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

This Memo sees Certificates as a collection of Attribute-Assertions,
which may or may not aid in identifying the entity that has been

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.


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.


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.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

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".


      -- 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.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

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

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.


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

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