Class OpenPGPCertificate.OpenPGPSignatureChain

java.lang.Object
org.bouncycastle.openpgp.api.OpenPGPCertificate.OpenPGPSignatureChain
All Implemented Interfaces:
Comparable<OpenPGPCertificate.OpenPGPSignatureChain>, Iterable<OpenPGPCertificate.OpenPGPSignatureChain.Link>
Enclosing class:
OpenPGPCertificate
public static class OpenPGPCertificate.OpenPGPSignatureChain extends Object implements Comparable<OpenPGPCertificate.OpenPGPSignatureChain>, Iterable<OpenPGPCertificate.OpenPGPSignatureChain.Link>
Chain of signatures. Such a chain originates from a certificates primary key and points towards some certificate component that is bound to a certificate. As for example a subkey can only be bound by a primary key that holds either at least one direct-key self-signature or at least one user-id binding signature, multiple signatures may form a validity chain. Another example is a third-party certification over a user-id or certificates primary key. Here, the chain originates from the certifiers primary key and ends at the user-id or primary key of the signee. An OpenPGPCertificate.OpenPGPSignatureChain can either be a certification (isCertification()), e.g. it represents a positive binding, or it can be a revocation (isRevocation()) which invalidates a positive binding.

Example: 

                          v-----------\
          [PRIMARY KEY 0xAAAA]         \
           /         \       \         |
          /           \       \__(DIRECT KEY SIG #0)
  (USERID BINDING #1) |
         |    (SUBKEY BINDING #2)
         v           |
 [USERID Alice]      v
                 [SUBKEY 0xAABB]
Here, the certificates components are bound like follows:
  • Primary Key 0xAAAA: [0xAAAA->#0->0xAAAA]
  • UserID Alice: [0xAAAA->#0->#1->Alice]
  • Subkey 0xAABB: [0xAAAA->#0->#2->0xAABB]
Note: If the certificate does not carry a direct-key self-signature, the primary user-id binding would be used as root link in its place. A binding can also be a revocation. In such case, the whole chain represents a revocation.

In Web-of-Trust scenarios, signature chains can span multiple certificates.

Example: 

                              ________________
                             v               |
              [PRIMARY KEY 0xAAAA]---(DIRECT KEY SIG #0)
              /         |     \
 (USERID BINDING #1)    |      \
       |                |  (DELEGATION #2)-->[PRIMARY KEY 0xBBBB]
       |                \                            |
       v                 \                  (USERID BINDING #3)
[USERID Alice]      (CERTIFICATION #4)               |
                            \                        v
                             \________________>[USERID Bob]
Here, Alice delegated trust to Bob by issuing a direct key delegation signature (#0) over Bobs primary key, as well as a 3rd-party certification signature for UserID Bob. Now there are the following paths of trust from Alice's certificate down to Bobs certificate:
  • Bobs Certificate (primary key 0xBBBB): [0xAAAA->#0->#2->0xBBBB
  • Bobs UserID Bob: [0xAAAA->#0->#4->Bob
Note, that certificate 0xAAAA holds signatures #0,#1, while certificate 0xBBBB holds signatures #2,#3,#4.