Subject: [keyassure] what PKIX is not

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jan 2011 17:59:13 -0500

I've seen several references to PKIX in the context of TLS that 
suggest some confusion.

It appears that some folks believe that the trust anchor (TA) 
management model that browsers have adopted is somehow a PKIX-based 
requirement. That is not true. Browser vendors have adopted a TA 
model that is generally compliant with what X.509 and PKIX require, 
but neither X.509 nor PKIX mandate that model. So, for example, if 
DANE defines a way to distribute TAs via the DNS, that will not 
conflict with PKIX standards.

The checks used to validate a TA are not specified in the core PKIX 
specs. (We do have other standards the define ways to deliver and 
validate TA material, but they are not the only game in town, e.g., 
see the SIDR WG spec on how to do this.)  Section 6.1.1 of RFC 5280 
says that the TA info used to validate a cert path includes

          (1)  the trusted issuer name,

          (2)  the trusted public key algorithm,

          (3)  the trusted public key, and

          (4)  optionally, the trusted public key parameters associated
               with the public key.

So, if DANE defines a way to populate items 1-3 (and, optionally 4) 
from data acquired from the DNS, it can satisfy the 5280 requirements 
for a TA.  This could be dine via a self-signed cert, or even using a 
raw key. It's up to DANE to decide what checks it imposes on the data 
it retrieves from the DNS before using that data to validate an EE 
cert for a TLS server, for example.

If DANE decides that it will use a raw key from the DNS directly in a 
TLS handshake, for example, then it moves outside the PKIX/X.509 
realm, as no certs are being validated.  DANE would then need to 
decide what, if any, constraints it would impose of how the key is 
used, e.g., matched to the DNS name for a server.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Jan 2011 07:56:02 -0800

Thank you very much for this! It helps move the discussion forwards.

On 1/17/11 2:59 PM, Stephen Kent wrote:
> I've seen several references to PKIX in the context of TLS that suggest
> some confusion.
>
> It appears that some folks believe that the trust anchor (TA) management
> model that browsers have adopted is somehow a PKIX-based requirement.
> That is not true. Browser vendors have adopted a TA model that is
> generally compliant with what X.509 and PKIX require, but neither X.509
> nor PKIX mandate that model. So, for example, if DANE defines a way to
> distribute TAs via the DNS, that will not conflict with PKIX standards.

We currently don't talk in the document about the certificate 
association made by TLSA types 3 and 4 as being temporary trust anchors, 
but if we did so, it might clear up any confusion that people have about 
the relationship between TLSA and PKIX.

> validate TA material, but they are not the only game in town, e.g., see
> the SIDR WG spec on how to do this.) Section 6.1.1 of RFC 5280 says that
> the TA info used to validate a cert path includes
>
> So, if DANE defines a way to populate items 1-3 (and, optionally 4) from
> data acquired from the DNS, it can satisfy the 5280 requirements for a
> TA. This could be dine via a self-signed cert, or even using a raw key.
> It's up to DANE to decide what checks it imposes on the data it
> retrieves from the DNS before using that data to validate an EE cert for
> a TLS server, for example.

We can clear this up for types 3 and 4 by saying that the trust anchors 
gotten from TLSA act as full trust anchors for the client for the life 
of the TTL of the TLSA RR.

> TLS handshake, for example, then it moves outside the PKIX/X.509 realm,
> as no certs are being validated. DANE would then need to decide what, if
> any, constraints it would impose of how the key is used, e.g., matched
> to the DNS name for a server.

Exactly. We could clear up types 1 and 2 by not calling them 
certificates but instead binary blobs that are compared against the 
first binary blob in the TLS "Certificate" structure. That way, if there 
is later a standards-track update to TLS to allow OpenPGP certs or bare 
keys or whatnot, TLSA will already work with those.