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

[Martin Rex <[e-mail]>]

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.

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.

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


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

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.



-Martin