-----BEGIN PGP SIGNED MESSAGE-----
In
<3(_dot_)0(_dot_)5(_dot_)32(_dot_)19970925170557(_dot_)009ce100(_at_)mail(_dot_)pgp(_dot_)com>,
on 09/25/97
at 07:05 PM, Jon Callas <jon(_at_)pgp(_dot_)com> said:
At 11:05 PM 9/24/97 -0700, Patrick Richard wrote:
The major problem with 'key-principal' architectures is the
revocation problem.
When my key is revoked/changed/upgraded/whathaveyou all bindings
are lost.
I think the revocation problem is the major problem with *all*
architectures.
If you develop a system that goes around this, then the key is
not the principal...
I disagree. One of the things that I want to see in PGP is an
"I-used-to-be" certificate. With proper setup of one of those, you have a
key-as-principal system, but delegation of authority with transfer of
authority, it all flows.
Hi Jon,
I am not quit sure that I like this idea of "I-used-to-be" certificate.
If I sign John Doe's userID JD(_at_)domain(_dot_)com and he changes his userID
to
Bill_Clinton(_at_)whitehouse(_dot_)gov do I really want my signature transfered
to
this new ID?
Perhaps a better approach would be to have a signature block that just
signed the key but not any of the userID's. This in conjunction with the
UserID signatures would provide you with the best of both worlds:
[KeyBlock]
[Signature]
[Signature]
[Signature]
[UserID]
[Signature]
[Signature]
[Signature]
[UserID]
[Signature]
[Signature]
[Signature]
The signatures on the keyblock could be used for key-as-principle based
system for providing key authority while signatures on the userID's would
be used are they are now as certification of "who" the key belongs to.
Hmmmm the more I think about this I see a way this could be implemented
without modifying the curent key structure by just using a blank userID
:). Signatures on a blankID could be used to provide authority and would not be
affected by changes to other userID's. This need not be a "blank" userID but
any standarized userID for the system it was intended to be used with.
As an example take an SSH aplication that makes use of PGP keys:
- -- The SSH app would use userID "SSH" as the Authorization userID.
- -- The SSHd would only accept public keys with the above userID that had
been signed with the servers private authorization key.
By using this approach several issues are addressed:
- -- The type/level of authorization can be determined by the contents of
the userID:
-- userID "SSH" could be used to give home access while "SSH ROOT"
could be used to give root access.
-- colision between multiple application using the same userID is not
a problem as the current key structure supports mulitple signatures per
keyID.
-- [KeyBlock]
[UserID]
[Sig]
[Sig]
[UserID] "SSH"
[Sig] "SSHd Sig domain1.com"
[Sig] "SSHd Sig domain2.com"
[UserID] "SSH ROOT"
[Sig] "SSHd Sig domain3.com"
-- Provides the greatest flexability as the same key can be used with
numerious aplications.
Of cource their is the question of wether a user would want to use one key
for all aplications. While it would provide the ease of having only one
key to manage it presents several issuse such as increase of keysize and
exposure of sensitive data (user is running SSH, SHTML, ...). These are
relativly minor issues that can be addressed by using multiple keys.
As far as revoked keys or "upgraded" keys I really see no easy solution.
Once the key itself (not userID's) changes one really needs to go through
the authorization process again.
- --
- ---------------------------------------------------------------
William H. Geiger III http://www.amaranth.com/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
- ---------------------------------------------------------------1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNCw+Oo9Co1n+aLhhAQHMlgQAx+maClpKyKAHu4DhVf12hZWZiyK7sOa6
K/dpsefkhqNPJrHV9EN3MKv0HT2b7oft7SbXgUfpCqnhu3es8vlPBZ3hwvKdgnfH
+MVIU9M+e1SO1yWLc9CNFGiGV1nf7tLsvq8gu4MTV0XAMqLVRGglUXmAlUKMoaxe
j9jlsQ38J7g=
=mz7B
-----END PGP SIGNATURE-----