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