PKP is a footgun. Deploying it without being prepared for the
situations you've described is ill-advised.  There's a few options
available for organizations who want to pin, in increasing order of

Enforce Certificate Transparency. You're not locked into any CA or
key, only that the certificate has been published publicly.

Pin to a CA or a couple of CAs - this reduces the
operational/availability risk while increasing the security risk.
(Although still a reduction from the entire set of CAs of course.)

Pin to leaf *keys*, as you suggest, and ensure that they cannot all be
compromised at once through the use of offline storage and careful key
mangement. Use the keys to get certificates when needed. As you note,
if you can't manage these keys securely and separately, you need to go
to something less sophisticated, like pinning to CAs.

Pin to a locally managed trust anchor, and operate a root CA oneself,
managing it as one would a public CA (offline root, possibly offline
intermediates, etc)


On Tue, 13 Aug 2019 at 15:12, Nuno Ponte via dev-security-policy
<> wrote:
> Dear m.d.s.p.,
> I would like to bring into discussion the use of certificate/public key 
> pinning and the impacts on the 5-days period for certificate revocation 
> according to BR §
> Recently, we (Multicert) had to rollout a general certificate replacement due 
> to the serial number entropy issue. Some of the most troubled cases to 
> replace the certificates were customers doing certificate pinning on mobile 
> apps. Changing the certificate in these cases required configuration changes 
> in the code base, rebuild app, QA testing, submission to App stores, call for 
> expedited review of each App store, wait for review to be completed and only 
> then the new app version is made available for installation by end users 
> (which is turn are required to update the app the soonest).
> Meeting the 5-days deadline with this sort of process is “challenging”, at 
> best.
> A first approach is to move from certificate pinning to public key pinning 
> (PKP). This prevents the need to update the app in many of the certificate 
> replacement operations, where the public key is reused and the certificate 
> can be replaced transparently to the app (generically, an “User Agent” doing 
> PKP).
> However, in the event of a serious security incident that requires re-key 
> (such as key compromise), the certificate must be revoked in less than 24 
> hours (for the benefit of everyone – subscriber, relying parties, issuing CA, 
> etc). It’s virtually impossible to release a new app version within this 
> timeframe. And this, I think, make a very strong point against the use of PKI.
> On the other side, PKP is a simple yet powerful and effective technique to 
> protect against MITM and other attacks. It seems to be widely used in apps 
> with advanced threat models (mobile banking, sensitive personal information, 
> etc) and there are many frameworks available (including native support in 
> Android via Network Security Configuration [1]).
> There are several possible mitigation actions, such as pinning more than one 
> public key to have more than one certificate to quickly rollover in case of a 
> revocation. Even then, it is very likely that all the redundant key pairs 
> were generated and maintained by the same systems and procedures, and thus 
> all of them will become effectively compromised.
> Ultimately, it may become common practice that 1) PKP frameworks are set to 
> bypass revocation checks or 2) PKP is done with private certificates 
> (homemade, self-signed, managed ad-hoc with no CRL/OCSP services). Does any 
> of this leads to a safer Internet?
> I don’t expect this thread to end up into an absolute conclusion advocating 
> for or against, but opening it to discussion and contributions may help to 
> document possible strategies, mitigations, alternatives, pros & cons, and 
> hopefully provide guidance for an educated decision.
> Best regards,
> Nuno Ponte
> Multicert SA
> [1]
> _______________________________________________
> dev-security-policy mailing list
dev-security-policy mailing list

Reply via email to