Check S/MIME signatures, and remember who signed

A signed message now says whether that holds up, as it is read. This is
verification only: nothing here signs, encrypts or decrypts, and the
private-key question that blocks those is untouched. Verifying needed
none of it, because the certificate travels inside the message -- which
is why this is the half that could be built.

What it checks. For multipart/signed carrying PKCS#7, the exact bytes of
the signed part -- headers included, canonicalised to CRLF -- are hashed
against the messageDigest attribute, and the signature over the signed
attributes is verified with WebCrypto against the certificate inside the
message. RSA PKCS#1 v1.5 and ECDSA over P-256/384/521, with SHA-256, 384
or 512.

The trust model is the design, and it is deliberately small. A browser
has no system trust store, and the certificate arrives inside the
message, so anyone can self-sign as anyone: on its own a good signature
shows only that the sender held the key they attached. So the word
"verified" is never rendered, and the reassuring case is not the loud
one. What carries the weight is remembering -- the first signed message
from an address pins its fingerprint, later ones are compared, and a
signer that changed is reported with both names and told to check by
another route. Trust on first use, no certificate authority anywhere.

The pins live in the account's settings rather than the browser: one
that only a single device knew would greet the same correspondent as new
everywhere else, which is how people are trained to click past the one
warning that matters. A pin records the message that created it, so the
message that established a signer keeps saying so instead of appearing
to be corroborated by itself -- without that, the very first signed
message anybody receives reads as "the same signer as before", where
before is itself. A changed, mismatched or expired signer is never
pinned, since writing the anomaly into the baseline makes every later
message agree with it.

Three things are declined rather than attempted, and all three say
"could not check" rather than "does not check out", because ignorance
and an accusation are different claims:

  - OpenPGP, by name. The signature carries no key and there is nowhere
    to get the sender's: x:PublicKey is the account's OWN registry, and
    a keyserver or WKD lookup would tell a third party who you
    correspond with -- the leak the image proxy exists to close.
  - SHA-1. Not forgeable in practice today, still not something to put a
    tick beside.
  - RSA-PSS, whose salt length lives in parameters this does not read.
    Guessing wrong would report a good signature as bad.

Nothing validates a chain: no CA bundle is shipped and revocation is not
checked. "Issued by" reports what the certificate claims, and a
self-signed one claims itself.

The DER, CMS, X.509 and MIME readers are hand-written and deliberately
narrow -- no new dependency, and the whole verifier is a lazily imported
8.6 kB chunk that a reader of unsigned mail never downloads. The one
place this is easy to get quietly wrong has its own function and its own
test: signed attributes are signed as a SET OF, not as the [0] IMPLICIT
they arrive as, and hashing the message instead would make every
signature "pass".

Tested against real `openssl smime -sign` output rather than hand-built
fixtures -- RSA, ECDSA, a tampered copy, and a valid signature by a
certificate for somebody else -- because a signed message written by
hand only agrees with whatever its author believed the format to be.
Also driven in a browser against the mock, which now serves three real
signed messages so every branch of the banner is reachable.

Translations: 34 new strings in all nine catalogues, 306 entries.
Falling back to English is unchanged at 24 per language.

web/src/styles/app.css

@@ -1781,6 +1781,20 @@ button.dp-open:disabled { cursor: default; opacity: .5; }
 
 /* The banner naming a sender from outside the organisation. */
 .remote-banner.external-banner { background: var(--warn-soft); border-color: var(--warn); }
+/*
+ * The signature banner's colour is the claim it is making, so the quiet tones
+ * are deliberate. "Signed by somebody new" is grey, because an unknown
+ * certificate that verifies against itself has established nothing worth a
+ * green tick; green is kept for the one case that earned it, a signer matching
+ * what was pinned the first time. Red is for a signer that changed.
+ */
+.remote-banner.signature-banner { align-items: flex-start; }
+.remote-banner.signature-banner.good { background: var(--success-soft); color: var(--success); }
+.remote-banner.signature-banner.warn { background: var(--warn-soft); color: var(--warn); }
+.remote-banner.signature-banner.danger { background: var(--danger-soft); color: var(--danger); }
+.remote-banner.signature-banner.quiet { background: var(--bg-sunken); color: var(--fg-muted); }
+.remote-banner.signature-banner .sessions-table td { padding: 2px 8px 2px 0; }
+.remote-banner.signature-banner .hint { opacity: .8; }
 
 /* The line offering the whole folder once the page is selected. */
 .list-hint.select-all-hint { background: var(--accent-soft); color: var(--accent-soft-fg); }