Re: [saag] On PKI vs. Pinning (SAAG 108 preview)

[Viktor Dukhovni <[e-mail]>]

On Tue, Jul 28, 2020 at 12:13:31PM -0700, Benjamin Kaduk wrote:

> Is there benefit in arranging for a description of the system where
> the ability to pin is just a degenerate case of a PKI, with a single
> trust anchor and no real hierarchy?

FWIW, I should mention that the DANE support in OpenSSL (since 1.1.0) is
really just support for verifying a certificate chain against a list of
EE and/or TA pins.  The pins need not come from DNS, and DNSSEC is not
required to use the "DANE" in OpenSSL.  How the application obtains the
pin values is not OpenSSL's concern.

The PKIX-TA and PKIX-EE pins are second factors, while the DANE-TA
and DANE-EE pins are bypass verification via the usual root CA
store, and use only the pins to validate the chain.

Thus, for example, in Postfix the following all use the same underlying
"DANE" (really general-purpose pinning) API.

    - The "fingerprint" security level that verifies the peer
      against a static locally configured list of acceptable
      certificate or public key fingerprints.

    - The "secure" level with a local per-destination "tafile",
      which pins acceptable (possibly intermediate) issuer
      certificates or public keys.  The chain must be signed
      by an issuer that matches one of the pins.

    - The "dane" level, where the "pins" take the form of
      dynamically obtained DNSSEC-validated TLSA records,
      which can be a mixture of EE and TA pins.

So if an OpenSSL application wants to implement pinning that
either replaces or augments WebPKI validation, the code is
already there in OpenSSL, in the form of support for "DANE",
but perhaps it is not correctly "marketed".  It is a really
a fairly general framework for validating certificate chains
against a list of "pins" ("OR" rather than "AND" semantics,
success when any *one* of the pins works out).

-- 
    Viktor.