Stephen Farrell and Steve Kent: > On 01/10/14 15:30, Stephen Kent wrote: >> How can we proceed on CT if we don't have a solid definition of the >> problem it purports to address? Certainly detecting mis-issuance >> has to be well-defined. > > I think this is the crux of the matter. > > Mis-issuance is not a feature but a bug. Attempting to > describe all possible bugs of any sort is futile. If you > argue that a CT RFC has to describe all possible bugs, then > that amounts to arguing to not do CT. But the IETF has > reached consensus to do CT so it seems that others do not > agree with you that "detecting mis-issuance has to be > well-defined" at least if that is meant to call for a > complete enumeration of all the ways in which mis-issuance > might occur. (And I don't get what else you might have > meant, but please correct me if I'm misreading what > you've written.) > > Having some examples of mis-issuance described is quite > reasonable. Asking that all forms of mis-issuance be > documented is not reasonable. > > Now as to CABF, while its very reasonable to think about > their requirements, I don't think it'd be a good plan > to hard-code a dependency on a version of those into a CT > RFC. Their baseline reqs doc has changed 3 times this year > already for example and 5 times in 2013 and I suspect will > continue to evolve significantly. > > But if you see a stable useful and quotable definition of > mis-issuance in one of their documents, then sending a > pointer to that text would be good. I don't know if there > is such a piece of text though. > > Cheers, > S. > > PS: I'm not sure CABF would describe themselves as an SDO > either, but that's a mere matter of terminology.
I think it is fairly easy to define mis-issuance, but I think it is nearly impossible to detect mis-issuance by an independent third party. To my way of thinking, mis-issuance is a certificate that is issued in violation to some aspect of the certificate policy identified in the certificate itself. I can think of very many policy violations that are not visible in the certificate itself. Russ _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
