Re: [Trans] path validation

[Stephen Kent <[e-mail]>]

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.