Stephen,
Hiya,
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.
I didn't say that, don't put words in my mouth.
But the IETF has
reached consensus to do CT
I think that's s an overstatement. This WG was formed without a BoF.
So the usual IETF consensus process was not followed. You persuaded your
fellow IESG members to approve the WG and to use the Experimental RFC as
the starting point for a standard track RFC. I doubt that many of them
paid close attention to the Experimental RFC. In any case, the charter
does not use the term "rubber stamp" so I think we're free to revisit
the design, which is under-specified, lacks a security analysis, etc.
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.)
Again, don't mis-characterize what I have said. One need not
enumerate _all_ the ways that a cert can be mis-issued. One can,
however, should be able to characterize classes of behavior that
constitute mis-issuance, unless one is _trying_ to be ambiguous. Within
the classes of mis-issuance it ought to be possible to enumerate a fair
number of MUSTs, to note when no external examination of certs can detect
mis-issuance, and to note when mis-issuance can be detected based on
specified,
per-Subject (and/or per-Issuer) data. These all seem like reasonable
characterizations
that ought to be pursued. I have been doing so in the text I've provided.
Having some examples of mis-issuance described is quite
reasonable. Asking that all forms of mis-issuance be
documented is not reasonable.
ibid.
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.
We can accommodate changes in specs; we do it in other contexts.
I looked at the 3 2014 versions of the baseline spec, using the
diff's the CABF provides on its website. None of the changes in 2014
affected any of the requirements included in my proposed Appendix.
Looking at the 2013 changes, the only one I noted that had real impact
on the
syntax checks I proposed was version 1.1.6 (July 2013). In that version
the discussion of EKU and nameConstraints was added. That change relates
to just one set of syntactic checks. In 1.1.4, they added DSA
modulus/divisor
constraints. This is precisely what Ben cited as a cert mis-issuance
criteria,
so, presumably, we would want to update our specs accordingly.
Given that, over the past 2 years, there have been only two changes that
have any impact on the syntax checks I enumerated, and that they impact
only two of the detailed chekcs, I think this argument is a red herring.
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.
First, they would never define mis-issuance, any more than 5280
would define a defective cert, per se, so the suggestion is silly,
Stephen. The guidelines define requirements for the format of certs (DV
and EV)
and procedures for cert issuance by CAs. So, one develops a definition
for syntactic
mis-issuance, based on their guidelines, by noting violations of the
format MUSTs.
Semantic mis-issuance is similarly defined.
Steve
p.s. Yes, I agree that CABF is not an SDO, but neither was the source of
PKCS
doc when the IETF elected to use them as the basis for CMS.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
