Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: Martin Rex [mailto:[e-mail]]
> Sent: Thursday, September 30, 2010 2:15 PM
> To: Jim Schaad
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)
> 
> Jim Schaad wrote:
> >
> > If there is only one possible certification path then there is no
> > difference between caching just the EE certificate and caching the
> > entire chain.  However in the event that multiple certificate paths
> > are possible there may be a difference in behavior.
> 
> Nope, not for what is specified in server-id-check.
> 
> At most, the client would have to memorize along with the server cert
whether
> regular certificate path validation worked for this cached cert.
> Any changes to the path (above the server cert) will either make the cert
path
> validation fail or be security-irrelevant--entirely without caching and
> comparing chain certs above the cached/pinned server cert.

There is no need to remember that path validation has passed or failed - by
definition it has passed or you would never even get here.  The document
does not "permit" the case of using a certificate if path validation has
failed.

> 
> When the caching/pinning of the server certs is done for untrusted server
certs,
> then the trust relationship is defined only based on the server cert and
> certificate path validation can not be performed due to a lack of trust,
so the
> chain certs above the server cert are again irrelevant.

This document makes absolutely no statements about ever doing anything
positive with untrusted certificates.  If the certificate is untrusted -
i.e. fails path validation -- then all bets are off and the document does
not apply in any way.  After all if you don't trust the certificate why
would you believe anything that the certificate says about the identity that
is associated with the certificate.  This is a complete non-issue for the
document.

> 
> >
> > It is possible that you would trust a specific trust anchor (or
> > intermediate CA) to be more specific about getting things correct
> > (sooner or later).
> 
> There may be a slight difference for advanced users, but only at the point
> where they visualize and confirm the exception, not when doing further
> connects to the same target and have the server cert cached/pinned.

And the reason for having this is exactly because the advance user may be
looking at the chain of certificates when doing the conformation of the
exception.   They may make a different decision if a different path is
provided for making the decision.

> 
> 
> >
> > There may be differences in extensions which exist in the intermediate
> > certificates which might lead to slightly different behavior in how
> > the EE certificates are treated.
> 
> The existing server-id-check does _not_ specify any matching on chain
certs.
> As described above, changes that affect the outcome of the certificate
path
> validation, the difference in behaviour of the existing code in "fails
path
> validation", "passes path validation"
> is perfectly sufficient -- as long as the app client memorizes that the
> cached/pinned server cert originally passed certificate path validation
and
> repeats certificate path validation on future connects.
> 
> If the client app wants to _entirely_ skip certificate path validation on
the
> pinned/cached server cert, then a changed cert path would not be detected
> when only the server cert is compared.  But I have two observations about
this:
> (a) a malicious server in posession of the original server cert and
matching
> private key can easily send the original cert chain and pass your app
clients
> test, so security-wise, the client does _NOT_ get any security benefit
from
> caching and comparing the entire chain.  By not performing a certificate
path
> validation, the client misses cert revocations, and some folks might not
like this.

This behavior is not covered in the document.  The document assumes in all
locations that a successful path validation has been completed on the
certificate.

> 
> Pinning server certs protects you from attackers that manage to get a cert
> issued from any of the CAs operating under any of your (pre-)trusted
roots.
> Performing certificate path validation even for "pinned" certs protects
you
> from missing revocations.

Remember this only discussing the case of being unable to complete the logic
dealing with comparing the reference and the presented names.  This is not
dealing any cases where path validation either fails or is not performed.
Thus the idea of pinning a certificate that passes (or does not pass
validation) is not part of the concepts we are discussing here.

> 
> 
> 
> -Martin