<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 7, 2018 at 11:04 AM, Geoff Keating <span dir="ltr"><<a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="gmail-"><br><blockquote type="cite"><div>On Jun 7, 2018, at 3:32 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:</div><br class="gmail-m_8070773074166802315Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 7, 2018 at 10:24 AM, Geoff Keating <span dir="ltr"><<a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_8070773074166802315gmail-"><br>
<br>
> On Jun 7, 2018, at 1:40 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<br>
> <br>
> In the pursuit of a definition, we tried to work backwards - what are situations we think are misuse.<br>
<br>
</span>The dictionary definition of ‘misuse’ is:<br>
<br>
use (something) in the wrong way or for the wrong purpose<br></blockquote><div><br></div><div>I'm not sure how this helps us move forward</div></div></div></div></div></blockquote><div><br></div></span><div>I’m not sure how any of this discussion helps us move forward.</div></div></div></blockquote><div><br></div><div>Removing 4.9.1.1 (4) is an explicit proposal. The question is what will be lost if we do. It's unclear if anything will be lost, and if so, whether that thing can be articulated.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>1) Do you believe the right purpose is wholly reflecting in the Subscriber Agreement or Terms of Use?</div></div></div></div></div></blockquote><div><br></div></span><div>I’m having great trouble understanding this question. Why would I have any beliefs in this area? What does ‘reflected’ mean? Why are you asking me about a Subscriber Agreement I haven’t seen?</div><span class="gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>2) Do you believe the right way is wholly reflected in the definition I provided (from 1.1),</div></div></div></div></div></blockquote><div><br></div></span><div>(see above)</div></div></div></blockquote><div><br></div><div>This seems pretty unhelpful, I'm not sure how best to align our discussion. There's an explicit proposal - remove 4.9.1.1 (4). Would you (Apple) vote in favor of this? Would you vote opposed to this? Would you abstain? By understanding position and concerns, we can make forward progress.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> that the right way is "used for authenticating servers accessible through the Internet”</div></div></div></div></div></blockquote><div><br></div><div>That does seem like a partial definition of the right way to use a certificate.</div><div><br></div><div><br></div><div>Let’s try to make things more concrete. Your assertion is that auditors are having trouble with this wording. I presume this means that the following things have happened:</div><div><br></div><div>1. A report was made that a certificate was misused.</div><div>2. The certificate was not revoked.</div><div>3. The auditors couldn’t tell if step 2 was correct.</div><div><br></div><div>So, can you tell me more about the circumstances? What kind of misuse was alleged?</div></div></div></blockquote><div><br></div><div>Let's make it more concrete - no need to even get to the point of auditors.</div><div><br></div><div>I submit a problem report to a CA that says "This server operator is infecting my brain with radio waves by using their certificate. I would like you to revoke it for misuse."</div><div><br></div><div>As a CA, how do you determine whether or not that is misuse - so your obligations are clear and followed.</div><div>As a CA, how do you determine whether or not browsers will sanction you for not stopping the brain infections?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_8070773074166802315gmail-">
> Another suggestion was that it involved scenarios where the Subscriber private key was in an HSM, and itself was not compromised, but had signed things it was not expected to. This wasn't elaborated on further - so I'm uncertain if this meant things other than the TLS handshake transcript - but this is already met by our definition of Key Compromise in 1.6.1, that is:<br>
> ""A Private Key is said to be compromised if its value has been disclosed to an<br>
> unauthorized person, an unauthorized person has had access to it, or there exists a<br>
</span>> practical technique by which an unauthorized person may discover its value. “""<br>
<br>
If a key is in a HSM and not exportable, then its value is not disclosed, nor does an unauthorized person have access *to the key*. Dictionary definition of ‘access’ is 'obtain, examine, or retrieve’ none of which apply here. So it is not covered by Key Compromise.</blockquote></div><br></div><div class="gmail_extra">I'm not sure - what are you providing an example of?</div></div></blockquote><div><br></div></span><div>I didn’t use the word ‘example’ anywhere, I do not know what you are talking about.</div></div></div></blockquote><div><br></div><div>It sounds like you may not have completed your thought then. I thought you were providing a concrete example of an event that is a compromise key. I provided a short summary of that. Your statement beginning with "If a key" is fairly unclear - did you omit some concepts?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"> I would think that, say, generating a signed message that was not authorized, then "an unauthorized person has access to it”.</div></div></div></blockquote><div><br></div></span><div>This does not follow. If I there is an air conditioner behind a locked door, I do not have access to it, but maybe I can operate a thermostat and it will make me cold.</div></div></div></blockquote><div><br></div><div>I'm struggling to follow your thinking and confusion, perhaps through the argument-by-analogy not holding up well. Perhaps my confusion is that you're treating access as access to the underlying numeric values of the private key, rather than access to direct the inputs to combine with that key use. If that's correct, are your concerns ameliorated by rewording that section that:</div><div><br></div><div><div>A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to the underlying values of the key or the inputs to operations that use those values, or there exists a practical technique by which an unauthorized person may discover its value.</div></div></div></div></div>