Ben,
On 26 September 2014 16:49, Stephen Kent<[email protected]> wrote:
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.
This is the kind of thing I meant.
I didn't see replies to my other comments above.
As for the contract example, I think this is out of scope for anything we
are trying to do. If we say that CT enables detection of mis-issuance based
on the model I described in my proposed Appendix, we cover a lot of cases
that are defined objectively, are universal, and have a basis in the
Guidelines
to which you alluded when you mentioned EV certs. We can say that
examination of
logs MAY be enable detect ingother forms of mis-issuance, but that
because we
have no definition of what that might be, it's out of scope for this doc.
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.
I want to enable as much to be detected as possible. Certainly if we
could only help in these narrow cases, that would be a cause for
concern - but my point is I don't think we can _fully_ nail down all
instances of mis-issuance.
And I don't think we cannot discuss, not make design decisions, based on
types of mis-issuance we can't define.
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 didn't intend to suggest there was no point in defining mis-issuance
to the extent that its possible, just that I don't think its likely
we'll manage to completely define it, so we should not attempt to do
so. i.e. I would not like to see the RFC say "this is mis-issuance,
and nothing else is".
Again, I disagree. We should define what we can and make design decisions
based on that definition. Anything else that might be considered
mis-issuanve,
is out of scope for purposes of this work. This is the sort of
delineation that
we often impose on RFCs; we define a scope for a standard and declare
that other
stuff is out of scope, relative to the standard.
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.
I was supporting your claim that not all forms of mis-issuance are
detectable by simply looking at the certificate (though I guess almost
all are).
Well, there are a lot of examples that I think most folks will agree are
mis-issuance,
and which are syntactic. The original case I envisioned, issuing a cert
to the wrong
entity, is addressed by having a reference to the "right" cert or to
equivalent data. There
is also the interesting case of non-existence of issuance, as asserted
by the entity
that controls the Subject name. I didn't address that, but one could
imagine doing so.
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.
Sure thing.
OK. I think we may be converging on some aspects of this issue.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
