<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 5:29 AM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sig,<br>
<br>
You made a statement in another email which, if I'm remembering correctly, said something like this: If a cert is issued from a public root, for public domains, for use by the public, then its contents is automatically public.<br></blockquote><div><br></div><div>If a cert transitively chains to a publicly trusted root, it should be public, technically constrained subordinate CA notwithstanding.</div><div><br></div><div>We've already seen CA's CPSes and Relying Party Agreements attempt to use either copyright or trademark to prevent the distribution of such certificates. This is why, for example, the Mozilla Inclusion Policy was updated to include this disclaimer with respect to Intermediate certificates"All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part." or, for example, why Chromium's CT policy and RFC 6962 are worded in such a way to prevent things like 'paywalls' or 'auth gates'</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Is this based on:<br>
1. An authoritative definition? (if so, please cite a reference)<br>
2. A commonly held belief?<br>
3. Your own interpretation?<br></blockquote><div><br></div><div>Given that Certificate Authorities trusted by a given Root Program are entrusted by that Root Program to operate in the interest of the public (or, alternatively defined, that Root Program's users, which at least according to the CA/Browser Forum's bylaws is particularly interested in those that provide software to 'the general Public'), it's arguably reasonable to see #2 as the expectations of both users and Root Programs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Also, I think Inigo raised some privacy concerns that may make the above a violation of local laws. </blockquote><div><br></div><div>Considering that our very documents refer to them as "Publicly Trusted Certificates", it is intrinsic in the definition that they be Public in order to be Publicly Trusted. Any CA that is issuing certificates that they cannot freely and readily disclose due to local jurisdictions either:</div><div>a) Needs to relocate jurisdictions</div><div>b) Change their issuance process to not impinge upon such local jurisdictions</div><div>c) Request that their CA be removed from being Publicly Trusted.</div><div><br></div><div>In concrete, and absolute, terms: Privacy is not a justification for nor a shield during misissuance.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Your text below doesn't address that. That may be problematic for a 1 week timeline, especially if there are many domain owners that need to be consulted.<br></blockquote><div><br></div><div>Why would any form of disclosure need to wait for the domain holders being consulted?</div><div><br></div><div>I'm sorry, I absolutely do not buy this argument. If a CA misissues a certificate, it must be prepared to disclose the full contents of that certificate. Doubly so if such a misissued certificate was not delivered to the domain holder - there is zero standing for that domain holder to argue for non-disclosure.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Are you saying that any cert not in compliance with the BRs constitutes misissuance?<br></blockquote><div><br></div><div>Yes</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In the future, when name redaction is allowed for OV/DV, publishing the full certificate negates the value of name redaction. So for example, consider a case where the cert was issued to the right recipient, but the misissuance was the addition of a misleading OU field, or a "MUST INCLUDE" extension is omitted. The proposal would force CAs to reveal the redacted names.<br></blockquote><div><br></div><div>You speak of name redaction, which I suspect involves Certificate Transparency, but what is relevant for the CA/Browser Forum is that of Technically Constrained Subordinate CAs.</div><div><br></div><div>Unlike the Mozilla policy which the BR language was originally modeled after, the advocates of introducing technically constrained certificates as a class within the BR kept all of the BR obligations in scope for such certificates, except that of the audit.</div><div><br></div><div>That is, where Mozilla's policy would have exempted such certificates from the burden of compliance with Mozilla's policy (both audits and profile), the BRs only exempt audit, not profile.</div><div><br></div><div>As such, a leaf certificate issued underneath such an intermediate IS misissued and ostensibly the parent CA of the issuer-of-misissuance (aka, the root CA that signed the intermediate) SHOULD reasonably be expected to detect this during their quarterly audits.</div></div><br></div></div>