Explicitly note certificate "purpose" (the subject)

[Stebalien]

Currently, if a peer uses their peer ID to sign a certificate, QUIC will allow the signed key to act on behalf of the peer. The peer should have to explicitly state that they want to delegate their peer ID.

Motivation: If we don't do this, we won't be able to use peer IDs to sign any certificates except delegation certificates.

Proposal: Put /p2p/QmPeerID in the certificate's subject field (or some other field if that doesn't make sense). The certificate would only be valid if there exists some certificate higher up the chain signed by that peer ID.

[marten-seemann]

How would that work if we at some point use RFC 7250 style raw public keys? We wouldn't have any fields to note certificate purpose there.

[Stebalien]

This issue is just for certificate chains. That is, when permanent key A (used in the peer ID) signs ephemeral key B, the produced certificate should somehow indicate that key A is delegating to key B. If I'm using the key directly, there's really no need.

[marten-seemann]

It seems like there are two ways we can go from here:

1. If we want to use private keys directly, we can use raw pub key authentication, and we can get rid of the certificate chain (until we actually implement RFC 7250). This means that peers would need to generate child peer IDs if they want to keep their main ID offline.
2. We decide that child peer IDs are not a thing, and that we use certificate chains to enable peers to keep the private key of their main ID offline. This would then require us to fix this issue as well as Custom length certificate changes #21.

[Stebalien]

While I like the idea of using keys directly, I wonder if it would be simpler to just use length N (where 1 <= N <= 10 (or some sane bound)).

My worry is that RFC 7250 isn't widely supported which may increase the barrier to entry. This isn't much of an issue for QUIC because it's so new, I'd refer it if we could reuse the the same handshake/config across for TLS (1.2 and 1.3) over TCP.

Actually, is there any way for the client to indicate if it supports 7250? If so, we could say that self-signed certificates must be supported but bare keys should also be supported.

[marten-seemann]

Yes, RFC allows for a fallback. It's basically just an extension that is sent in the ClientHello TLS message. If the server supports it, it proceeds accordingly. TLS skips unsupported TLS extensions, so we could just use the normal certificate-based authentication then.
Using raw public keys will take us some time anyway. I'm planning to implement it into tls-tris at some point, but I don't see that happening before next year.

My point was that if we decide to use raw public keys (at some point) and to use the certificates as a fallback, this implies that we're rather taking the child peer ID path. Then we don't need any for support certificate chains, a single self-signed certificate would be sufficient.

[Stebalien]

I see. Yeah, I'd be fine just going with the single-link chain then. That's what the original TLS patch did anyways.