Subject: [TLS] Key agility issue in draft-ietf-tls-subcerts?

From: "Patton,Christopher J" <[email-masked]>
Date: Fri, 6 Jul 2018 01:11:34 +0000

The string over which the delegation signature is computed contains the `SubjectPublicKeyInfo` of the DC public key. This in turn contains an `AlgorithmIdentifier`. Does an X.509 `AlgorithmIdentifier` determine a unique TLS `SignatureScheme`?

If not, this might lead to key agility issues, since the server could indicate a different signature algorithm (via the `signature_scheme` extension) than it uses to sign the handshake. I'm not sure if this leads to an attack, but it's a bit ugly. What we could do is replace the `SubjectPublicKeyInfo` with the DER-encoded public key and the SignatureScheme. This way the delegation signature binds to the DC to the signature_algorithm indicated by the server. This design would seem to be inline with the goal of having the simplest possible semantics for delegated credentials.

Comments are welcome. See also the issue on GitHub: https://github.com/tlswg/tls-subcerts/issues/4

Chris Patton

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 6 Jul 2018 08:34:09 +0300

On Fri, Jul 06, 2018 at 01:11:34AM +0000, Patton,Christopher J wrote:
> The string over which the delegation signature is computed contains
> the `SubjectPublicKeyInfo` of the DC public key. This in turn
> contains an `AlgorithmIdentifier`. Does an X.509 `AlgorithmIdentifier`
> determine a unique TLS `SignatureScheme`?

Unfortunately not. While the ECDSA and EdDSA keys indeed only have one
valid SignatureScheme, RSA keys have three (the difference being
using SHA-256 vs. SHA-384 vs. SHA-512). This holds for both genric
RSA keys and RSA-PSS keys (and the signatureschemes are different for
those two).

Also, relying on this even for ECDSA keys might not be a good idea,
as if another hash ever gets added, then there could be mulitple
SignatureSchemes even for ECDSA keys.

-Ilari