Five types of delegation, allowing Alice to delegate some of her authority to Bob.

• #1: Bob gives Alice his pubkey, Alice returns a signed certificate that imbues his privkey with authority
• #2: Alice creates a new keypair, signs a certificate for it, then gives certificate and privkey to Bob
• #3: same as #2, but Bob makes a second keypair, uses the privkey from Alice to sign a certificate for it, and only ever uses the second privkey
• #4: Bob gives Alice his pubkey, Alice puts it in her list of root certificates
• #5: Bob gives Alice his pubkey, Alice puts a MAC around it, returns the MACed pubkey, which she will accept later

Type-1 and type-5 require a bidirection exchange of messages. Type-2 and type-3 require a message from Alice to Bob, but not vice versa: this makes them useful for patterns that require Alice to delegate authority to a key that she doesn't know about yet (or which might not yet exist). Type-4 requires a message from Bob to Alice, but not vice-versa: useful for times when Bob wants to get authority from someone who he has not yet met.

Many of these delegation types give Bob the ability to delegate some or all of his new authority to others. Type-1 and type-4 use Bob's long-term pubkey, so any certificates he's signed with his privkey become good for Alice's authority too: Bob can pre-sign a delegation to Carol. Type-2 and type-3 do not have this property: Bob must wait until he's received the new key from Alice before he can subdelegate to someone else.

Type-3 is distinct from type-2 in that a server which records the full certificate chain used for any given operation will be able to distinguish between Bob using his delegated authority and Alice using the privkey that she created for Bob (and retained, perhaps without his knowledge). While Alice is the sole source of storage authority, type-2 allows Alice to impersonate Bob, whereas type-3 does not (but Alice has full control over which Bobs are allowed to use storage).

Type-5 is a reminder that pubkey operations are not the only way to go. The MAC is just as secure, but does not allow a separation between signature-making and signature-verification. This limits the ability to subdelegate authority.