Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)

[Martin Rex <[e-mail]>]

I wrote about two issues:

 (1) lack of rationale why the cert chain should be cached
     rather than only the server certificate

 (2) support for server certs that do not succeed certificate
     path validation to one of the (pre-)configured trust anchors


You did not provide any arguments for (1) and inappropriately
dismiss (2) for the scope of the current document.

I think that (1) is seriously underspecified.  With the existing
matching procedure, caching the entire cert chain does NOT make
any sense at all (and does not provide security benefit).


Jim Schaad wrote:
> 
> There is no need to remember that path validation has passed or failed - by
> definition it has passed or you would never even get here.  The document
> does not "permit" the case of using a certificate if path validation has
> failed.

The previous document (rfc-2818) certainly did allow arbitrary certs
and left the notion when a server cert is acceptable completely out-of-scope
(it does NOT say PKIX certificate path validation anywhere):

 http://tools.ietf.org/html/rfc2818#section-3.1

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.)

This document here sensibly explains why you may want to allow
server certs that do not chain to pre-trusted roots:

 http://www.w3.org/TR/wsc-ui/#selfsignedcerts


> 
> This document makes absolutely no statements about ever doing anything
> positive with untrusted certificates.  If the certificate is untrusted -
> i.e. fails path validation -- then all bets are off and the document does
> not apply in any way.  After all if you don't trust the certificate why
> would you believe anything that the certificate says about the identity that
> is associated with the certificate.  This is a complete non-issue for the
> document.

If this documents engages at all into discussion when a server cert is
valid/acceptable for performing server-id-check, then it should _not_
limit the scope to trust anchors preconfigured by software distributors.
The current wording about NAGGING end users when the server cert does
not map to a pre-configured trust anchor and offering the "pinning"
of server-certs to advanced users only is inappropriate for an
IETF specification.  The W3C spec is much more reasonable in that
respect.


> 
> > 
> > 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.
> 
> Remember this only discussing the case of being unable to complete the logic
> dealing with comparing the reference and the presented names.  This is not
> dealing any cases where path validation either fails or is not performed.
> Thus the idea of pinning a certificate that passes (or does not pass
> validation) is not part of the concepts we are discussing here.


The document discusses the situation of a "cached server cert", without
going into details about why the certificate was cached, what
meta-information was cached along with it (giving more context to
the decision to cache/pin the server certificate), and it talks about
how to perform server-id-check when a cached/pinned certificate
exists.

The current description is artificially limited to be applicable to
the pre-configured commercial CA trust anchors, and doesn't even
mention that it is crippled like this, and that there be other
more sensible and more secure reasons for caching/pinning certs
that require a different "override" strategy or more fine-grained
control over server certificate caching/pinning.



Pinning of EE server certs (no matter whether self-signed,
from untrusted CAs, or from "common TLS PKI") interferes with
server cert rollover.  Security-wise, pinning the server cert
(effectively pinning the servers public key) is certainly the
strongest of all because it cuts most of the points-of-failures
completely out of the loop.

A "pinning" of server certs from CA-hierarchies (trusted AND untrusted)
that allows hidden key/cert-rollover might be useful to the public at
large -- which does neither care nor understand the technical details.
There, the server-cert issuing CA cert would be pinned along with
a set of client-applied constraints like the host or DNS domain to
which this pinning applies and whether a server-id-check should
still be performed on the server cert.

Allowing organizations to run their own CAs makes IMHO a lot of
sense (and several companies are doing it already).  Having to
make every CA from some other organization a full-blown trust anchor
is just as bad as an unduly requiring for any such organizational CAs
to get signed by a pre-configured commercial trust anchor.


ISO specified the ASN.1 OIDs so that they can lease "OID arcs" on
a subscription basis to organizations for a significant recurring
premium so that they can rake in extra revenues.
Fortunately, IANA has been giving out OID arcs under SNMP private
enterprises for free, and OIDs from that OID space is used
heavily for non-SNMP purposes.  :)


The existing "TLS PKI", which, for the server identity matching keys
off the existing DNS space and DNS delegations, represents close to
zero value to the IETF community and the public at large.  From
a technical perspective, both offer comparable security, so I
can understand the motivations behind trying to move to DNSSEC-based
distribution of trust.

Technically, the existing TLS PKI scheme of matching DNS delegations
for server endpoint identification in combination with the complete
mind-block for past encounters with a peer has always been a
primitive "better-than-nothing" approach to security.
Limiting acceptable certs to those distributed by the DNS domain
admin himself though DNSSEC signed zones would give those DNS admins
some of the control back that they're entitled to have (about
assignments and use of DNS domain names), something which is
very ill-designed in the existing "TLS PKI".


-Martin