3 ms·

Nah, we'd still have plenty of CAs at any given time. After all, it's highly unlikely that all of them will fuck up at the same time. If you buy from a reputabl

by kijin 12y ago

Nah, we'd still have plenty of CAs at any given time. After all, it's highly unlikely that all of them will fuck up at the same time. If you buy from a reputable CA, there's at least 90% chance that you won't have any issues during the life of your certificate (1-2 years). If the requirements for becoming (and remaining) a CA become stricter than they are now, the market will adjust after a while. Peace of mind has always been, and will always be, a very strong selling point. How about this: "We'll sell you three certificates for the price of one! One signed by Comodo, one signed by Verisign, and one signed by GlobalSign! And here's an Apache module that detects when one of your CAs get discredited, and automatically replaces it with a good one!"

yuhong 12y ago
Or just create a TLS extension that allow all of the chains to be served as part of the TLS Certificate message.
- geofft 12y ago
  There's even an SSL extension for the client to mention its list of trusted root CAs in its side of the handshake. It's very rarely used on desktop / on the public Internet because people tend to trust more CAs than would fit in a TCP packet, but it's apparently useful enough in embedded scenarios to standardize. https://tools.ietf.org/html/rfc6066#section-6 https://tools.ietf.org/html/rfc6066#section-6 You could imagine a variant for, say, pointing out that you explicitly distrust certain CAs that the server is likely to assume you trust.
- toast0 12y ago
  Unfortunately, that's not valid per the RFCs (from rfc 5246, TLS 1.2): "certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case." I would be super happy if I could send multiple certificates though (provided all my clients magically got tls client library updates to handle it)
  - yuhong 12y ago
    Just edited my comment.

by kijin 12y ago

yuhong 12y ago

Or just create a TLS extension that allow all of the chains to be served as part of the TLS Certificate message.

geofft 12y ago
There's even an SSL extension for the client to mention its list of trusted root CAs in its side of the handshake. It's very rarely used on desktop / on the public Internet because people tend to trust more CAs than would fit in a TCP packet, but it's apparently useful enough in embedded scenarios to standardize. https://tools.ietf.org/html/rfc6066#section-6 https://tools.ietf.org/html/rfc6066#section-6 You could imagine a variant for, say, pointing out that you explicitly distrust certain CAs that the server is likely to assume you trust.
toast0 12y ago
Unfortunately, that's not valid per the RFCs (from rfc 5246, TLS 1.2): "certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case." I would be super happy if I could send multiple certificates though (provided all my clients magically got tls client library updates to handle it)
- yuhong 12y ago
  Just edited my comment.