hierarchical keys?

[Andreas Bergen]

Hi,

> "Masterkeys" sollen die vollkommene Kontrolle über Slave Keys haben?
> Sowas gibt es generell nicht. 

There ist such a thing in real life. It's sort of a "Schließanlage" (don't 
know the English word), which everybody knows from big buildings. There's a 
master key to lock every door but often there's many differen sub-keys which 
open only selected doors. And it's the owner (master) of the building who 
distributes the keys to those he trusts.

> Bei einigen (kommerziellen?) PGP
> Versionen gibt es einen optionalen "ADK". D.h. ein "Masterschlüssel"
> kann Nachrichten dechiffrieren, die mit einem Schlüssel verschlüsselt
> wurden, der einen ADK enthält ("addtional irgendwas key").

> > When I encrypt a file using the keys Di, the encrypted
> > file can be decrypted using only Di (and not Dj with i != j) or M.
>
> Das ist das Standartverhalten unter PGP und GnuPG.

With the exception of decryption by M.

>
> > M can be configured to allow or disallow certain Di to sign in M's
> > name without giving away the secret part of M.
>
> Das ist technisch gar nicht möglich. Wenn in M's Namen signiert werden
> soll, dann muss dafür auch M's privater Schlüssel dafür benutzt werden.

But that's exactly what I don't want. All those keys belong to M, that is M is 
the real owner of these keys. They're just delegated keys (therefore "D"). M 
gives out these keys to certain people to do things (sign / encrypt) in M's 
name. But still they remain M's keys. And M should retain the full control 
over these D-keys.

In German law there's something similar which is called "Prokura" (http://
de.wikipedia.org/wiki/Prokura), which allows to the so called "Prokurist" to 
sign and act in the name of the owner of the company. He doesn't do it by 
forged signatures of the owner (which in a way would be similar to signing 
with M's key). In fact the only thing that happens is that his signature gets 
officially registered as a Prokura-signature. (ppa) Everybody can see using 
the signature that it's the Prokurist signing and not the owner himself but 
everybody can verify that he's authorized to do so.

What is important: A Prokura can be revoked at any time! (This can't be done 
if M gives away his private key(phrase)).


> > That is, if someone
> > gets a message, signed by Di the signature can be verified using the
> > public part of M (or Di).
>
> Hm, dafür könnte man einen Workaround machen. Frag mal Adrian von Bidder
> in der Liste, der kennt sich mit der Subkeythematik aus. Ich stelle mir
> das so vor: Di enthält einen Unterschlüssel zum Signieren. Dieser
> Unterschlüssel wird exportiert und in M eingesetzt. Wenn Di dann mit
> dem Unterschlüssel "Di,u" signiert, kann M verifizieren, dann in M's
> Schlüssel "Di,u" aufgenommen wurde.

But not only M should be able to verify this, but everyone having the public 
key of M. Di should be in a way "prokura-signed", which means that not only M 
certifies the identity of Di but is by the "Prokura-signature" bound to the 
signatures of Di. Additionally M can always decrypt everything the person 
using the Di keys encrypts (that is encrypts in the name of M).

Another advantage would be that everyone signing in the name of M can be 
identified which is impossible if the secret key of M is distributed to 
several people.

>
> > Using M I can create revocation certificates for all Di.
>
> Ohne Einverständnis von Di kann niemand dessen Schlüssel widerrufen. Das
> würde ja das PGP-Schema komplett aushebeln! 

Not if it's clear that Di basically is M's key which is given to a person to 
do things in M's name. This warrant (Vollmacht) must always be revokable.

> Wie sollte ich einem
> Schlüssel vertrauen, der jederzeit von einem Dritten widerrufen werden
> kann? Darum erstellt man direkt nach dem Erzeugen von Di ein
> Widerrufszertifikat und sichert es an einem sicheren Ort, muss Di
> wiederrufen werden, benutzt man dieses Widerrufszertifikat. M kann aber
> tatsächlich im Namen von Di den Schlüssel Di widerrufen ("designated
> revoker"), das geht aber nur mit Di's Einverständnis! D.h. ohne
> Passphrase kann Di's Schlüssel niemals widerrufen werden, von
> niemandem.

As said before: Di firstly belongs to M and it expresses only that the owner 
of Di is authorized to do things in M's name.

>
> > This can be used for example for signing publicly available software,
> > where the signing-process can be delegated without giving away the
> > master signing key.
>
> Das mit dem Masterkey ist imho eine unnötige Verkomplizierung. Für die
> Zertifizierung machst du einfach einen separaten Key, denn alle
> bekommen, die Software zertifizieren müssen. Entweder du vertraust
> ihnen und gibst ihnen diesen Schlüssel, oder eben nicht, daran ändert
> auch kein Masterkey etwas. 

As probably everyone has already experienced, trust can change. What once was 
a loyal worker in the company can through certain circumstances become a 
bitter enemy. In order to retain the control over his signatures it's not so 
good to give away the master-private key as this can't be got back. And this 
enables this person to continue signing in the name of the owner as long as 
this owner's key isn't revoked. And both revocation of this key as well as 
illegitimate signing can be very harmfull to the owner.

> Du kannst es aber so machen: einen
> Hauptsignaturschlüssel, über den nur du verfpgst. Dieser Key "s0"
> signiert dann den Softwaresignaturschlüssel softsig0 den deine
> Angestellten bekommen und mit softsig0 signieren sie dann Software.
> Theoretisch könnten sie einen neuen Softwaresignaturschlüssel erzeugen,
> oder softsig0 sogar widerrufen - sie haben ja die Passphrase zum
> Signieren mit diesem Schlüssel! - aber sie haben eben nicht den
> Hauptsignaturschlüssel s0 mit dem softsig0 signiert ist.

In the above mentioned case this won't help. If the user of the softsig0-key 
wants to misuse this key the owner of the master key has no way to stop him 
exept from revoking the whole softsig0-key which is not very desireable.

>
> > Or it can be used for people / organizations to
> > have a backup master key to be able to decrypt files with where the
> > decryption-key / passphrase has been lost.
>
> Wie gesagt, Stichwort "ADK", mit GnuPG wird es aber niemals einen ADK
> geben. Du kannst dir aber anders helfen: du kannst in GnuPG sehr wohl
> einstellen, dass immer zusätzlich an einen weiteren dritten Schlüssel
> chiffriert wird, dann kannst du die Nachricht auch mit diesem
> entschlüsseln. Aber: dieses zusätzliche Verschlüsseln wird in der
> Konfigurationsdatei festgelegt und kann jederzeit vom Benutzer wieder
> entfernt werden, kann also nicht gegen den Willen des Benutzers
> erzwungen werden.
>
> Gruß
> Malte

Hope this clarifies my intention.

Thanks for any comment.
Yours
  Andreas Bergen

-- 
Andreas Bergen
PGP/GnuPG-encrypted / -signed Email welcome. PGP-key-ID: 8CDEC18F
Gott ist Liebe, und wer in der Liebe bleibt, bleibt in Gott und Gott in ihm.