Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
812ea2fa66 |
+12
-10
@@ -174,16 +174,18 @@ also refuses a manifest whose `signingPubKey` holds a DSA key or subkey, or any
|
||||
secret key or subkey, since checking the self-signatures of a DSA key or the
|
||||
numbers of a secret key can take hours when those numbers are very large.
|
||||
|
||||
A signature is good only if the key that made it was valid at the signature's
|
||||
creation time. The primary key is judged by the newest self-signature on its
|
||||
primary user ID, and a subkey by its newest binding signature. By the
|
||||
signature's creation time the primary key and that self-signature must have been
|
||||
made and neither may have expired, and when a subkey made the signature the same
|
||||
holds of the subkey and its binding signature. A signature made before that
|
||||
self-signature or binding signature is not good, even if an older one made the
|
||||
key valid at that time. A key that has expired since does not make the signature
|
||||
bad, because a manifest outlives its key. A signature past its own expiry time
|
||||
is not good, whether or not the key has expired too.
|
||||
A signature is good only if the primary key, and the subkey that made the
|
||||
signature, were valid at the signature's creation time under the key validity
|
||||
rules of RFC 9580. The key is judged by its current self-signatures and binding
|
||||
signatures: for a version 4 key the newest self-signature on its primary user
|
||||
ID, for a version 6 key its newest direct-key signature, and for a subkey its
|
||||
newest binding signature with the signature embedded in it. So a signature made
|
||||
before the newest of those is not good, even if an older one made the key valid
|
||||
at that time. The reference implementation checks this by verifying the
|
||||
signature a second time with its clock set to the signature's creation time. A
|
||||
key that has expired since does not make the signature bad, because a manifest
|
||||
outlives its key. A signature past its own expiry time is not good, whether or
|
||||
not the key has expired too.
|
||||
|
||||
## Deterministic Serialization
|
||||
|
||||
|
||||
+9
-8
@@ -284,14 +284,15 @@ func verifySignature(data, signature, pubKey []byte) (string, error) {
|
||||
return "", fmt.Errorf("verify signature: %w", err)
|
||||
}
|
||||
|
||||
// The library checks whether the key is valid at the time its config
|
||||
// gives, which above is now. Verifying again as of the signature's
|
||||
// creation time refuses a signature made before the key or subkey that
|
||||
// made it was made, after it expired, or after its self-signature or
|
||||
// binding signature expired. The library judges the primary key by the
|
||||
// newest self-signature on its primary user ID and a subkey by its
|
||||
// newest binding signature, so this also refuses a signature made
|
||||
// before either of those, even if an older one was valid then.
|
||||
// The check above judges the key as of now. Checking the signature a
|
||||
// second time with the library's clock set to its creation time
|
||||
// requires the primary key, and the subkey that made the signature, to
|
||||
// have been valid then under the key validity rules of RFC 9580. The
|
||||
// key is judged by its current self-signatures and binding signatures:
|
||||
// for a version 4 key the newest self-signature on its primary user
|
||||
// ID, for a version 6 key its newest direct-key signature, and for a
|
||||
// subkey its newest binding signature with the signature embedded in
|
||||
// it. So a signature made before the newest of those is refused.
|
||||
signedAt := &packet.Config{
|
||||
Time: func() time.Time { return sig.CreationTime },
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user