[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SPKI in OpenPGP format

I am going to try to answer a number of comments from Carl an Bill here.

let me summerize my question, I belive that a  SPKI cert can be represented
by using an OpenPGP standalone sig with the follwoing form:

VALIDITY - represented by the signature creation/expiration fields
ISSUER   - represented by the Key ID field.
SUBJECT		- notation value/data pair (SPKI_SUBJ)
AUTHORIZATION	- notation value/data pair  (SPKI_AUTH)
DELEGATION 	- notation value/data pair  (SPKI_DELEG)

The notation  records are a type/value  structure that could contain a SPKI

It could be as simple as having a type 'SPKI' followed by an encapsulated
SPKI record  or as above I am  shifting the  Validity and Issuer fields  to
the standard standalone sig fields.

An  OpenPGP parser doesnt have to understand the notation data, it can just
check that the signature and validity dates work and pass up the notation
data to it's client for further processing.

But I am not asking to extend the the OpenPGP standard in any way, the
notation fields are already there and there is nothing  in the proposed
standard that enforces how a notation is used.

 This doesnt really break either of the standards, its just a way to
encapulate a SPKI statement into an OPenPGP form,

>	What features of SPKI do you believe PGP could benefit from?

I am trying to build a Public Key authorized User auth module for managing
file system access.

>	Can we translate from PGP to SPKI canonical format easily?

absolutely. and that might be the key here, there is nothing that prevents
the data from being translated from one form to another. The above form
simply lets allows the SPKI information to be carried in an openPGP packet.

One question though, judging from my responses I think I might have
misunderstood the Subject field. I was suggest that subject also be a
Notation value/data pair that contained the keyID or maybe
fingerprint/alg/keyID of the subject..

The current keyservers out there don't index on fingerprints, just keyIDs..
this is a problem that OpenPGP 2 needs to solve, they need to extend the
keyID to a long enough field that it canbe replaced with a fingerprint.

 I was using the key ID to do a lookup, then comparing the fingerprints and
algorithms to ensure I was using the right one. this might be more of an
implementation issue.

Vinnie Moscaritolo			    <vinnie@pgp.com>
Chief Consulting Engineer
Total Network Security                 	    555 Twin Dolphin Drive
Network Associates, Inc.                    Suite 570
650.572.0430	                            Redwood Shores, CA 94065
Fingerprints: DE60 DB68 8E17 2A3F 60AE A933 88F1 F50E 070A 5CFF (DSS)

1 if by land, 2 if by sea.
	 Paul Revere - encryption 1775