Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Public-Key-Based Certification Infrastructure Framework for Asynchronous Transfer Mode

IP.com Disclosure Number: IPCOM000117415D
Original Publication Date: 1996-Feb-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 163K

Publishing Venue

IBM

Related People

Peyravian, M: AUTHOR [+3]

Abstract

Disclosed is a public-key-based certification infrastructure framework for ATM which addresses inter-domain certification and certificate revocation and allows organizations that wish to "isolate" themselves (and explicitly choose whom they want to communicate with) to do so.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 36% of the total text.

Public-Key-Based Certification Infrastructure Framework for Asynchronous
Transfer Mode

      Disclosed is a public-key-based certification infrastructure
framework for ATM which addresses inter-domain certification and
certificate revocation and allows organizations that wish to
"isolate" themselves (and explicitly choose whom they want to
communicate with) to do so.

      Asynchronous Transfer Mode (ATM) is a connection-oriented
communication technology which handles all the different kinds of
traffic (i.e., voice, data, video,...) in an integrated way.  A key
concept of AM is that all information (i.e., voice, data, video,...)
is transported through the network in very short blocks called cells.
Each ATM cell consists of a 48-byte data payload and a 5-byte header.
ATM connections are either pre-established (i.e., semi-permanent) or
established on demand dynamically as connection requests arrive.

      In a public key cryptosystem, each node (i.e., an ATM switch
or endpoint) X has a unique and personal key-pair:  one of which is
publicly known (Xp, X's "public key"), and the other known only by X
(Xs, X's "private"  or "secret"  key).  Xp is used to encrypt data
meant to be only read by X; X can decrypt the result using it's
private key.  In a public key signature scheme, X uses Xs to create a
digital signature, which can be verified by any node using Xp but
which is computationally infeasible to create without the knowledge
of Xs.  The actual algorithm used can be a regular public key
en/decryption algorithm (e.g., RSA) or a public key signature
algorithm that cannot be used for encryption (e.g., DSS).

      In order for a node A to send secret information to B (or,
alternatively, in order for A to be able to verify a signature
produced by B), A needs to obtain B's public key (whether from it's
own private database, a cache, a centralized database, or directly
from B).  Though Bp is public by definition, it should not be
possible for any party X to substitute another value (e.g., Xp) for
Bp (either in a database or in a message to A).  To prevent this kind
of attack, public keys are being stored and distributed in the form
of "certificates."  A certificate contains the node's name, it's
public key, and some additional information (such as the key
lifetime) and is signed by a trusted party, a Certification Authority
(CA).  This signature unforgeably binds the public key to the subject
node.  Any node with access to the CA's public key (CAp) can verify
the genuineness of the certificate (by checking the CA's signature in
the certificate) and recover the public key which was certified.
Once signed, certificates can be stored anywhere (e.g., in
databases).  Since they are unforgeable, they can be transmitted via
non-secure message exchanges.

      An "implicit"  way of certificate revocation is by expiration
(i.e., each certificate includes a validity lifetime).  However, it
might be the case that a node'...