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

[Martin Rex <[e-mail]>]

Jim Schaad wrote:
>
> Martin Rex wrote: 
> > 
> >  (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.

Thanks! I was asking for removal of the reference to path validation from
that one paragraph:

PeterSA wrote:
>
>                                    then the client MUST verify that
>    the presented certificate is the same as the cached certificate,
>    including verification of the entire certification path.

So the "including verification of the entire certification path"
should be completely removed, and the "cached certificate"
ought to be clarified to mean memorized "CERT-ID" reference identifier
to make it clearly distinct from anything related to TLS session caching.

Jim Schaad wrote:
>
> Martin Rex wrote:
> > 
> >  (1) lack of rationale why the cert chain should be cached
> >      rather than only the server certificate
> > 
> > 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).
> 
> 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 your example, which admittedly I have difficulty understanding,
I firmly believe the use of the term "cached server cert (chain)"
is throroughly underspecified in server-id-check and should be
fixed and all existing references to "certificate path validation"
should be removed.


The concept of "caching" implies to shortcut or skip operations and
rely on previous results of the same operation (e.g. network round-trips,
network bandwidth, computational overhead like PK-crypto-operations
or other resource-intensive operations such as OCSP-requests or
CRL-downloads&checking).

The TLS protocol contains a feature called "TLS session caching",
and when used, it normally "saves" not only the PK-crypto-operations
for the TLS key exchange (which may be a single PK-crypto operation
for each peer for RSA ciphersuites), but also the entire certificate path
validation (which usually involves several PK-crypto-operations plus
OCSP-requests and CRL-downloads with third parties).

As specified in all existing TLS protocol specs, last sentence of
section 1, the interpretation of peer certificates is entirely up
to the calling application on top of TLS.  It is also completely
up to the application to decide whether to abort a TLS handshake
when PKIX certificate path validation can not be performed for
the peer certificate due to a lack of trust.

server-id-check is an operation that is performed after
the TLS handshake has completed, and the peer certificate
can be obtained from the TLS stack, independent of whether
the TLS session was resumed from the cache (and certificate
path validation skipped) or a full TLS handshake was perfomed.

"Pinning" of the server certificate means, that server-id-check
is substituted with a comparison of the server's end-entity cert,
like a "CERT-ID" reference identifier.  The "pinned" server cert
must be memorized by the application "somewhere", along with the
meta-information for which hostname / reference-identifier the
pinning applies and whether PKIX cert validation succeeded
on this certificate.  There is no security problem with allowing
CERT-ID matching for certificate chains for which no certificate
path validation can be performed due to a lack of trust.

This is what this paragraph of rfc-2818 is about:

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

A users decision to "pin" a server cert may involve consideration
of chain certificates in case that PKIX certificate path validation
succeeded.  But memorizing anything besides the server cert will *NOT*
provide any security benefit for future automated server endpoint
identifications and is unnecessary.


If the server-id-check document wants to define a CERT-ID reference
identifier and use the term "caching", is should use it in a fashion
that there is no confusion with the TLS session caching and that
the PKIX certificate path validation usually performed by TLS
on behalf of the calling app (but only during full TLS handshakes)
is independent from application-level server-id-check, independent
of whether DNS-ID, URL-ID, SRV-ID, CN-ID or CERT-ID is used.


One should be very careful about the use of the term "caching"
in server-id-check so that there is no confusion with anything
from the TLS session caching.  For server-id-check "caching" applies
only to the decision to use the server end-entity cert as the
reference identifier ("CERT-ID") for a specific target, instead
of deriving reference identifiers such as DNS-ID, URL-ID or CN-ID
from the target's hostname that was used to establish the
communication channel.  This decision could be a result of
user-interaction or result of a configuration to that effect.


Btw. I would be extremely careful about visualizing chain certificates
to Joe Average user for a chain that failed certificate path validation
because it is quite undefined how many checks were really skipped.
You do NOT want to have Joe Average user perform an eyeball comparison
on the cert or public key fingerprint on the top-level cert at the
end of a cert chain for which certificate path validation failed
and let him assume this makes it a successfull path validation.

Given how certificate path validation is specified by PKIX
(rfc-5280, section 6), working from the trust anchor downwards,
no signature checks, no constraints checks and not revocation
checks are performed on an untrusted chain.


-Martin