Re: [Trans] Threat model outline, attack model

[Stephen Kent <[e-mail]>]

Ben,

> ...
>> Mis-issuance is the primary (sole?) rationale for CT, so I am not
>> comfortable
>> with the notion that mis-issuance is not well-defined.
> Reality doesn't always make us comfortable :-)
>
> We keep finding new ways for people to get certs wrong, and thus
> creating new rules for them. Also, the exact rules are context
> dependent, and may even depend on contracts and other things we can't
> even see.
I don't accept that rationale as a basis for avoiding creating a definition
for mis-issuance.

The CABF Guidelines are revised over time. We can update the RFC to match.
We do that for other IETF Standards.

I don't understand the notion of context dependence for the definition
of mis-issuance. Can you provide some examples? Who decides what constitutes
a mi-issued cert inn what context?

I agree that a contracts between a CA and a Subject can include terms and
conditions that might cause aert to be "mis-issued" relative to those
Ts & Cs. But, I though CT was trying to enable Monitors to detect 
mis-issuance
on an Internet-wide scale. Violation of Ts & Cs is something that the
Subject and CA would be able to determine, but not others, in general.
At a minimum we need a set of universally-applicable issuance standards to
apply, based on two things:
- the syntax of the cert, which everyone can examine
- comparison of logged certs against reference certs, i.e., valid
certs already issued to (legitimate) Subjects. A Monitor can
perform this comparison if provided with a reference cert. if the
Monitor wants to perform additional checks, that may be fine

if we're going to create a standard that purports to detect mis-issuance,
but we can't define mis-issuance in a well-articulated, testable fashion, I
question the utility of this effort.
>> I'm puzzled; how would CT allow a Monitor to determine who generated the
>> key pair used in a cert that was logged? I don't understand your example
>> here.
> I said it wouldn't, so you are right to be puzzled.
Then why cite this as as an example of mis-issuance, and yet claim that CT
is intended to detect mis-issuance? That's what I find puzzling.
>>> As far as I know there are no standards in this area. Chrome contains
>>> a blacklist of certificate hashes (from memory, its been a while since
>>> I looked at this) - I don't know what other browsers do.
>> Well, if we can't say how this is done, preferably based on some standard,
>> then we can't make an argument that, after being being detected by CT, that
>> there is a fix. If so, then the security considerations section will have to
>> discuss this residual issue.
> I think we have ample evidence that there are fixes to mis-issuance.
> Some of them are based on standards, too (e.g. revoking in CRLs or via
> OCSP).
I believe we have to be able to explain how mis-issuance (if it can be 
defined)
is detected by CT, and then how the detection provided by CT is used to 
address
the problem. That's why I believe we need an architecture and a 
threat/attack model, so
that there is a framework for explaining how CT fits into a solution to 
the problem.
When there are standards-bases ways to respond to mis-issuance detected 
by CT, then we
need to point to them. When there are not, we need to admit that and say 
that there
are residual problems, or that there are extant, but not standardized, 
mitigation
techniques.

Steve