Chris's Wiki :: blog/tech/WhyDirectCertificateChecking Commentshttps://utcc.utoronto.ca/~cks/space/blog/tech/WhyDirectCertificateChecking?atomcommentsDWiki2007-01-22T16:37:34ZRecent comments in Chris's Wiki :: blog/tech/WhyDirectCertificateChecking.By Chris Siebenmann on /blog/tech/WhyDirectCertificateCheckingtag:CSpace:blog/tech/WhyDirectCertificateChecking:fb103746692bcabe0d3fef53669d0dae4f8a19faChris Siebenmann<div class="wikitext"><p>You're right; I should not have talked about authorization at all. Indeed
in the situation I'm thinking about, the authorization is entirely
separate; we would not be making the SSL call to verify the host's identity
if the machine wasn't authorized.</p>
<p>I still prefer 'check if certificate is X' to 'check if certificate is
signed, has not been revoked, and has a CN of X' as a way of verifying
the host's identity, though.</p>
</div>2007-01-22T16:37:34ZBy Dan.Astoorian on /blog/tech/WhyDirectCertificateCheckingtag:CSpace:blog/tech/WhyDirectCertificateChecking:4c7fcd4f218199c4cf99753b20b12bf6367a1e3aDan.Astoorian<div class="wikitext"><blockquote><p>(You do not have to check that the host is authorized; you would not have signed a certificate with a CN for an unauthorized host, and if a host becomes unauthorized you add its signature to your CRL.)</p>
</blockquote>
<p>With all due respect, that's a really poor way to manage authorization.</p>
<p>Authorization is a separate problem from identification and authentication; you are attempting to combine everything into a single process by declaring "any host I can authenticate is authorized."</p>
<p>A far better model is to use SSL for identification and authentication ("I am host <em>A</em>, and I can prove that I hold <em>A</em>'s private key"), then use other means to manage authorizations for authenticated hosts ("host <em>A</em> is allowed to use this service, but host <em>B</em> is not).</p>
<p>The CRL is used when the authentication loses its trustworthiness (<em>e.g.</em>, because there's evidence that someone might have had access to <em>A</em>'s private key, not merely because <em>A</em> is no longer authorized to access the service).</p>
<p>--Dan</p>
</div>2007-01-22T16:07:28ZBy Chris Siebenmann on /blog/tech/WhyDirectCertificateCheckingtag:CSpace:blog/tech/WhyDirectCertificateChecking:f9c1a66d0f5ffc7c9c3a3d5249e4de38904b4e33Chris Siebenmann<div class="wikitext"><p>To simplify my argument, let's look at what you need to do to authenticate
a host in each case:</p>
<ul><li>for CA checking: check CA signature, that the certificate is not in
the CRL, and that the certificate's CN (or other attribute that you
have specified) matches the host.<p>
(You do not have to check that the host is authorized; you would not
have signed a certificate with a CN for an unauthorized host, and if
a host becomes unauthorized you add its signature to your CRL.)<p>
</li>
<li>for direct checking: check that the certificate is authorized for
that host, either directly or by having a global list of authorized
certificates and then checking that the certificate CN matches the
host.</li>
</ul>
<p>(Note that in both cases you need to keep a complete list of authorized
certificates yourself; it is just that in the CA case, the only thing
you use the list for is putting things in the CRL.)</p>
<p>I believe that the second case is simpler, has fewer moving parts, and
is more direct. As a result I like it better and trust it more.</p>
</div>2007-01-20T23:34:33ZBy Chris Siebenmann on /blog/tech/WhyDirectCertificateCheckingtag:CSpace:blog/tech/WhyDirectCertificateChecking:5024d3732b0a8d176e36bafc9265630f594028dcChris Siebenmann<div class="wikitext"><blockquote><p>In other words, it's easier for you to believe in because you can see it?</p>
</blockquote>
<p>It's easier for me to <em>trust</em> because I can see it. (It is also easier
to manipulate, because I can do so directly instead of indirectly.)</p>
<p>As a side effect, it also removes the need to crack the certificate
open and check that the CN matches and so on. (Doing so is necessary
in a CA situation.)</p>
</div>2007-01-20T23:13:27ZFrom 128.100.26.136 on /blog/tech/WhyDirectCertificateCheckingtag:CSpace:blog/tech/WhyDirectCertificateChecking:fead824f3a3fcdedb7c191f89039e314617b0040From 128.100.26.136<div class="wikitext"><blockquote><p><em>If</em> you actually knowingly issued the key, that is true.</p>
</blockquote>
<p>My point is that it is probably very safe, from a practical perspective, to assume that I did knowingly issue the key.</p>
<p>For this not to be the case, one must assume that an attacker had the ability to compromise my CA private key (which would certainly have been passphrase-protected, and is only ever used when signing new host certificates), but would not have been able to compromise a trusted host private key (which is used orders of magnitude more frequently, and thus is far more likely to be stored somewhere on the host in an unencrypted form).</p>
<p>(Strictly speaking, there is another possibility: there could be a flaw in the design or implementation of the cryptographic infrastructure itself; <em>i.e.</em>, a weakness in the software or algorithms which make it possible for host keys to be signed without possessing the CA's private key. The fact that the entire e-commerce industry has already bet very, <em>very</em> heavily against this possibility makes it difficult to lend much credibility to this idea.)</p>
<blockquote><p>But the presence of the digital signature is much more direct and visible, so it is much more amenable to me checking to make sure that intentions and reality actually match up.</p>
</blockquote>
<p>In other words, it's easier for you to believe in because you can see it?</p>
<p>I don't dispute that direct certificate checking is a simpler approach (or would be, if the software you were using provided support for it). I only maintain that it is nevertheless not (by the mere fact of its comparative simplicity) significantly more secure than the approach already designed into the system.</p>
<p>--Dan</p>
</div>2007-01-20T20:57:57ZBy Chris Siebenmann on /blog/tech/WhyDirectCertificateCheckingtag:CSpace:blog/tech/WhyDirectCertificateChecking:eaa8241ef0e0cd9b089ae8f6a2374d04fc5fa6c6Chris Siebenmann<div class="wikitext"><p>Let me rephrase my CA+CRL versus direct checking thing slightly:
CA+CRL is fundamentally 'everything not explicitly listed is allowed
(provided that it is signed by the CA cert etc)', whereas direct
checking is 'everything that is not explicitly listed is forbidden'.</p>
<p>I disagree with:</p>
<blockquote><p>[...] issuing a host certificate with your CA certificate is a
(cryptographically-strong) form of explicitly granting permission
to the possessor of the certificate's private key, [...]</p>
</blockquote>
<p><em>If</em> you actually knowingly issued the key, that is true. But a signature
by the CA certificate is not proof of that any more than my digital
signature on a piece of email is proof that I wrote it, and for the same
reason. Both are merely reasonably strong indications.</p>
<p>Of course, neither is the presence of a digital signature in a
directory. But the presence of the digital signature is much more
direct and visible, so it is much more amenable to me checking to
make sure that intentions and reality actually match up.</p>
</div>2007-01-19T22:14:56ZBy Dan.Astoorian on /blog/tech/WhyDirectCertificateCheckingtag:CSpace:blog/tech/WhyDirectCertificateChecking:b224b07d64a33a2744b88603bd4faf0f16877ba7Dan.Astoorian<div class="wikitext"><blockquote><p>Even with CA plus CRL you still have the risk that an attacker has managed to get some signed host certificates of his own (whether by quietly compromising your keys or by surreptitiously inserting things into your processing pipeline)</p>
</blockquote>
<p>This is a practical risk if and only if it is substantially easier to create a new signed host certificate than to break or steal the private key for an existing one; I can't think of any reason that would be the case, unless you are doing something very, very wrong (such as failing to protect your CA private key at least as well as your host certificate private keys).</p>
<blockquote><p>What this boils down to is that the CA approach is 'everything that is not explicitly forbidden is permitted' (if it is signed by your CA certificate it is allowed unless it is in your CRL),</p>
</blockquote>
<p>That logic is tangled: issuing a host certificate with your CA certificate is a (cryptographically-strong) form of explicitly granting permission to the possessor of the certificate's private key, so it really boils down to "everything that is explicitly permitted [through issuing a certificate] that is not explicitly forbidden [via a CRL] is permitted (and everything else is forbidden)." From that statement follows this one: "everything that is not explicitly permitted is forbidden."</p>
<p>--Dan</p>
</div>2007-01-19T17:02:14Z