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

From: =JeffH <[email-masked]>
Date: Wed, 29 Sep 2010 14:27:44 -0700

I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad certificate 
handling) and indeed its language needed some semi-major rewriting, which we've 
done. The entire new section "4.6 Outcome" is below.

comments?

thanks,

=JeffH

###

4.6.  Outcome

    The outcome of the checking procedure is one of the following cases.

4.6.1.  Case #1: Match Found

    If the client has found a presented identifier that matches a
    reference identifier, matching has succeeded.  In this case, the
    client MUST use the matched reference identifier as the validated
    identity of the server.

4.6.2.  Case #2: No Match Found, Cached Certificate

    If the client does not find a presented identifier matching any of
    the reference identifiers, and (a) a human user has previously
    accepted and cached a certificate for this application service during
    a previous interaction with the service or (b) a certificate has been
    cached via configuration settings, then the client MUST verify that
    the presented certificate matches the cached certificate.  If the
    presented certificate does not match the cached certificate then the
    client MUST proceed as described under Section 4.6.4.

4.6.3.  Case #3: No Match Found, No Cached Certificate

    If the client does not find a presented identifier matching any of
    the reference identifiers, and the client has not previously cached a
    certificate for this application service based on user acceptance or
    configuration, then the client MUST proceed as described under
    Section 4.6.4.

4.6.4.  Fallback

    If the client is an interactive client that is directly controlled by
    a human user, then it SHOULD inform the user of the identity mismatch
    and automatically terminate the connection with a bad certificate
    error; this behavior is preferable because it prevents users from
    inadvertently bypassing security protections in hostile situations.

       Security Note: Some interactive clients give advanced users the
       option of proceeding with acceptance and caching of the presented
       certificate despite an identity mismatch.  Although this behavior
       can be appropriate in certain specialized circumstances, in
       general it ought to be exposed only to advanced users.  Even then
       it needs to be handled with extreme caution, for example by first
       encouraging even an advanced user to terminate the connection and,
       if the advanced user chooses to proceed anyway, by forcing the
       user to view the entire certification path and only then allowing
       the user to accept the certificate (on a temporary or permanent
       basis, at the user's option).

    Otherwise, if the client is an automated application not directly
    controlled by a human user, then it SHOULD terminate the connection
    with a bad certificate error and log the error appropriately.  An
    automated application MAY provide a configuration setting that
    disables this behavior, but MUST enable the behavior by default.

###

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 Sep 2010 15:19:24 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> =JeffH
> Sent: Wednesday, September 29, 2010 2:28 PM
> To: IETF cert-based identity
> Subject: [certid] section 4.6 rewrite (aka: Bad certificate handling)
> 
> handling) and indeed its language needed some semi-major rewriting, which
> we've done. The entire new section "4.6 Outcome" is below.
> 
> comments?
> 
> thanks,
> 
> =JeffH
> 
> ###
> 
> 4.6.  Outcome
> 

There was one case in the original text here that I was expecting to be
kept.   This was the case of the chain of certificates being changed from
when it was originally presented.  Given the suggestion that the chain is
shown for advanced users (see 4.6.4) I am wondering about the fact that we
are no longer looking at anything more that the terminal certificate at this
point.

>     disables this behavior, but MUST enable the behavior by default.

I would like to see the MAY and MUST here be lower cased.  They are implied
by the SHOULD in the preceding sentence and do not need to be re-iterated.

> 
> ###
> 
> 
> 
> 
> _______________________________________________
> certid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/certid

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Sep 2010 16:39:30 -0600

> are no longer looking at anything more that the terminal certificate at this

Yes, that's important.

I think this text is a bit confusing because it uses the term "match"
for comparing the entire cached certificate against the entire presented
certificate, whereas in the rest of the document we use the term "match"
for comparing reference identifiers against presented identifiers.

Therefore I propose the following adjusted text:

   If the client does not find a presented identifier matching any of
   the reference identifiers, and (a) a human user has previously
   accepted and cached a certificate for this application service during
   a previous interaction with the service or (b) a certificate has been
   cached via configuration settings, then the client MUST verify that
   the presented certificate is the same as the cached certificate,
   including verification of the entire certification path.  If the
   presented certificate is not the same as the cached certificate then
   the client MUST proceed as described under Section 4.6.4.

> by the SHOULD in the preceding sentence and do not need to be re-iterated.

I think it might be better to delete the last sentence entirely since it
is really an implementation detail (the main point is that the client
SHOULD terminate the connection).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 Sep 2010 16:20:48 -0700

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2010 3:40 PM
> To: Jim Schaad
> Cc: '=JeffH'; 'IETF cert-based identity'
> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)
> 
> >> handling) and indeed its language needed some semi-major rewriting,
> >> which we've done. The entire new section "4.6 Outcome" is below.
> >>
> >> comments?
> >>
> >> thanks,
> >>
> >> =JeffH
> >>
> >> ###
> >>
> >> 4.6.  Outcome
> >>
> > when it was originally presented.  Given the suggestion that the chain
> > is shown for advanced users (see 4.6.4) I am wondering about the fact
> > that we are no longer looking at anything more that the terminal
> > certificate at this point.
> 
> Yes, that's important.
> 

You might change the text to be "cached a certificate with certificate path" for the text in (a) and (b)  This makes it more clear that the entire certificate path is supposed to be cached.  (This is a potentially harder thing for configuration settings as a certificate path would be required to be loaded.  But making it more explicitly is probably helpful.)

> > I would like to see the MAY and MUST here be lower cased.  They are
> > implied by the SHOULD in the preceding sentence and do not need to be re-
> iterated.
> 
> I think it might be better to delete the last sentence entirely since it is really an
> implementation detail (the main point is that the client SHOULD terminate the
> connection).
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Sep 2010 17:19:25 -0600

On 9/29/10 5:20 PM, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Peter Saint-Andre
>> [mailto:[email-masked]] Sent: Wednesday, September 29, 2010
>> 3:40 PM To: Jim Schaad Cc: '=JeffH'; 'IETF cert-based identity' 
>>>> -----Original Message----- From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf
>>> Of
>>>> =JeffH Sent: Wednesday, September 29, 2010 2:28 PM To: IETF
>>>> cert-based identity Subject: [certid] section 4.6 rewrite (aka:
>>>> Bad certificate handling)
>>>> 
>>>> I and PeterSA took a hard look at section "4.6 Outcome" (aka:
>>>> Bad
>>> certificate
>>>> handling) and indeed its language needed some semi-major
>>>> rewriting, which we've done. The entire new section "4.6
>>>> Outcome" is below.
>>>> 
>>>> comments?
>>>> 
>>>> thanks,
>>>> 
>>>> =JeffH
>>>> 
>>>> ###
>>>> 
>>>> 4.6.  Outcome
>>>> 
>>>> reference identifier, matching has succeeded.  In this case,
>>>> the client MUST use the matched reference identifier as the
>>>> validated identity of the server.
>>>> 
>>>> If the client does not find a presented identifier matching any
>>>> of the reference identifiers, and (a) a human user has
>>>> previously accepted and cached a certificate for this
>>>> application service during a previous interaction with the
>>>> service or (b) a certificate has been cached via configuration
>>>> settings, then the client MUST verify that the presented
>>>> certificate matches the cached certificate.  If the presented
>>>> certificate does not match the cached certificate then the 
>>> There was one case in the original text here that I was expecting
>>> to be kept.   This was the case of the chain of certificates
>>> being changed from when it was originally presented.  Given the
>>> suggestion that the chain is shown for advanced users (see 4.6.4)
>>> I am wondering about the fact that we are no longer looking at
>>> anything more that the terminal certificate at this point.
>> 
>> Yes, that's important.
>> 
>> I think this text is a bit confusing because it uses the term
>> "match" for comparing the entire cached certificate against the
>> entire presented certificate, whereas in the rest of the document
>> we use the term "match" for comparing reference identifiers against
>> presented identifiers.
>> 
>> accepted and cached a certificate for this application service
>> during a previous interaction with the service or (b) a certificate
>> has been cached via configuration settings, then the client MUST
>> verify that the presented certificate is the same as the cached
>> certificate, including verification of the entire certification
>> path.  If the presented certificate is not the same as the cached
>> certificate then the client MUST proceed as described under Section
>> 4.6.4.
>> 
> 
> You might change the text to be "cached a certificate with
> certificate path" for the text in (a) and (b)  This makes it more
> clear that the entire certificate path is supposed to be cached.
> (This is a potentially harder thing for configuration settings as a
> certificate path would be required to be loaded.  But making it more
> explicitly is probably helpful.)

I'm always in favor of making such things explicit. This will be fixed
in the next version -- I now have "certificate (with certificate path)"
in multiple locations of the working copy.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 29 Sep 2010 20:56:47 -0400

> done. The entire new section "4.6 Outcome" is below.

The cases of "no cached certificate" and "different cached certificate"
could probably be combined into "certificate not cached" to simplify
things.  I.e.:

###

4.6. Outcome
...
4.6.1.  Case #1: Match Found
...
4.6.2.  Case #2: No Match Found, Certificate Cached

If the client does not find a presented identifier matching any of the
reference identifiers, but the presented certificate has been designated
as acceptable for this application service (a) by a human user during a
previous interaction with the service or (b) via configuration settings,
the server identity check succeeds.  [XXX: What is the validated
identity of the server?  Should the cached certificate rather be
designated as acceptable for a reference identifier, which can be taken
as the identity of the server?]

4.6.3.  Case #3: No Match Found, Certificate Not Cached

If the client does not find a presented identifier matching any of the
reference identifiers and the presented certificate has not been
accepted as described in section 4.6.2, then the client MUST NOT
consider the certificate to include a validated identity for the
application service.  Instead, the client MUST proceed as follows. [...]

###

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 29 Sep 2010 21:10:48 -0400

> > are no longer looking at anything more that the terminal certificate at this

What is the benefit of caching the entire certification path?  What
attacks does it prevent?  Mozilla PSM only caches the end-entity
certificate, and if there is a problem with that approach, I would like
to know about it.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Sep 2010 04:32:00 +0200 (MEST)

>    the client MUST proceed as described under Section 4.6.4.

I do NOT see any reason to cache (and later compare) the entire chain
of certificates.  It is ONLY the server certificate that matters here.

What could be distinguished is what kind of override the user or the
application configuration is requesting.  Is it only an override for
the server-id-check (but otherwise a server certificate that
succeeds a regular path validation), or is it an _untrusted_ server
certificate, for which no certificate path validation can be
performed.  If it is only the former, performing regular certificate
path validation and revocation checking is sensible.  For the
latter, a certificate path validation can not be performed.

> >>        basis, at the user's option).

Similarily here, "forcing the user to view the entire certification
path" does not seem appropriate.  It is the server's certificate
that matters and which needs to be cached.  When there is a lack
of trust to the servers certificate (because it is a self-signed
cert or issued by some private CA) then the certification path
is irrelevant and can not be verified with a regular
certificate path validation for "pinned" server certs.

> > by the SHOULD in the preceding sentence and do not need to be re-iterated.

There appears to be a misunderstanding about rfc-2119 terminology
(which is not affected by case).

compare
http://www.ietf.org/mail-archive/web/ietf/current/msg59589.html

If the document wants to use the rfc-2119 terminology in lower case
typesetting for non-rfc-2119 meaning, it should explicitly say so.
Preferably, it should use different words/expressions than "must".

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 Sep 2010 22:25:24 -0700

If there is only one possible certification path then there is no difference between caching just the EE certificate and caching the entire chain.  However in the event that multiple certificate paths are possible there may be a difference in behavior.  It is possible that you would trust a specific trust anchor (or intermediate CA) to be more specific about getting things correct (sooner or later).  There may be differences in extensions which exist in the intermediate certificates which might lead to slightly different behavior in how the EE certificates are treated.  It is for these reasons that if an explicit mismatch exists then you might be more or less willing to trust the EE certificate based on a specific validation path but not on another validation path.

Jim

> From: Matt McCutchen [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2010 6:11 PM
> To: Peter Saint-Andre
> Cc: Jim Schaad; 'IETF cert-based identity'
> > > when it was originally presented.  Given the suggestion that the
> > > chain is shown for advanced users (see 4.6.4) I am wondering about
> > > the fact that we are no longer looking at anything more that the
> > > terminal certificate at this point.
> >
> > Yes, that's important.
> 
> What is the benefit of caching the entire certification path?  What attacks does
> it prevent?  Mozilla PSM only caches the end-entity certificate, and if there is a
> problem with that approach, I would like to know about it.
> 
> --
> Matt

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 Sep 2010 22:27:05 -0700

Of
> Matt McCutchen
> Sent: Wednesday, September 29, 2010 5:57 PM
> To: =JeffH
> Cc: IETF cert-based identity
things.
> I.e.:
reference
> identifiers, but the presented certificate has been designated as
acceptable for
> this application service (a) by a human user during a previous interaction
with
> the service or (b) via configuration settings, the server identity check
succeeds.
> [XXX: What is the validated identity of the server?  Should the cached
certificate
> rather be designated as acceptable for a reference identifier, which can
be
> taken as the identity of the server?]

You cannot take the presented identifier as the identity of the server as it
might contain wild cards.

> If the client does not find a presented identifier matching any of the
reference
> identifiers and the presented certificate has not been accepted as
described in
> section 4.6.2, then the client MUST NOT consider the certificate to
include a
> validated identity for the application service.  Instead, the client MUST
proceed
> as follows. [...]

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Sep 2010 23:14:52 +0200 (MEST)

Jim Schaad wrote:
> 
> If there is only one possible certification path then there is no
> difference between caching just the EE certificate and caching the
> entire chain.  However in the event that multiple certificate paths
> are possible there may be a difference in behavior.

Nope, not for what is specified in server-id-check.

At most, the client would have to memorize along with the server cert
whether regular certificate path validation worked for this cached cert.
Any changes to the path (above the server cert) will either make the
cert path validation fail or be security-irrelevant--entirely without
caching and comparing chain certs above the cached/pinned server cert.

When the caching/pinning of the server certs is done for untrusted
server certs, then the trust relationship is defined only based on
the server cert and certificate path validation can not be performed
due to a lack of trust, so the chain certs above the server cert
are again irrelevant.

>
> It is possible that you would trust a specific trust anchor (or
> intermediate CA) to be more specific about getting things correct
> (sooner or later).

There may be a slight difference for advanced users, but only at
the point where they visualize and confirm the exception, not when
doing further connects to the same target and have the server cert
cached/pinned.

>
> There may be differences in extensions which exist in the intermediate
> certificates which might lead to slightly different behavior in how the
> EE certificates are treated.

The existing server-id-check does _not_ specify any matching on
chain certs.  As described above, changes that affect the outcome
of the certificate path validation, the difference in behaviour
of the existing code in "fails path validation", "passes path validation"
is perfectly sufficient -- as long as the app client memorizes that the
cached/pinned server cert originally passed certificate path validation
and repeats certificate path validation on future connects.

If the client app wants to _entirely_ skip certificate path validation
on the pinned/cached server cert, then a changed cert path would not
be detected when only the server cert is compared.  But I have two
observations about this:  (a) a malicious server in posession of
the original server cert and matching private key can easily send
the original cert chain and pass your app clients test, so security-wise,
the client does _NOT_ get any security benefit from caching and
comparing the entire chain.  By not performing a certificate path
validation, the client misses cert revocations, and some folks
might not like this.

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.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 Sep 2010 18:49:16 -0700

> From: Martin Rex [mailto:[email-masked]]
> Sent: Thursday, September 30, 2010 2:15 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]; [email-masked]
whether
> regular certificate path validation worked for this cached cert.
> Any changes to the path (above the server cert) will either make the cert
path
> validation fail or be security-irrelevant--entirely without caching and
> comparing chain certs above the cached/pinned server cert.

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.

> 
> When the caching/pinning of the server certs is done for untrusted server
certs,
> then the trust relationship is defined only based on the server cert and
> certificate path validation can not be performed due to a lack of trust,
so the
> chain certs above the server cert are again irrelevant.

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.

> There may be a slight difference for advanced users, but only at the point
> where they visualize and confirm the exception, not when doing further
> connects to the same target and have the server cert cached/pinned.

And the reason for having this is exactly because the advance user may be
looking at the chain of certificates when doing the conformation of the
exception.   They may make a different decision if a different path is
provided for making the decision.

> > certificates which might lead to slightly different behavior in how
> > the EE certificates are treated.
> 
> The existing server-id-check does _not_ specify any matching on chain
certs.
> As described above, changes that affect the outcome of the certificate
path
> validation, the difference in behaviour of the existing code in "fails
path
> validation", "passes path validation"
and
> repeats certificate path validation on future connects.
> 
> If the client app wants to _entirely_ skip certificate path validation on
the
> pinned/cached server cert, then a changed cert path would not be detected
> when only the server cert is compared.  But I have two observations about
this:
> (a) a malicious server in posession of the original server cert and
matching
> private key can easily send the original cert chain and pass your app
clients
> test, so security-wise, the client does _NOT_ get any security benefit
from
> caching and comparing the entire chain.  By not performing a certificate
path
> validation, the client misses cert revocations, and some folks might not
like this.

This behavior is not covered in the document.  The document assumes in all
locations that a successful path validation has been completed on the
certificate.

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