PHB,
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.
A cabal? Gee do member have secret handshakes and a secret clubhouse?
That sounds like fun. Can I join? Oh, you're
saying that I _am_ a member!
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.
The fact that the PKIX WG did not elect to adopt every proposal you made
is hardly a justification for name calling.
Moving your crusade to the CABF was a good strategy; fewer folks to
convince and a focus on outcomes independent of
architectural considerations. This is the same group that wanted to give
CAs 3 years to fix a serious security bug,
before the ICANN SSAC insisted otherwise, if I recall Warren's briefing
in SAAG.
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.
It might be worth emhpasizing that the principal reason cited for not
marking the extension critical, as per X,.509
and RFC 5280, was a single vendor's unwillingness to fix a bug in their
browser. The CABF members, being browser vendors
as well as third-party CAs, was the prefect venue in which elect to
given precedence to a vendor's intransigence.
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.
A number of folks have long wanted OCSP to be a cert status protocol,
instead of a cert _revocation_ status protocol.
DoD is probably not the only CA that uses CRLs to generate OCSP replies.
The relevant RFCs have always allowed
this practice, and it's a reasonable one, especially if the OCSP service
providers is not the CA.
There are a number of ways that the major problems associated with
DigiNotar breech could have been mitigated, many
of them not requiring any changes to protocols.
The fundamental issue here, for both of the examples cited, is that the
browser PKI model is a terrible one.
DANE is a much better solution, except for the CAs that might lose
business as a result.
Steve
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
