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
Vinnie Moscaritolo <vinnie(_at_)pgp(_dot_)com>
Chief Consulting Engineer
Total Network Security 555 Twin Dolphin Drive
Network Associates, Inc. Suite 570
415.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