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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: Martin Rex [mailto:[e-mail]]
> Sent: Monday, October 04, 2010 12:29 PM
> To: Jim Schaad
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)
> 
> I wrote about two issues:
> 
>  (1) lack of rationale why the cert chain should be cached
>      rather than only the server certificate

Ok - I will work through a more explicit example of how I would look at
things.

I look upon section 4.6.2 (and follows) to be analogous to the user adding
an additional SAN to a certificate that states that one or more of the
reference identifiers is being bound to a certificate.  As an advanced user,
I may still wish some correct path validation to occur.

Example:

Given that I have a certificate for the web site ietf.russ.housely.org and
it changes to two different CAs - one operated by Tim Polk (a government
employee and thus containing a number of name constraints to avoid being
court marshaled and shot) and one operated by Sean Turner (those contractors
will work with anybody).  However the address of the website that I typed in
is ietf.russ.housley.org.  The reference and presented names do not match.
If the presented name was correctly in the certificate the path to the Tim
Polk CA would fail validation.  I may decide that I will accept the
certificate only if it continues to validate to the Sean Turner CA on the
assumption that he might be more on the ball about looking for such
desrepances and getting them resolved, however I might look at the
certificate in question and decide that the typo was a certificate issuing
problem (having called and gotten a SHA-512 hash from Russ) and that I will
currently accept the lack of a name match.  

Here is a circumstance where I have made the decisions of implicitly adding
the SAN based on the path used to validate the certificate.  Thus if I get a
different valid path (because maybe Sean revoked the certificate) I want to
be re-informed that the basis of my decision has been altered.

NOTE: This is not a trust decision - this is only a decision on the name
mapping issue.

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

This is from the abstract of the document in question:

"This document specifies best current practices for
   representing and verifying the identity of application services in
   such interactions."

As you see the document is about how to do name comparisons.  If you believe
a document on trust , path validation and pinning are needed I would
strongly suggest that you write such a draft.

jim

> 
> 
> 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