Subject: [TLS] Certificate validation can of worms

From: Watson Ladd <[email-masked]>
Date: Fri, 4 Apr 2014 18:35:52 -0700

Dear all,
https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests of
many TLS implementations. Interestingly all tested implementations
contain errors, and all but OpenSSL erroneous accepts. Cryptlib was
not tested, because it doesn't validate certificates.

At the core of these issues is the complexity of certificate
validation. Things for this committee to consider:

1: How will DANE make this worse?
2: Is this really the best we can do? What features of X509 led to
these problems?
3: This focused on server authentication. How does client authentication fare?
4: Did this actually cover everything?

Sincerely,
Watson Ladd

---

From: Yan Zhu <[email-masked]>
Date: Fri, 04 Apr 2014 18:48:54 -0700

> 3: This focused on server authentication. How does client authentication fare?

In case anyone wants to investigate these questions, the code used in
that study to generate mutated certificates is at
https://github.com/sumanj/frankencert. (You will need a corpus of
certificates to start from; the mirrors of EFF's SSL Observatory scan
results seem to all be unavailable at the moment, but that should be
fixed soon.)

-Yan

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 

-- 
Yan Zhu  <[email-masked]>
Staff Technologist
Electronic Frontier Foundation                  https://www.eff.org
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x134

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 Apr 2014 23:17:46 -0500

> 2: Is this really the best we can do? What features of X509 led to

Let's take #2 first.  Here's two entrants:

- x.509 naming is impossibly difficult to deal with (see RFC4514);

- stapled OCSP is how it should have been from day one -- CRLs add a ton of
complexity

Back to #1:  DNSSEC is a PKI, but with better naming and fewer root CAs.
We're going to need CT for DNSSEC.

> 3: This focused on server authentication. How does client authentication
fare?

Very differently.  For user authentication I think something more like
Persona (still PK, but not Internet-scale PKI) is better.  We really need a
standard account & device enrollment protocol to make user PK work well --
then we can land wherever on the PKI..web-of-trust..ad-hoc spectrum the
market likes best.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Fri, 4 Apr 2014 22:15:39 -0700

> - stapled OCSP is how it should have been from day one -- CRLs add a ton of

You are ignoring the reason we have CRLs in the first place: stapled
OCSP assumes all devices are globally connected and so can get OCSP.

Furthermore, neither naming nor OCSP/CRLs were involved in this
research, although the complexity may have lead to corners being cut
in the rest of the code.

> We're going to need CT for DNSSEC.

Well, you're assuming that all implementations will agree on DNSSEC
validity. Even if they do, DANE connects to the X509 ecosystem. This
raises the problem of validating the parts between the TLS connection
and the link to DANE.

> then we can land wherever on the PKI..web-of-trust..ad-hoc spectrum the

Enrollment and accounts are secondary to making sure everyone agrees
on what a valid certificate looks like. If you don't have that, you
can't trust the results of authentication. This research analyzed
server certificates only. It didn't have user certificates to play
with. Furthermore, if X509 implementors  got this wrong, how do we get
it right?

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 5 Apr 2014 11:14:50 +0200

> results seem to all be unavailable at the moment, but that should be

I have a copy of that corpus.  But you might also want to look at
https://scans.io/

Kurt

---

From: Nico Williams <[email-masked]>
Date: Sat, 5 Apr 2014 16:01:02 -0500

> OCSP assumes all devices are globally connected and so can get OCSP.

This is the off-line infrastructure argument.

If you have the same freshness policy for CRLs and [stapled] OCSP then
you have the same on-line/off-line trade-off but with the on-line
infrastructure access burden moved from the RP's shoulders to the
presenter's.

In terms of mechanics, stapled OCSP Response validation is simpler than
CRL checking, and its operational characteristics are *much* better
(just ask the DoD).

> research, although the complexity may have lead to corners being cut

What TLS/PKIX libraries have historically implemented naming constraints
correctly, or at all?

Naming constraint usage and enforcement are critical for PKI, so that a
CA compromise in -say- the Netherlands doesn't affect anyone outside its
purview.

With DNS the naming constraints were always there, so DNSSEC gets them
for free.

OTOH, DNS is lousy for representing some types of names -- IP addresses,
for example.  But for the things we desperately need strong security
for, namely server/service names, DNS is perfect.

DNS is perfect for host/domain naming because it's what won for
host/domain naming, so it's what we all use for host/domain naming.
x.400/500-style naming was a horrible, useless mess from day one, and
we're still stuck with x.500-style naming for TLS server certs, with
kludgy conventions layered on top.

The research you linked didn't deal with naming.  That doesn't mean
naming isn't a problem for PKI.  You asked, I answered :)

> validity. Even if they do, DANE connects to the X509 ecosystem. This

I'm not sure what you mean by "agree on DNSSEC validity".  If you mean
"agree to place high value on DNSSEC", no, I'm not assuming that.

Still, assuming that [we have any significant reliance on DNSSEC (and
why wouldn't we for at least some things)] for Internet security,
doesn't it stand to reason that, being a PKI, DNSSEC will need to
address transparency?

Even if we don't replace the TLS server PKI with DANE... generic PKI
problems -as opposed to x.509/PKIX-specific ones- will surely apply to
DNSSEC.

> raises the problem of validating the parts between the TLS connection

Hmm?  What are the problems here?  DANE specifies this "link" in detail.

And if DANE "certificate usage 3" cuts out the PKIX world almost
completely.

> on what a valid certificate looks like. If you don't have that, you

Certificate validation is a sine qua non for PKI, no doubt, at least for
_servers_/_services_.  For users it's different since you might just do
TOFU enrollment and only match on public keys (or the public key of a
user's private "root CA").

Therefore, and considering the extremely low penetration of PKI for user
authentication in TLS, I think certificate validation is not really all
that relevant to the user authentication side of things.  Depending on
how one chooses to use PK (not necessarily I) for user authentication,
certificate validation can be a separable [non-]problem.

One could publish user name/public key pairings in the DNS[SEC] and
enroll user accounts in domains which then act as CAs/IdPs, in which
case "certificate validation" becomes relevant again.  But in any case,
account/device enrollment is a big deal if you want to use PK for user
authentication in a scalable and reusable way.

> can't trust the results of authentication. This research analyzed

Why do you assume that PKI is the only way to use PK?

> with. Furthermore, if X509 implementors  got this wrong, how do we get

By simplifying.  I'm not saying DNS is simple, but the ugly parts of it
are not really relevant to the cryptographic security side of things,
while the ugly parts of PKIX are (see above).  In particular DNS naming
is trivial, and so are name constraint expression and checking.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 5 Apr 2014 16:37:14 -0500

> [...]

Er, no, it did deal with naming.  Search for "name constraint"; it's
mentioned quite a few times.  Several TLS libraries don't implement PKIX
name constraints at all.  Embarrassing.

I'd say that a PKI with no name constraints is just not hierarchical, it
can only be logically flat (ignoring local policy), which then results
in a lot of the problems that we've seen with the TLS server PKI.

It'd be extremely difficult to not apply DNSSEC's equivalent of name
constraints!

Nico
--

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 7 Apr 2014 15:06:15 +0000

You are comparing apples and oranges - OCSP responses covering one or a few certificates vs. CRLs covering hundreds of thousands.  If you select a given number of subscribers per status structure, CRLs are more efficient than OCSP.  Alternately, if you select a given data structure size (4K, 16K, 64K), the number of subscribers covered by a CRL of that size is larger than the number covered by the same sized OCSP response, because the CRL uses a more efficient encoding.

The same server-vs-client fetch options apply to CRLs as OCSP.  However, only CRLs support delta coding, which saves significant bandwidth for bulk transfers (as a server validating many clients would need).

OCSP validation is not simpler, it simply uses a more verbose representation of the same information.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Saturday, April 05, 2014 5:01 PM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [TLS] Certificate validation can of worms

On Fri, Apr 04, 2014 at 10:15:39PM -0700, Watson Ladd wrote:
> > - stapled OCSP is how it should have been from day one -- CRLs add a 
> > ton of complexity
> 

If you have the same freshness policy for CRLs and [stapled] OCSP then you have the same on-line/off-line trade-off but with the on-line infrastructure access burden moved from the RP's shoulders to the presenter's.

In terms of mechanics, stapled OCSP Response validation is simpler than CRL checking, and its operational characteristics are *much* better (just ask the DoD).

-------------------------

---

From: [email-masked] (Martin Rex)
Date: Mon, 7 Apr 2014 22:23:18 +0200 (CEST)

> not tested, because it doesn't validate certificates.

That paper seems to contain a few flawed assumptions
on what characteristics is to be expected from implementations of
X.509 or PKIX, and on which specific checks a TLS client is supposed
to do.

As much as some may dislike this, the extendedKeyUsage in an end entity
certificate is completely irrelevant for TLS (rfc2246/rfc4346/rfc5246)
as well as HTTP-over-TLS (rfc2818).   I don't know whether there currently
exists _any_ X-over-TLS protocol specification that addresses EKU.

There seem to be very few protocols that specify requirements for the EKU
value in the end entity cert (such as OCSP: rfc2560 & bis) and timestamps
(rfc3161).

Similar for certificate policies and policy constraints.  They're completely
irrelevant for any X-over-TLS, and it would be unwise to assume that they
are not simply ignored.

Implementing name constraints (other than Distinguished Name) is
a mere option.  The usage of a subjectAltName name constraint alone
(i.e. without a Distinguished name name constraints to go with it)
as depicted in Fig. 1 can be a security problem for CRL checking
because any CRL signer whose certificate can be verified under the same
trust anchor is specified to be an acceptable CRL signer.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 7 Apr 2014 22:31:31 +0200 (CEST)

> name constraints at all.  Embarrassing.

This is not embarrassing at all.
Name constraints are *OPTIONAL* to implement.

What is embarrassing is an implementation of PKI & CA software that will
happily created cert chains with bogus name constraints in them.

A while ago I had been given a certificate chain with a huge amounts
of name constraints in them.  Some of the name constraints were bogus
(syntactically invalid), and there was a set of name constraints included
for which no public specification of the subjectAltName (otherName),
let alone the definition of name constraints format and processing for
that proprietary nametype.  

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Apr 2014 20:57:51 +0000

While I am still reading the cited paper , the EKU if present should be very relevant.  The client should reject the server certificate if server authentication or anhyExtendedKeyUsage is not present.  Similarly, certificate policies and policy constrains extensions should be processed by the client and if the require explicit policy state variable get turned on and the path is not valid for some policy, it must be rejected.  Finally, name constraint is very relevant.  The certificate must be rejected if any of the name forms in a certificate in the path violate name constraint state variable values at that point in the path.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, April 07, 2014 4:23 PM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [TLS] Certificate validation can of worms

> not tested, because it doesn't validate certificates.

That paper seems to contain a few flawed assumptions on what characteristics is to be expected from implementations of
X.509 or PKIX, and on which specific checks a TLS client is supposed to do.

As much as some may dislike this, the extendedKeyUsage in an end entity certificate is completely irrelevant for TLS (rfc2246/rfc4346/rfc5246)
as well as HTTP-over-TLS (rfc2818).   I don't know whether there currently
exists _any_ X-over-TLS protocol specification that addresses EKU.

There seem to be very few protocols that specify requirements for the EKU value in the end entity cert (such as OCSP: rfc2560 & bis) and timestamps (rfc3161).

Similar for certificate policies and policy constraints.  They're completely irrelevant for any X-over-TLS, and it would be unwise to assume that they are not simply ignored.

Implementing name constraints (other than Distinguished Name) is a mere option.  The usage of a subjectAltName name constraint alone (i.e. without a Distinguished name name constraints to go with it) as depicted in Fig. 1 can be a security problem for CRL checking because any CRL signer whose certificate can be verified under the same trust anchor is specified to be an acceptable CRL signer.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 7 Apr 2014 23:30:51 +0200 (CEST)

Santosh Chokhani wrote:
>
> While I am still reading the cited paper , the EKU if present should be
> very relevant.  The client should reject the server certificate if server
> authentication or anhyExtendedKeyUsage is not present.

There is *NO* such requirement (to look at EKU) anywhere in rfc5246
and rfc2818.  The EKU processing within the PKIX certificate path validation
applies only to path certificates, not to the leaf certificate (because the
certificate path validation is context-free, i.e. independent of the
actual usage of the certificate.

KeyUsage is different, processing KeyUsage is explicitly described in
rfc2246/rfc4346/rfc5246.

Did you notice that the id-kp-serverAuth that is defined in rfc5280
is strictly limited to HTTP-over-TLS anyway, so would not apply to
XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou.

>
> Similarly, certificate policies and policy constrains extensions should
> be processed by the client and if the require explicit policy state
> variable get turned on and the path is not valid for some policy,
> it must be rejected.

PolicyOIDs are completely meaningless for HTTP-over-TLS.
Is there *ANY* X-over-TLS specification that gives a meaning 
to any policy OIDs?

>
> Finally, name constraint is very relevant.

name constraints will be missing from a PKIX minimum requirements RP.
And considering how broken the _definitions_ are, and how broken
some of the CA software is that is creating them, simply ignoring
name constraints seems like the only sane behaviour.

>
> The certificate must be rejected if any of the name forms in a
> certificate in the path violate name constraint state variable
> values at that point in the path.

name constraints are a HUGE mess.  PKIX does not really describe
their processing at all, and neither gives an indication that when
*ANY* name constraints are used that name constraints on distinguished
names will have to be used as well, otherwise creating security problems
for the permissible CRL signer logic.

When looking at how X.509 describes processing of name constraints in
the example section, you may realize that it talks about iteratively
trying to build certification pathes and checking whether name constraints
work from them.  Ooops.  building a certification path is declared out
of scope by rfc5280, so logically, this spills the baby with the bathtub
and makes name constraints in PKIX/rfc5280 optional in its entirety,
because something that needs a feature that has been explicitly declared
out of scope can never be a mandatory part of the spec.

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Mon, 07 Apr 2014 23:03:14 +0100

On 07/04/14 22:30, Martin Rex wrote:
<snip>
> actual usage of the certificate.

Martin, how about RFC6125?

"Representation and Verification of Domain-Based Application Service
  Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
      Certificates in the Context of Transport Layer Security (TLS)
...
1.4.  Applicability

    This document does not supersede the rules for certificate issuance
    or validation provided in [PKIX].  Therefore, [PKIX] is authoritative
    on any point that might also be discussed in this document.
    Furthermore, [PKIX] also governs any certificate-related topic on
    which this document is silent, including but not limited to
    certificate syntax, certificate extensions such as name constraints
    and extended key usage, and handling of certification paths."

<snip>
> XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou.

You mean the "-- TLS WWW server authentication" comment in section 
4.2.1.12?  Or something else?

Would you be happier if "WWW " wasn't in that comment?

> Is there *ANY* X-over-TLS specification that gives a meaning

Yes.  The CA/Browser Forum EV SSL Guidelines and Baseline Requirements.

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: [email-masked] (Martin Rex)
Date: Tue, 8 Apr 2014 00:43:29 +0200 (CEST)

Rob Stradling wrote:
> Martin Rex wrote:

I do not see any specific requirements listed in the quoted paragraph
(not even a MAY).   PKIX deals with the black box called "certificate
path validation" (within which EKU-processing is defined), and with
requirements for "conforming CAs" which issue X.509v3 certs (of which
there seem to exist very few, if any, considering how much junk
X.509v3 certificates are floating around.

Could it be that GoDaddy is issuing Server certs that aren't valid ASN.1 DER ?

Their ASN.1 DER encoder doesn't seen to implement "BOOLEAN DEFAULT FALSE"
correctly:

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

> Would you be happier if "WWW " wasn't in that comment?

This isn't about happiness.  If this OID has any meaning at all, then this
limitation "TLS WWW server authentication" will be an integral part of it.

An implementation of TLS will be looking here:
  http://tools.ietf.org/html/rfc2246#page-38
when checking KeyUsage of the Server Certificate, and *NOT* in PKIX.

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.

> Yes.  The CA/Browser Forum EV SSL Guidelines and Baseline Requirements.

Ah--yes, the fancy Gui/chrome thingy for EV/OV/DV certs.
programmatic clients don't look at CAB Forum baseline requirements
(except maybe when looking for excuses to give to unhappy customers).

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Mon, 7 Apr 2014 18:20:59 -0700

>      pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

Well, are they? Short of a hex dump of a GoDaddy certificate+chapter and
verse of X509 I don't know how we are supposed to evaluate your claim.

> 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. Instead you have to have
separate trust roots, and the whole thing becomes a giant mess for people
with lots of different keys to keep track of. (Imagine the janitor at a
large institution and his key ring. Now imagine that if he uses the wrong
key on a door, everything breaks. The poor sob isn't going to last long I'm
afraid).

It's particularly bad when you want to have a distributed agent-based
authentication and authorization system. You end up needing Kerberos, which
has a central server.

> (except maybe when looking for excuses to give to unhappy customers).

Remind me what svn is used for again? Oh right, it downloads the FreeBSD
ports tree. And what does the ports tree have? SHA256 hashes of all
software in the ports tree used for checking authenticity of mirrored
files. I can't imagine lacking necessary validation of certificates could
possibly go wrong there.

Now, Colin Percival developed a better way involving signed tarballs. I
don't know how MacPorts does it. I know Apple signs its updates, and most
people have realized that this is the way to go. (Especially given that you
can sign on a hardened machine.) But you still have the problem of needing
a PKI capable of expressing the policy you want to express.

Sincerely,

Watson Ladd

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 08 Apr 2014 10:06:58 +0200

On Mon, 2014-04-07 at 18:20 -0700, Watson Ladd wrote:

> 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.

regards,
Nikos

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Apr 2014 09:39:11 -0400

> 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/

---

From: Watson Ladd <[email-masked]>
Date: Tue, 8 Apr 2014 09:05:26 -0700

> extension as about half a billion deployed devices don't support name

?? Flame was a MD5 collision. Nothing saves you from that one.

> constraints need not be marked critical.

Which makes them useless: the point of name constraints is that I can
issue a name constrained certificate without issuing a global
intermediate CA certificate. If the extension is not marked critical,
then I've issued a global intermediate CA certificate for those who
don't check it, and so need to be just as strict as if it was an
intermediate CA certificate, so I might as well not bother with the
constraint.

> in charge of global PKI is not exactly a sound proposition.

No, this one is IETF. The spec for ECDSA in DNSSEC is only from 2012.
As a result there wasn't an alternative when the root zone was being
signed. Furthermore, changing the root key is an interesting exercise.

Sincerely,
Watson Ladd

---

From: [email-masked] (Martin Rex)
Date: Tue, 8 Apr 2014 19:06:10 +0200 (CEST)

Watson Ladd wrote:
> "Martin Rex" <[email-masked]> wrote:
>>
>>                     PKIX deals with the black box called "certificate

openssl asn1dump for Server cert from https://www.verisign.com/

 1087:d=4  hl=2 l=   9 cons: SEQUENCE
 1089:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
 1094:d=5  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000

openssl asn1dump for Server cert from https://www.godaddy.com/

  784:d=4  hl=2 l=  15 cons: SEQUENCE
  786:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
  791:d=5  hl=2 l=   1 prim: BOOLEAN           :255
  794:d=5  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:3003010100
  801:d=4  hl=2 l=  29 cons: SEQUENCE
  803:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Extended Key Usage
  808:d=5  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:301406082B060105050703
0106082B06010505070302

The godaddy ASN.1 DER encoding problem might be specific to the
BasicConstraints extension.  The criticality Boolean is correctly
omitted in their non-critical ExtendedKeyUsage encoding, but
not within the BasicConstraints extension.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 8 Apr 2014 18:40:36 +0000

Martin,

There are several misunderstandings on your part.

The EKU is generally only applies to the leaf certificate (per X.509 and RFC 5280) and is not involved in path processing.  I would think that if EKU is present at least a browser application will ensure that the certificate has server auth OID.

While TLS applications may or may not be able to set policies, the interactions among policy related extensions and path validation state machine can make the path invalid if the policy intersection is null and the require explicit policy flag has been turned on.

Path building need not be tied to path validation.  That is your choice.  Name constraints for the hierarchical name form types are not a mess as you say.  5280 and X.509 are pretty clear on how to implement them and I know of and have been involved in a few successful implementations.

I see lot of misunderstandings and exaggerations about problems in X.509 and RFC 5280 and folks with incorrect implementations having an axe to grind. 

Our time is better spent in implementing a well-designed RFC properly, addressing issues it has as opposed to justifying poor implementations.

We have enough problems implementing good specs.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, April 07, 2014 5:31 PM
To: Santosh Chokhani
Cc: [email-masked]; Watson Ladd; [email-masked]
Subject: Re: [TLS] Certificate validation can of worms

Santosh Chokhani wrote:
>
> While I am still reading the cited paper , the EKU if present should 
> be very relevant.  The client should reject the server certificate if 
> server authentication or anhyExtendedKeyUsage is not present.

There is *NO* such requirement (to look at EKU) anywhere in rfc5246 and rfc2818.  The EKU processing within the PKIX certificate path validation applies only to path certificates, not to the leaf certificate (because the certificate path validation is context-free, i.e. independent of the actual usage of the certificate.

KeyUsage is different, processing KeyUsage is explicitly described in rfc2246/rfc4346/rfc5246.

Did you notice that the id-kp-serverAuth that is defined in rfc5280 is strictly limited to HTTP-over-TLS anyway, so would not apply to XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou.

>
> Similarly, certificate policies and policy constrains extensions 
> should be processed by the client and if the require explicit policy 
> state variable get turned on and the path is not valid for some 
> policy, it must be rejected.

PolicyOIDs are completely meaningless for HTTP-over-TLS.
Is there *ANY* X-over-TLS specification that gives a meaning to any policy OIDs?

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 8 Apr 2014 14:06:47 -0500

On Tue, Apr 8, 2014 at 1:40 PM, Santosh Chokhani <[email-masked]> wrote:

I agree with what you say, but there is one area where I think name
constraints could be improved: when a certificate has no
subjectAlternativeNames, or only directoryNames when it does, and
those names are RFC6125-style, then if the CA certs in the validation
path have dNSName name constraints then those should be applied to the
CN RDNs of the subjectName and/or dirname SANs that bear the
domainnames.  To my knowledge this isn't codified, but correct me if
I'm wrong.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Tue, 8 Apr 2014 21:33:11 +0200 (CEST)

Santosh Chokhani wrote:
> 
> The EKU is generally only applies to the leaf certificate
> (per X.509 and RFC 5280) and is not involved in path processing.

EKU applies *ONLY* to higher layer protocols where the higher layer
protocol specifies behaviour for a list of EKUs.  For TLS,
such specification simply do not exist.

Potentially, there is something in the CABrowser Forum Baseline
requirements.  But I'm not a Browser implementor, so I don't know
and don't care.  I'm a maintainer of a TLS library and application
level wrapper to TLS for programmatic use.

> 
> While TLS applications may or may not be able to set policies,
> the interactions among policy related extensions and path validation
> state machine can make the path invalid if the policy intersection
> is null and the require explicit policy flag has been turned on.

Aside from what the CABForum & Browser folks may have defined to
create fancy GUI chrome, I'm not currently aware of any X-over-TLS
spec that gives meaning to policies.  So the easiest approach is
to entirely ignore them -- during path validation as well as
on the end entity certs.

> 
> Path building need not be tied to path validation.  That is your choice.
> Name constraints for the hierarchical name form types are not a mess
> as you say.

To me, the idea behind X.509 11/2008 Appendix G.3.3 looks like a
pretty big mess, and it requires an iterative approach of building
a certification path, failing, building an alternative path and succeeding,
and this is where the whole name constraints processing becomes out of
scope of PKIX/rfc5280.

> 
> I see lot of misunderstandings and exaggerations about problems in X.509
> and RFC 5280 and folks with incorrect implementations having an axe to grind. 

I see a huge amount of needless complexity

A while ago I had an inquiry from a governmental customer because our
library rejected their "pretty" certificate chains on the TLS server cert.
They had a critical policy constraints extension in one of their
path CA certs

  https://tools.ietf.org/html/rfc5280#section-4.2.1.11

with the field "inhibitPolicyMapping" present(!)

To me, this particular extension looks like a pretty stupid design flaw.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 8 Apr 2014 22:41:50 +0200 (CEST)

Santosh Chokhani wrote:
> 
> The EKU is generally only applies to the leaf certificate (per X.509
> and RFC 5280) and is not involved in path processing.
> I would think that if EKU is present at least a browser application
> will ensure that the certificate has server auth OID.

There is one central statement in rfc5280/PKIX that you seem to be
unaware of:

https://tools.ietf.org/html/rfc5280#section-6.1

   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.

Whit this  "this profile RECOMMENDS against including such checks"
says explicitly to an TLS implementor: you SHOULD NOT implement any
conformance checks to stuff that is described in section 4 & 5 of
this document.  (so you do not have to read, let alone understand
what all the stuff in that part of the document means).

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Apr 2014 20:41:07 -0400

> ?? Flame was a MD5 collision. Nothing saves you from that one.

Had name constraints been deployable and deployed, the Microsoft CA
that the NSA attacked could have been locked down to mitigate the
consequences of a breach.

> intermediate CA certificate, so I might as well not bother with the

Again, you don't get the idea that redundant controls have value. Even
though I have full control over the signing key for a sub-ca, there is
no reason for the sub-ca to have the power to issue any cert so why
grant it?

Least privilege is a powerful tool. The IETF had no business telling
people they couldn't use it.

You have no idea what my requirements or constraints are. So why
presume to tell us what is or is not useful?

The IETF was following an outdated mode of security thinking. One that
is unfortunately very common in US government contractor circles.

A MUST is only justified when there is a serious negative consequence
from not following it. There is no serious consequence that follows
from not marking a name constraint critical in the context in which it
is now used in the industry.

The clear industry consensus is that name constraints MAY be marked as
non-critical.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Apr 2014 14:15:11 +0000

Nico,

As far as CN is concerned, assuming that the path validation engine resides in a lower layer in the software stack and services a variety of protocols and applications, it would not make sense for RFC 5280 to specify this.  But, in order to facilitate what you are saying, I am an advocate of outputting the state of the name constraints as part of Section 6.1.6 of RFC 5280.  This would consist of permitted subtrees sets and excluded subtrees sets.  This output will allow higher layer protocols and applications to perform name constraints on CN.  For example, S/MIME application can verify if the e-mail address in the CN passes name constraints.

By your second part, I assume you mean when the DN contains domainComponnent attributes.  Section 4.1.2.4 of 5280 says these are not required to be converted to DNS names.  Thus, one need not apply DNS based name constraints to such DN.  I can see when the DN has a mix of attributes this leading to problems.  It is better to provide guidance to the CAs to assert the corresponding names as DNS name as well.  BTW, anything one does in this area should be applied uniformly to the Subject DN or DN in SAN.  I also did not see the discussion of this in RFC 6125.  May be I missed it or you meant something else altogether.

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2014 3:07 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: Re: [TLS] Certificate validation can of worms

I agree with what you say, but there is one area where I think name constraints could be improved: when a certificate has no subjectAlternativeNames, or only directoryNames when it does, and those names are RFC6125-style, then if the CA certs in the validation path have dNSName name constraints then those should be applied to the CN RDNs of the subjectName and/or dirname SANs that bear the domainnames.  To my knowledge this isn't codified, but correct me if I'm wrong.

Nico
--

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Apr 2014 15:26:36 +0000

Martin,

You are misreading this.  This is talking about things such as must be critical.  For example, 5280 requires some extensions to be critical.  Some of the path validation software was checking if the extension was marked critical or not and then was throwing an error if not marked critical.  There is no need for that.  CA has already produced an object.  The consumer understands the extension and should go ahead and process it.  CA having not set it critical does not and should not make a difference.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2014 4:42 PM
To: Santosh Chokhani
Cc: [email-masked]; Watson Ladd; [email-masked]
Subject: Re: [TLS] Certificate validation can of worms

> will ensure that the certificate has server auth OID.

There is one central statement in rfc5280/PKIX that you seem to be unaware of:

Whit this  "this profile RECOMMENDS against including such checks"
says explicitly to an TLS implementor: you SHOULD NOT implement any conformance checks to stuff that is described in section 4 & 5 of this document.  (so you do not have to read, let alone understand what all the stuff in that part of the document means).

-Martin