<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-05-31 22:38 GMT+02:00 Viktor Dukhovni <span dir="ltr"><<a href="mailto:cryptography@dukhovni.org" target="_blank">cryptography@dukhovni.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, May 31, 2016 at 08:47:11PM +0200, Erwann Abalea wrote:<br>
<br>
> Another behavior dictated by the norm is this:<br>
><br>
>  CA(BC:pathLenConstraint=0) -> self-issued CA(anything) -> end-entity : OK<br>
><br>
> That is, they could issue another CA certificate named the same (C=US,<br>
> O/OU..., CN=Blue Coat Public Services Intermediate CA) for which they have<br>
> the private key, and then issue end-entity certificates. It works because<br>
> the pathLength is decremented for each non self-issued CA certificate. I<br>
> haven't tested implementations on this point.<br>
<br>
</span>If BlueCoat had the key for the path-constrained intermediate CA<br>
they could indeed create additional self-issued intermediates.<br>
However, allegedly they don't have the key.  So the self-issued<br>
intermediate would have to be issued to BlueCoat by Symantec.<br></blockquote><div><br></div><div>The private key is hosted by Symantec, but most likely on a shared online HSM, on their Managed PKI service.</div><div>I guess someone from BlueCoat has a clientAuth certificate to approve the generation of subscriber certificates.</div><div>Hopefully, IIRC, Managed PKI doesn't allow the client admin to change certificate profiles.</div></div><div><br></div>-- <br><div class="gmail_signature">Erwann.</div>
</div></div>