Re: [TLS] Certificate validation can of worms

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Apr 8, 2014 at 4:06 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> On Mon, 2014-04-07 at 18:20 -0700, Watson Ladd wrote:
>
>> > And a TLS client that implements rfc2818 (HTTP-over-TLS) will look
>> > exactly at rfc2818 for any checks that the client will do on the
>> > Server certificate, and again *NOT* in PKIX.
>>
>> This is really a problem with RFC2818. The whole idea of X509v3 is
>> that you should be able to issue certificates that have meaning beyond
>> assertions of identity, such as for use as code-signing. But because
>> implementations don't respect the PKIX standard, we can't do that.
>
> I think PKIX is far from being described as standard. It looks more than
> a set of rules that the implementer is expected to distill and select
> the relevant ones, as most of the described rules are legacy baggage
> (e.g. DN comparison rules that assume that the DN is copied by a
> secretary that introduces case changes and alters spaces, rather than a
> memcpy).
>
> PKIX's requirements are pretty strange to put it mildly. One example are
> the key purposes that Martin described. Another is the name constraints
> which is optional to implement for DNS or e-mails (that everyone uses),
> and mandatory for DistinguishedNames (that no-one uses); then it becomes
> an issue when people realize that no-one implements name constraints
> (and the only certificates that I've seen that contained constraints,
> had syntactical errors in them). There are much more issues in PKIX (and
> Peter Gutmann is much better in providing a good overview). We certainly
> need something better than rfc5280.

Name constraints are in use today. They are supported in all the
browsers with the possible exception of OSX (which I am told is fixed
but I have not checked).

The issue with Name Constraints is that the Industry has rejected the
IETF specification which requires that a Name Constraint be marked
'break backwards compatibility' aka the 'critical bit'. This
requirement is stupid and wrong and so the industry has decided to
override RFC5280 on this point and the correct specification as far as
the industry is concerned is that the setting of the critical bit is
at the option of the issuing CA.

If IETF produces rubbish specifications we will ignore them.

The requirement to mark the certificate critical enabled the NSA
attack on Microsoft in the Flame malware attack. Marking the bit
critical makes it impossible to issue a certificate with that
extension as about half a billion deployed devices don't support name
constraints.

The consensus model does not really work when a specification has been
poisoned by an attacker who can block changes to correct the spec.
Fortunately IETF specifications are not definitive, industry practice
is. The industry consensus on this point is unanimous: name
constraints need not be marked critical.


Industry consensus is also unanimous that RSA1024 is inadequate for
any form of PKI infrastructure use including for ZSKs. So right now
DNSSEC is not adequately deployed in the ICANN root or in .com in a
form that can be considered fit for purpose. So the idea that the
world is going to move to a DANE validity chain is rather peculiar.

Fixing this situation requires a minor configuration change next time
the keys are rolled. So don't take this as an argument against DNSSEC
per se. I think it is just indicative of the reason why having ICANN
in charge of global PKI is not exactly a sound proposition.

-- 
Website: http://hallambaker.com/