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 _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
