From RFC 4880 [1]:
There are a number of possible meanings for a signature, which are
indicated in a signature type octet in any given signature. Please
note that the vagueness of these meanings is not a flaw, but a
feature of the system. Because OpenPGP places final authority for
validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other
authority's positive act. See Section 5.2.4, "Computing
Signatures", for detailed information on how to compute and verify
signatures of each type.
These meanings are as follows:
0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it
has not been modified.
0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the text
data with its line endings converted to <CR><LF>.
0x02: Standalone signature.
This signature is a signature of only its own subpacket contents.
It is calculated identically to a signature over a zero-length
binary document. Note that it doesn't make sense to have a V3
standalone signature.
0x10: Generic certification of a User ID and Public-Key packet.
The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the owner
of the key is in fact the person described by the User ID.
0x11: Persona certification of a User ID and Public-Key packet.
The issuer of this certification has not done any verification of
the claim that the owner of this key is the User ID specified.
0x12: Casual certification of a User ID and Public-Key packet.
The issuer of this certification has done some casual verification
of the claim of identity.
0x13: Positive certification of a User ID and Public-Key packet.
The issuer of this certification has done substantial verification
of the claim of identity.
Most OpenPGP implementations make their "key signatures" as 0x10
certifications. Some implementations can issue 0x11-0x13
certifications, but few differentiate between the types.
0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key that
indicates that it owns the subkey. This signature is calculated
directly on the primary key and subkey, and not on any User ID or
other packets. A signature that binds a signing subkey MUST have
an Embedded Signature subpacket in this binding signature that
contains a 0x19 signature made by the signing subkey on the
primary key and subkey.
0x19: Primary Key Binding Signature
This signature is a statement by a signing subkey, indicating that
it is owned by the primary key [2]. This signature is calculated
the same way as a 0x18 signature: directly on the primary key and
subkey, and not on any User ID or other packets.
0x1F: Signature directly on a key
This signature is calculated directly on a key. It binds the
information in the Signature subpackets to the key, and is
appropriate to be used for subpackets that provide information
about the key, such as the Revocation Key subpacket. It is also
appropriate for statements that non-self certifiers want to make
about the key itself, rather than the binding between a key and a
name.
0x20: Key revocation signature
The signature is calculated directly on the key being revoked. A
revoked key is not to be used. Only revocation signatures by the
key being revoked, or by an authorized revocation key, should be
considered valid revocation signatures.
0x28: Subkey revocation signature
The signature is calculated directly on the subkey being revoked.
A revoked subkey is not to be used. Only revocation signatures by
the top-level signature key that is bound to this subkey, or by an
authorized revocation key, should be considered valid revocation
signatures.
0x30: Certification revocation signature
This signature revokes an earlier User ID certification signature
(signature class 0x10 through 0x13) or direct-key signature
(0x1F). It should be issued by the same key that issued the
revoked signature or an authorized revocation key. The signature
is computed over the same data as the certificate that it revokes,
and should have a later creation date than that certificate.
0x40: Timestamp signature.
This signature is only meaningful for the timestamp contained in
it.
0x50: Third-Party Confirmation signature.
This signature is a signature over some other OpenPGP Signature
packet(s). It is analogous to a notary seal on the signed data.
A third-party signature SHOULD include Signature Target
subpacket(s) to give easy identification. Note that we really do
mean SHOULD. There are plausible uses for this (such as a blind
party that only sees the signature, not the key or source
document) that cannot include a target subpacket.
[1]: http://tools.ietf.org/search/rfc4880#section-5.2.1
[2]: http://www.rfc-editor.org/errata_search.php?rfc=4880
Errata ID: 2208
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 5.2.1. says:
This signature is a statement by a signing subkey, indicating
that it is owned by the primary key and subkey.
It should say:
This signature is a statement by a signing subkey, indicating
that it is owned by the primary key.
Notes:
The subkey does not own itself.
110: 'private',
}
+ _signature_types = {
+ 0x00: 'binary document',
+ 0x01: 'canonical text document',
+ 0x02: 'standalone',
+ 0x10: 'generic user id and public-key packet',
+ 0x11: 'persona user id and public-key packet',
+ 0x12: 'casual user id and public-key packet',
+ 0x13: 'postitive user id and public-key packet',
+ 0x18: 'subkey binding',
+ 0x19: 'primary key binding',
+ 0x1F: 'direct key',
+ 0x20: 'key revocation',
+ 0x28: 'subkey revocation',
+ 0x30: 'certification revocation',
+ 0x40: 'timestamp',
+ 0x50: 'third-party confirmation',
+ }
+
_clean_type_regex = _re.compile('\W+')
def _clean_type(self):
projects / gpg-migrate.git / commitdiff