search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.58k stars 275 forks source link

Require the libp2p extension to be non-critical #241

Closed Demi-Marie closed 3 years ago

Demi-Marie commented 4 years ago

Otherwise webpki (and thus rustls) reject it.

marten-seemann commented 4 years ago

Why do they reject it?

Demi-Marie commented 4 years ago

They don’t understand it, so they reject it per the X.509 specification.

marten-seemann commented 4 years ago

Isn't that the right thing to do though? If they don't understand how to do the libp2p handshake, failing the handshake would be what we want them to do, wouldn't it?

Demi-Marie commented 4 years ago

@marten-seemann WebPKI does two things:

  1. Verifying that a signature was made by the holder of the secret key corresponding to the public key in the certificate.
  2. Verifying that the certificate should be trusted.

Part 1 requires no knowledge of extensions. If there is a critical extension that WebPKI does not understand, part 2 should fail, but part 1 should not.

marten-seemann commented 4 years ago
  1. Verifying that a signature was made by the holder of the secret key corresponding to the public key in the certificate.
  2. Verifying that the certificate should be trusted.

That sounds like how every implementation would do certificate verification.

If the libp2p was not critical, it would be ok for implementations to skip handling this extension, which would compromise the security properties we're expecting from the handshake.

Demi-Marie commented 4 years ago
  1. Verifying that a signature was made by the holder of the secret key corresponding to the public key in the certificate.
  2. Verifying that the certificate should be trusted.

That sounds like how every implementation would do certificate verification.

If the libp2p was not critical, it would be ok for implementations to skip handling this extension, which would compromise the security properties we're expecting from the handshake.

Does that make this a WebPKI bug? WebPKI refuses to even parse a certificate with a critical extension it is unaware of.

@marten-seemann

ctz commented 4 years ago

Part 1 requires no knowledge of extensions.

I'm not sure I agree. Consider something like the EKU extension.

Demi-Marie commented 4 years ago

Part 1 requires no knowledge of extensions.

I'm not sure I agree. Consider something like the EKU extension.

That is still part of step 2, in my opinion. EKU determines what the valid uses of a a certificate are. It doesn’t affect whether a message was signed by the holder of the secret key corresponding to the certificate’s private key. That data is in the SubjectPublicKeyInfo structure, which makes no reference to extensions.

In any case, it is still necessary for WebPKI to be able to verify signatures made by the holders of certificates that have critical extensions it does not understand. Otherwise, it cannot be used for libp2p, which means that rustls cannot be used for that purpose either.

marten-seemann commented 4 years ago

Does that make this a WebPKI bug? WebPKI refuses to even parse a certificate with a critical extension it is unaware of.

How would you then parse a certificate with a critical extension (other than the one that WebPKI ships with)? If this is really how WebPKI deals with things, this would mean that there's a list of hard-coded critical extensions, and you'd never be able to use any critical extension that's not on this list.

Demi-Marie commented 4 years ago

Does that make this a WebPKI bug? WebPKI refuses to even parse a certificate with a critical extension it is unaware of.

How would you then parse a certificate with a critical extension (other than the one that WebPKI ships with)? If this is really how WebPKI deals with things, this would mean that there's a list of hard-coded critical extensions, and you'd never be able to use any critical extension that's not on this list.

My thoughts exactly. Pinging @briansmith.

briansmith commented 4 years ago

My thoughts exactly. Pinging @briansmith.

Please file an issue in the webpki repo that points to the specification that clearly describes how the certificates are supposed to be processed in libp2p. Then we can discuss whether it makes sense to add support for this protocol to webpki.

Demi-Marie commented 4 years ago

@briansmith I filed an issue (https://github.com/briansmith/webpki/issues/119).

mxinden commented 3 years ago

Closing here since this is implementation (webpki) specific only. Please comment in case I am missing something.