Subject: [keyassure] to validate or not to validate?

From: "Carl Wallace" <[email-masked]>
Date: Wed, 18 Aug 2010 09:10:10 -0400

In section 3, it is difficult to ascertain the relationship between the
two bullets.  The first clause of the each bullet requires the client to
determine if the TLS server's certificate is signed by a CA trusted by
the client.  This is typically done by applying "PKIX validation
checks", which are only applied in the first bullet after making this
determination.  It's not clear to me if a failed PKIX validation check
coupled with a key association match is a success case or a failure
case.  Is the intent to do full path processing with the issuer's
certificate as the end entity before deciding which option to invoke?

This may be cleaner if the key association comparison was performed
first then PKIX validation checks enforced if required by the client.  A
client could then require the extra checks in some cases but not all.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 08:02:14 -0700

At 9:10 AM -0400 8/18/10, Carl Wallace wrote:
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01CB3ED6.B0FD9F6D"
>Content-class: urn:content-classes:message
>
>In section 3, it is difficult to ascertain the relationship between the two bullets.  The first clause of the each bullet requires the client to determine if the TLS server's certificate is signed by a CA trusted by the client.  This is typically done by applying "PKIX validation checks", which are only applied in the first bullet after making this determination.  It's not clear to me if a failed PKIX validation check coupled with a key association match is a success case or a failure case.  Is the intent to do full path processing with the issuer's certificate as the end entity before deciding which option to invoke?
> 
>This may be cleaner if the key association comparison was performed first then PKIX validation checks enforced if required by the client.  A client could then require the extra checks in some cases but not all.

The current intent, which might not be reflected well in the processing is:
- If there is no DNS key association, do normal PKIX validation
- If there is one or more key associations, make sure that one of them matches the key in the server certificate
- If the server certificate looks like it is supposed to chain to a trust anchor, do the PKIX validation check and fail if it fails
- If the server certificate does not look like it is supposed to chain to a trust anchor (generally: it is self-signed or signed by a CA that is not a trust anchor), don't bother doing the PKIX validation and accept it as-is

Expressing the fourth part is where we might have tripped up. A simplification could be to only check if it is self-signed, but I think there is a real use-case for "I have a cert signed by my organization's local authority that people in my organization use as a trust anchor but probably no one else does".

--Paul Hoffman, Director
--VPN Consortium

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 18 Aug 2010 11:34:55 -0400

<snip>
> first then PKIX validation checks enforced if required by the client.
> A client could then require the extra checks in some cases but not
all.
> 
> The current intent, which might not be reflected well in the
processing
> is:
> - If there is one or more key associations, make sure that one of them
> matches the key in the server certificate
> - If the server certificate looks like it is supposed to chain to a
> trust anchor, do the PKIX validation check and fail if it fails
> - If the server certificate does not look like it is supposed to chain
> to a trust anchor (generally: it is self-signed or signed by a CA that
> is not a trust anchor), don't bother doing the PKIX validation and
> accept it as-is
> 
> Expressing the fourth part is where we might have tripped up. A
> simplification could be to only check if it is self-signed, but I
think
> there is a real use-case for "I have a cert signed by my
organization's
> local authority that people in my organization use as a trust anchor
> but probably no one else does".

It's going to be tricky to define the condition that drives selection of
one of the last two bullets.  Simply checking for self-signed is
probably the safest option.  There are lots of sites with certificates
issued by a CA that is not a trust anchor, so including a check to see
if a certificate is signed by a TA is not a good option.  

More generally, it does not seem like a good idea to allow the key
association check to circumvent the client's trust anchor store.  I may
want to operate my browser with a very limited set of (ideally
constrained) TAs in some scenarios and a broader set in other scenarios.
Having the key association check as an additional check is good.  Having
the key association check serve as the only check is also good in some
cases, but not all, hence my suggestion that PKIX enforcement be at the
client's discretion.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Aug 2010 12:26:28 -0400

I have been working on this problem for some time. The scheme I came
up with was:

1) Create a new RR for end entity cert disclosure with the following attributes:

* Digest algorithm + Digest value
* URL for retrieval of cert chain (optional)

* DNS record prefix for use in disambiguating multiple certs
associated with the same domain (optional).

2) Create an X.509v3 certificate extension for DNS path chain
validation. This takes as an attribute a prefix value.

If we are going to modify an application's use of DNS then lets not do
half measures. Lets do the job right and make the best use of DNS
features that we can. If a Web browser is going to be looking at the
DNS for keys, then lets take the time to take advantage of SRV as
well.

So lets imagine that we have a HTTP/SSL service that is served using 4
different servers. Each of which has its own certificate. This is
highly desirable regardless of the type of certificate.

The certificate can be self signed, it can be issued under a local CA
with a local trust root, it can be issued as Domain Validated or it
can even be an EV certificate.

Different relying parties may validate the same certificate along
different trust paths for different purposes. So it may be that in
some cases you would want to validate the cert along the X.509v3 path
alone, in others you would want to have the additional verification of
a DNSSEC validated path. For example, X.509v3 wildcard certificates
currently only support *.example.com. It would be nice for the subject
to be able to lock them down to specific domains.

Each server has their own key and thus their own cert. Each has a
DNSHASH extension as follows:

www1.example.com ->> DNSHASH (c1)
www2.example.com ->> DNSHASH (c2)
www3.example.com ->> DNSHASH (c3)
www4.example.com ->> DNSHASH (c4)

On the DNS side there is a round robin A record for backwards
compatibility and a series of SRV records.:

www.example.com A [10.0.0.1  10.0.0.2  10.0.0.3  10.0.0.4

_http._srv.example.com SRV 1 1 80 www1.example.com
_https._srv.example.com SRV 1 1 443 www1.example.com
_http._srv.example.com SRV 1 1 80 www2.example.com
_https._srv.example.com SRV 1 1 443 www2.example.com
_http._srv.example.com SRV 1 1 80 www3.example.com
_https._srv.example.com SRV 1 1 443 www3.example.com
_http._srv.example.com SRV 1 1 80 www4.example.com
_https._srv.example.com SRV 1 1 443 www4.example.com

www1.example.com A 10.0.0.1
www2.example.com A 10.0.0.1
www3.example.com A 10.0.0.1
www4.example.com A 10.0.0.1

_c1.example.com CERTH "h=SHA1:bd0e87ecc53c4d961ef55f3b4bb47dd06ff8c825"
_c2.example.com CERTH "h=SHA1:f55ad283945cdc4903bf8c22b04074ada5d20104"
_c3.example.com CERTH "h=SHA1:0f3ba85b555d74cfd653dabb74046220ccdc5ba1"
_c4.example.com CERTH "h=SHA1:160c9cd8877025be44c790653815b949986ebd54"

>From the relying party point of view:

1) Resolve www.example.com to obtain an A record for use with HTTP/TCP
2) Decide to use SSL
        [Will explain this in more detail in a later post]
3) Connect to the IP address with SSL
        [Require use of the domain extension]
4) Server pushes out its certificate -  Certificate specifies DNSHASH c3
5) Pull _c3.www.example.com CERTH
* Verify that CERTH specifies acceptably secure algorithm
* Verify digest value for acceptable algorithm matches cert.
* Verify the trust path on the CERTH RR.