> On Jun 7, 2018, at 3:32 PM, Ryan Sleevi <[email protected]> wrote: > > > > On Thu, Jun 7, 2018 at 10:24 AM, Geoff Keating <[email protected] > <mailto:[email protected]>> wrote: > > > > On Jun 7, 2018, at 1:40 PM, Ryan Sleevi via Public <[email protected] > > <mailto:[email protected]>> wrote: > > > > In the pursuit of a definition, we tried to work backwards - what are > > situations we think are misuse. > > The dictionary definition of ‘misuse’ is: > > use (something) in the wrong way or for the wrong purpose > > I'm not sure how this helps us move forward
I’m not sure how any of this discussion helps us move forward. > - were you suggesting that 4.9.1.1 would read: > > 4. The CA obtains evidence that the Certificate was used for the wrong way or > for the wrong purpose; > > With such a definition, this supposes there's a right way or right purpose. That does not follow but let’s go with it for now. > 1) Do you believe the right purpose is wholly reflecting in the Subscriber > Agreement or Terms of Use? 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? > 2) Do you believe the right way is wholly reflected in the definition I > provided (from 1.1), (see above) > that the right way is "used for authenticating servers accessible through the > Internet” That does seem like a partial definition of the right way to use a certificate. 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: 1. A report was made that a certificate was misused. 2. The certificate was not revoked. 3. The auditors couldn’t tell if step 2 was correct. So, can you tell me more about the circumstances? What kind of misuse was alleged? > > 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: > > ""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 it, or > > there exists a > > practical technique by which an unauthorized person may discover its > > value. “"" > > 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. > > I'm not sure - what are you providing an example of? I didn’t use the word ‘example’ anywhere, I do not know what you are talking about. > I would think that, say, generating a signed message that was not authorized, > then "an unauthorized person has access to it”. 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
