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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
