Hiya, FWIW, I don't buy Phill's theory at all.
I do think its fair to say that the US DoD set of requirements for PKI have dominated discussion at various times. Now that is a complex PKI and not much like the web PKI so that has generated some friction, but I don't see any need at all for conspiracy theories to explain that. It just seems to me like a normal case of different reasonably large sets of folks having very similar but slightly different requirements. On the specific topics below, if I recall correctly, both were uncontroversial parts of the "design" of PKI for years before they became problematic for the web PKI when it finally started to seriously consider revocation. And it seems to me that both "sides" in that debate were inflexible and unwilling to make changes. I still don't know why that was, and it still seems dumb to me, but life's full of little mysteries like that. And I am just not seeing how this is related to pervasive monitoring except very very tangentially - Phill, can you please explain its relevance? And finally the subject line also seems unwise as it'll probably just annoy folks and just distract us from getting real work done. (So, if it does annoy you, please try be moderate in your response, or maybe don't even send that mail, until we see how Phill justifies its relevance.) Cheers, S. On 10/19/2013 04:24 PM, Phillip Hallam-Baker wrote: > There are a bunch of changes to PKIX that were blocked for quite some time. > The opposition coming from a cabal of DoD etc. contractors. This opposition > has proven ultimately futile since the industry has decided to ignore the > specification and set its own standards in two cases. > > I don't want to get into a discussion of Snowden etc. I will however note > that I suspected something of the sort was going on several years ago and > that is why I was looking to take the standards process to a forum where > such interference could be prevented. The only practical effect of Snowden > is that I can now explain the reasons for that decision without sounding > like a black helicopter paranoid nut. > > > 1) Name Constraints MUST be marked critical > > And utterly stupid restriction since the semantics of the criticality bit > are 'break backwards compatibility'. Use of name constraints provide a > significant reduction in the attack surface and would have prevented the > Flame attack. However marking a name constraint critical breaks Safari and > provides no security benefit in the Web PKI. > > Outcome: Industry has decided that the standard is that name constraints > MAY be marked non-critical. > > > 2) OCSP reports success for unknown/unissued certificates. > > One of the reasons that the DigiNotar incident was so severe is that the > OCSP responder reported 'Valid' status for certificates that the CA had not > issued. This limit is allegedly a consequence of the DoD's billion dollar > PKI being unable to issue OCSP responses except by using CRLs as a source. > > One important consequence of this constraint is that it provides a weak > form of CA transparency. It is possible to determine whether a CA is > consistently defaulting on this requirement or not. > > > Outcome: Industry has mandated OCSP responses report INVALID status if the > certificate was not issued. > > > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
