[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PGPticket
>Date: Tue, 26 May 1998 16:19:55 -0800
>From: Vinnie Moscaritolo <vinnie@apple.com>
>Subject: PGPticket
>To: "ietf-open-pgp@imc.org" <ietf-open-pgp@imc.org>
>X-Priority: 3
>MIME-Version: 1.0
>Sender: owner-ietf-open-pgp@imc.org
>Precedence: bulk
>
>
>I am looking for someone to help me co-author the PGPticket Internet draft.
>PGPtickets are SPKI authentication certs represented as an OpenPGP
>standalone signature packets. This allows us to represent SPKI packets in
>a form that most PGP implemenations can process.
>
>The authetication certs are a powerful tool, and this might be a way to
>get the best of the SPKI into a form that PGP users can do something with.
>
>In order to test out this concept I have even built some code
>with the PGPsdk that I would lov eto make public, but would like to
>write up the message format as an ietf draft...
>
>being that I don't have much experience writting these documents, I
>am seeking (a) partner(s) who is intersted in helping out with the draft.
>
> PGPticket is a lightweight but very secure authorization protocol
> based on the OpenPGP Message Format and SPKI structure. PGPticket
> is designed to control access of services over a public network by
> granting and transfering user privileges through authorization
> certificates signed with strong public key cryptography.
>
>
> A PGPticket packet contains:
>
> - Packet Tag
>
> - One-octet version number (4).
> - One-octet Standalone signature type (2).
> - One-octet public key algorithm.
> - One-octet hash algorithm.
>
> - Two-octet scalar octet count for following hashed subpacket data.
>
> Certificate validity Information consisting of:
> - One-octet signature creation time subpacket type (82)
> - Four-octet time field
> - One-octet signature expiration time subpacket type (83)
> - Four-octet time field
>
> Certificate Issuer Information consisting of:
> - One-octet signature creation issuer key ID type (90)
> - Eight-octet key ID
>
> Certificate Authorization Information consisting of:
> - One-octet Notation Data subpacket type (94)
> - 4 octets of flags (0)
> - 2 octets of name length (4)
> - 2 octets of value length (N),
> - 4 octets of name data ('AUTH')
> - N octets of authorization string data
>
> Certificate Subject Information consisting of:
> - One-octet Notation Data subpacket type (94)
> - 4 octets of flags (0)
> - 2 octets of name length (4)
> - 2 octets of value length (N),
> - 4 octets of name data ('SUBJ')
> N octets of Subject string data for each subject
> authorized in this certifcate consisting of
> - Eight-octet key ID
> - One-octet public key algorithm.
> - One octet scaler length count for public Key fingerprint
> - N octets public Key fingerprint data
>
> Optional Certificate Delegation Information consisting of:
> - One-octet Notation Data subpacket type (20)
> - 4 octets of flags (0)
> - 2 octets of name length (4)
> - 2 octets of value length (0),
> - 4 octets of name data ('DELG')
>
> - Two-octet scalar octet count for following unhashed subpacket
> data.
>
> - Unhashed subpacket data. (zero or more subpackets)
>
> - Two-octet field holding left 16 bits of signed hash value.
>
> - One or more multi-precision integers comprising the signature.
>
>
>Below is a brief overview of the PGPticket Protocol
>
> 1. The user requests server access from the system admin
> (possibly a verbal request). The user either provides a copy
> of his public key or makes the key available on common
> key-server. The Admin verifies the validity of this key.
>
> 2. The administrator generates the PGPticket with
> appropriate authorizations and validity information, signing
> the ticket with the server admin key. The ticket is either
> posted in a public place or sent by email to the user.
>
> 3. The user retrieves the PGPticket and stores it in a local
> ticket database.
>
> Client to server
> 4. The user attempts to access a network service, the client
> searches its ticket database for any tickets pertaining to
> the server, and sends a copy of the tickets along with the
> access request.
>
> Server to Client
> 5. The server checks validity of ticket, which entails
> verifying the admin signature and expiration date of ticket.
> The server then generates a random challenge string and
> sends the challenge to the client requesting that it be
> signed by the key specified in the ticket.
>
> Client to server
> 6. The client signs and returns the challenge string with a
> random nonce appended. The server then checks the clients
> signature and if successful grants access with the
> authorizations specified in the ticket
>
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Vinnie Moscaritolo
>Wordwide Developer Technical Support
>N&C/Hardware
>
>Apple Computer, Inc. email: vinnie@apple.com
>3 Infinite Loop, MS: 303-2T phone: 408.974.5560
>Cupertino, CA 95014 fax: 408.862.7602
>Fingerprint: 0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
-------------------------------------------------------------------------
Bill Frantz | If hate must be my prison | Periwinkle -- Consulting
(408)356-8506 | lock, then love must be | 16345 Englewood Ave.
frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA
Follow-Ups: