Index: doc/DETAILS =================================================================== --- doc/DETAILS +++ doc/DETAILS @@ -39,7 +39,7 @@ tru = trust database information spk = signature subpacket - 2. Field: A letter describing the calculated trust. This is a single + 2. Field: A letter describing the calculated validity. This is a single letter, but be prepared that additional information may follow in some future versions. (not used for secret keys) o = Unknown (this key is new to the system) @@ -48,18 +48,23 @@ (deprecated - use the 'D' in field 12 instead) r = The key has been revoked e = The key has expired - - = Unknown trust (i.e. no value assigned) - q = Undefined trust + - = Unknown validity (i.e. no value assigned) + q = Undefined validity '-' and 'q' may safely be treated as the same value for most purposes - n = Don't trust this key at all - m = There is marginal trust in this key - f = The key is fully trusted - u = The key is ultimately trusted. This often means + n = This key or User ID is not valid + m = For UID or UAT: marginal calculated validity (the User + ID is marginally bound to the key). For a key: At + least one User ID on this key has marginal validity, + and none have full or ultimate. + f = For UID or UAT: full calculated validity (the User ID + is fully bound to the key). For a key: at least one + User ID on this key has full validity. + u = The key is ultimately valid. This often means that the secret key is available, but any key may - be marked as ultimately trusted. + be marked as ultimately valid. - For X.509 certificates an 'u' is used for a trusted root + For X.509 certificates a 'u' is used for a trusted root certificate (i.e. for the trust anchor) and an 'f' for all other valid certificates. @@ -77,8 +82,8 @@ self-signature date. Note that the date is usally printed in seconds since epoch, however, we are migrating to an ISO 8601 format (e.g. "19660205T091500"). This is currently - only relevant for X.509, A simple way to detect the format - is be scannning for the 'T'. + only relevant for X.509, A simple way to detect the new format + is to scan for the 'T'. 7. Field: Key or user ID/user attribute expiration date or empty if none. @@ -103,13 +108,15 @@ An FPR record stores the fingerprint here. The fingerprint of an revocation key is stored here. -11. Field: Signature class. This is a 2 digit hexnumber followed by - either the letter 'x' for an exportable signature or the - letter 'l' for a local-only signature. +11. Field: Signature class. (http://tools.ietf.org/html/rfc4880#page-20) + This is a 2 digit hexnumber followed by either the letter 'x' + for an exportable signature or the letter 'l' for a + local-only signature. The class byte of an revocation key is also given here, - 'x' and 'l' ist used the same way. + 'x' and 'l' is used the same way. 12. Field: Key capabilities: + (http://tools.ietf.org/html/rfc4880#section-5.2.3.21) e = encrypt s = sign c = certify @@ -128,7 +135,7 @@ this is the same string as the fingerprint. The advantage of using this value is that it is guaranteed to have been been build by the same lookup algorithm as gpgsm uses. - For "uid" recods this lists the preferences n the sameway the + For "uid" records this lists the preferences n the sameway the -edit menu does. For "sig" records, this is the fingerprint of the key that issued the signature. Note that this is only filled in if @@ -177,9 +184,18 @@ 4: Date trustdb was created in seconds since 1/1/1970. 5: Date trustdb will expire in seconds since 1/1/1970. + 6: Number of signatures from keys with marginal ownertrust needed to + calculate full validity. + + 7: Number of signatures from keys with full ownertrust needed to + calculate full validity. + + 8: max_cert_depth how deeply can certificates be chained (?) + + The "spk" signature subpacket records have the fields: - 2: Subpacket number as per RFC-2440 and later. + 2: Subpacket number as per RFC-4880 and later. 3: Flags in hex. Currently the only two bits assigned are 1, to indicate that the subpacket came from the hashed part of the signature, and 2, to indicate the subpacket was marked critical. @@ -320,16 +336,19 @@ TRUST_FULLY [0 []] TRUST_ULTIMATE [0 []] For good signatures one of these status lines are emitted to - indicate how trustworthy the signature is. The error token - values are currently only emitted by gpgsm. VALIDATION_MODEL - describes the algorithm used to check the validity of the key. - The defaults are the standard Web of Trust model for gpg and the - the standard X.509 model for gpgsm. The defined values are + indicate how strongly the signing key is bound to its User ID. The + error token values are currently only emitted by gpgsm. + VALIDATION_MODEL describes the algorithm used to check the validity + of the key. The defaults are the standard Web of Trust model for + gpg and the the standard X.509 model for gpgsm. The defined values + are "pgp" for the standard PGP WoT. "shell" for the standard X.509 model. "chain" for the chain model. + This might have been better called "VALIDITY_*", but we will not + change the name of the messages. PKA_TRUST_GOOD PKA_TRUST_BAD @@ -535,7 +554,7 @@ NOTATION_NAME NOTATION_DATA - name and string are %XX escaped; the data may be splitted + name and string are %XX escaped; the data may be split among several notation_data lines. USERID_HINT @@ -660,7 +679,7 @@ --status-fd as part of the required information is carried on the ATTRIBUTE status tag (see above). -The contents of the attribute data is specified by 2440bis, but for +The contents of the attribute data is specified by RFC 4880, but for convenience, here is the Photo ID format, as it is currently the only attribute defined: @@ -693,25 +712,25 @@ pubkey: the third field contains the public key algorithmdcaiphers this version of GnuPG supports, separated by semicolons. The - algorithm numbers are as specified in RFC-2440. + algorithm numbers are as specified in RFC-4880. cfg:pubkey:1;2;3;16;17 cipher: the third field contains the symmetric ciphers this version of GnuPG supports, separated by semicolons. The cipher numbers - are as specified in RFC-2440. + are as specified in RFC-4880. cfg:cipher:2;3;4;7;8;9;10 digest: the third field contains the digest (hash) algorithms this version of GnuPG supports, separated by semicolons. The - digest numbers are as specified in RFC-2440. + digest numbers are as specified in RFC-4880. cfg:digest:1;2;3;8;9;10 compress: the third field contains the compression algorithms this version of GnuPG supports, separated by semicolons. The - algorithm numbers are as specified in RFC-2440. + algorithm numbers are as specified in RFC-4880. cfg:compress:0;1;2;3 @@ -1192,7 +1211,7 @@ This mode can be used to perform multiple operations with one call to gpg. It comes handy in cases where you have to verify a lot of signatures. Currently we support only detached signatures. This mode -is a kludge to avoid running gpg n daemon mode and using Unix Domain +is a kludge to avoid running gpg in daemon mode and using Unix Domain Sockets to pass the data to it. There is no easy portable way to do this under Windows, so we use plain old pipes which do work well under Windows. Because there is no way to signal multiple EOFs in a pipe we