Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Assume I have a universe of U users. Every user has his private key. I want to build user groups by adding a company sub key to his key set. Now users can sign his company sub key with there company sub keys.

Now the user resigns from the company. He is lazy and will not revoke his sub key right away, or he plays not fair, and will never revoke it. Ok, others could revoke their signatures after they have been notified that he left the company, but others may never revoke their signatures.

How can I assure that after he resigns, he will be dismissed from/denied access to the group?

Update: I found that PGP supports something called "Designated revoker". The definition for it is:

A designated revoker in OpenPGP is a partner key that we trust and that can be used to revoke our public key in the case when we have lost our own private key and cannot do the revocation ourselves.

Could that be a solution to my problem?

share|improve this question
2  
Your trust model inherits the worst from both hierarchical (X.509) and WoT worlds. You also rely on the user revoking her key after being fired. Not a nice assumption. Please think over the reasons you want to build a web of trust instead of a centralized hierarchical structure with a single CA. –  Deer Hunter Apr 30 '13 at 3:38
    
i want to join/leave circles. a company was just an example. circle can be created individually, so a ca is not a real option because then the CA has to know all circles or i need a CA for each circle. –  esskar Apr 30 '13 at 4:02
2  
Take a look at the multiple rooted hierarchies (chapter 4.1.2) in PKI trust models by Tim Moses(PDF). Other PKI trust models described therein might also be suitable to your use case, and if none suit your needs then the paper also delves into X.509 certificate syntax standard, certificate extensions, constraints... –  Noordung Apr 30 '13 at 5:01
    
@TildalWave: i added the section about "designated revoker". any thoughts on that? –  esskar Apr 30 '13 at 10:58
1  
Designated Revoker model seems to be suitable for your needs, based on what I understand from your question and the way I read it's documentation. But it's probably not a bad idea to create a workflow diagram of this model and test your use case against it. –  Noordung Apr 30 '13 at 14:37

1 Answer 1

up vote 3 down vote accepted

There are two generic points which must be made:

  • PKI is for authentication, not for authorization. "Certificates", be they X.509 or OpenPGP "key signing" (same concept, different format), are meant to bind identities to public keys; they convey the information "Bob's public key is X". Certificates don't work well to manage authorization-like information such as "Bob is allowed to sign in the name of Company Y".

    Revocation is the subject where this distinction is most easily seen. Revocation is asynchronous; it is not efficient as propagating changes quickly. If Bob is fired, you want to revoke his "signing rights" immediately, preferably five minutes before informing Bob himself that he is no longer welcome. You don't want to remove the rights some hours or days after the deed, because there is a lot of harm that a disgruntled Bob could do.

  • You cannot enforce forgetfulness. In cryptography, power is knowledge: you can sign or decrypt by virtue of knowing the corresponding private key. When a participant has this power, then he somehow "knows" the private key, if only potentially (e.g. the key is in his computer). If he chooses to remember the key forever, well, he can. You cannot make sure that he did not keep a backup somewhere.

    To remove signature power from a user, you must make his key obsolete. This means generating a new signature key, and giving it to all the remaining signers (excluding Bob).

Sharing signature keys is not recommended anyway. When a secret is known to more than two persons, it is no longer secret, only somewhat discreet. If you want to allow a group to perform signatures in the name of the group, a robust solution would take the form of a signed, dated, short-lived, authoritative list of "allowed signers". A document which says "On April 30th 2013, Alice, Charlie and Donald are allowed to sign in the name of Group Y"; the document is then signed by a group manager. Verifiers will check the signature on this document to see whether the signer is really part of the current list of allowed signers.

The "group manager" must be an entity who can decide who is part of the group, and who is not. This is inherently centralized, thus at odds with the decentralized model of the Web of Trust.

share|improve this answer
    
a make this the answer, because it is good and it is the only one. cheers and thanks. –  esskar May 12 '13 at 0:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.