<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/03/2016 02:23, Viktor Dukhovni
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_20160311012325_GL10917_mournblade_imrryr_org"
cite="mid:20160311012325.GL10917@mournblade.imrryr.org"
type="cite">
<pre wrap="">On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote:
</pre>
<blockquote class=" cite" id="Cite_6566113" type="cite">
<pre wrap="">I am arguing that:
- 1.0.x behavior should not be changed, as it would violate the
principle of least surprise for a "security update" to change
semantics.
</pre>
</blockquote>
<pre wrap="">The odd 1.0.x behaviour leads to periodic email to openssl-security,
in which it is typically suggested that the 1.0.x behaviour violates
user expectations. Changing the 1.0.x behaviour addresses some
corner-case behaviour, and would not be inappropriate for a future
1.0.2 release. Keep in mind that 1.0.2 (unlike 1.0.1) gets bug
fixes not just security fixes. I have no plans to backport the
changes to 1.0.1 (EOL this December, security fixes only).
</pre>
<blockquote class=" cite" id="Cite_2097150" type="cite">
<pre wrap=""> - Therefore the 1.1.0 behavior should use the CA directory shared
with 1.0.x in a way consistent with how 1.0.x uses that directory
(as a repository for trust anchors only, as far as I understand
your non-replies), while 1.1.0 should store untrusted intermediary
certificates in a different directory where they don't affect
1.0.x instances running on the same machine.
</pre>
</blockquote>
<pre wrap="">Well, no, 1.0.2 uses the trust store not only for trust-anchors,
but also as a capricious source of intermediate certificates, whose
behaviour varies depending on whether the peer supplied same said
certificates on the wire or not. I expect to improve the capricious
behaviour.</pre>
</blockquote>
<tt>You keep dodging the question: Does 1.0.2g trust or not <br>
trust intermediary certs found in the "CA" store?</tt><br>
<blockquote class=" cite"
id="mid_20160311012325_GL10917_mournblade_imrryr_org"
cite="mid:20160311012325.GL10917@mournblade.imrryr.org"
type="cite">
<pre wrap="">
* The treatment of untrusted intermediates (not decorated with
explicit auxiliary EKUs) will be same regardless of origin.
* CRL checks, expiration checks, and EKU restrictions will apply
to all chain elements below the trust anchor (principle of least
surprise) regardless of origin (wire or trust store). This
avoids violating the principle of least surprise.</pre>
</blockquote>
<tt>And just to beat a dead horse again: Why skip those <br>
checks for the trust anchor too? A trust anchor can <br>
expire, be revoked or have insufficient EKUs just like <br>
any other cert.</tt><br>
<blockquote class=" cite"
id="mid_20160311012325_GL10917_mournblade_imrryr_org"
cite="mid:20160311012325.GL10917@mournblade.imrryr.org"
type="cite">
<pre wrap="">
* Partial chains (when enabled) will not extend beyond "intermediate"
CAs that have been "decorated" with auxiliary EKUs.
Yes, there is not in either 1.1.0 or 1.0.x a separate store of
intermediate certificates, that is just a local cache of certificates
erroneously left out of the peer's chain.</pre>
</blockquote>
<tt>Point is that if 1.1.0 introduces code that can load a <br>
certificate from the trust store without trusting it, <br>
then that new code should not be reusing a store which <br>
other software treats as a store of trust anchors.</tt><tt><br>
</tt>
<blockquote class=" cite"
id="mid_20160311012325_GL10917_mournblade_imrryr_org"
cite="mid:20160311012325.GL10917@mournblade.imrryr.org"
type="cite">
<pre wrap="">
Such a thing could be added to whatever release follows 1.1.0 if
there is sufficient demand or someone donates an implementation
that looks like a sufficiently compelling and well documented
feature.
My instinct is that giving administrators a new intermediate-CAfile
and intermediate-CApath to manage (to keep mostly empty) would not
prove especially popular. Placing undecorated intermediate certs
in the trust store is much simpler.
</pre>
</blockquote>
<tt>An intermediate-CApath store would typically act as a <br>
growing cache of encountered intermediaries, needing a <br>
lot less security considerations than a trusted-CApath.</tt><tt><br>
</tt><tt><br>
</tt><tt>This is especially useful with protocols and protocol <br>
variants where the convention is to not send the full <br>
certificate chain at all, but rather to expect the <br>
opposing end to request (and cache) any missing <br>
intermediaries as necessary.</tt><tt><br>
</tt><br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>