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

From: Martin Rex <[email-masked]>
Date: Mon, 4 Oct 2010 21:28:58 +0200 (MEST)

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 5 Oct 2010 00:19:00 -0700

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: Monday, October 04, 2010 12:29 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)
> 

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.

>      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):
> 
> This document here sensibly explains why you may want to allow server
certs
> that do not chain to pre-trusted roots:
> 
> > 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.
> 
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.
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.
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.
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

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Oct 2010 19:47:08 +0200 (MEST)

Jim Schaad wrote:
> Martin Rex wrote: 

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:
> > (and does not provide security benefit).
> 
> 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:

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Oct 2010 11:07:59 -0600

On 10/5/10 11:47 AM, Martin Rex wrote:
> should be completely removed, 

I'd be curious to see what Jim's feedback is on that point, since he
suggested the inclusion of text about the certification path.

> and the "cached certificate"

1. How about changing "cached certificate" to "stored certificate" or
"memorized certificate"? I agree that the term "caching" might be
confusing to some folks.

2. Are you suggesting that we change "cached certificate" to "stored
reference identifier"? That doesn't strike me as a helpful change
because it doesn't make clear that the client needs to keep track of
more than just the reference identifier, it needs to store an
association between the verified reference identifier (im.example.com or
whatever) and the certificate that was presented by the server it
connected to for that DNS domain name (or, at the very least, a hash of
the certificate).

> identifications and is unnecessary.

Aha, I see your point now. Thanks for explaining it in more detail.

> from the TLS session caching. 

Yes, point taken.

> For server-id-check "caching" applies
> reference identifier ("CERT-ID") for a specific target, 

In the terms of this I-D, a certificate is not a reference identifier.
The reference identifier is still a DNS-ID or whatever, it's just that
after pinning the client considers it acceptable to use as a reference
identifier a DNS domain name that was presented in the server's
certificate during a previous connection attempt and explicitly accepted
by a human user (as long as the memorized certificate doesn't change in
future connection attempts etc.).

> instead

Correct.

> and let him assume this makes it a successfull path validation.

Yes, applications need to be extremely careful about presenting anything
to Joe Average or Barry's Mother or other unsophisticated individuals.

> checks are performed on an untrusted chain.

Noted.

Peter

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 Oct 2010 12:57:27 -0700

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Wednesday, October 06, 2010 10:08 AM
> To: [email-masked]
> Cc: Jim Schaad; [email-masked]; [email-masked]
> >> 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:
> >>
> I'd be curious to see what Jim's feedback is on that point, since he suggested
> the inclusion of text about the certification path.

I don't care if you remove the word verification.  What I want to say is that the presented certificate and it's chain back to the trust anchor is the same as when it was first checked by the advanced user.   If the path has changed then the answer should be re-obtained.

4.6.2. Case #2: No Match Found, Name Association Cached

If the client does not find a presented identifier matching any of the reference identifiers, but has previously associated one of the reference identifiers with the certificate (a) by a human user during a previous interaction with this application service or (b) via configuration settings, the server identity check succeeds.  The cached name association needs to include the certificate presented and the context in which in which it was accepted.  The context includes the chain of certificates from the presented certificate to the trust anchor.

> > to make it clearly distinct from anything related to TLS session caching.

I don't any any big issues here with the word cached.  Although you might want to use "cached name association"
> "memorized certificate"? I agree that the term "caching" might be confusing to
> some folks.
> 
> 2. Are you suggesting that we change "cached certificate" to "stored reference
> identifier"? That doesn't strike me as a helpful change because it doesn't make
> clear that the client needs to keep track of more than just the reference
> identifier, it needs to store an association between the verified reference
> identifier (im.example.com or
> whatever) and the certificate that was presented by the server it connected to
> for that DNS domain name (or, at the very least, a hash of the certificate).
> 
> > Jim Schaad wrote:
> >>
> >> Martin Rex wrote:
> >>>
> >>> 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  [...]
> >
> >
> > is throroughly underspecified in server-id-check and should be fixed
> > and all existing references to "certificate path validation"
> > should be removed.
> >
> > 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
> > 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.
> >
> > A users decision to "pin" a server cert may involve consideration of
> > chain certificates in case that PKIX certificate path validation
> > 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.
> >
> > in server-id-check so that there is no confusion with anything from
> > the TLS session caching.
> 
> Yes, point taken.
> 
> The reference identifier is still a DNS-ID or whatever, it's just that after pinning
> the client considers it acceptable to use as a reference identifier a DNS domain
> name that was presented in the server's certificate during a previous
> connection attempt and explicitly accepted by a human user (as long as the
> memorized certificate doesn't change in future connection attempts etc.).
> 
> > 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.
> 
> Correct.
> 
> > to Joe Average user for a chain that failed certificate path
> > validation because it is quite undefined how many checks were really skipped.
> > 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.
> 
> Yes, applications need to be extremely careful about presenting anything to Joe
> Average or Barry's Mother or other unsophisticated individuals.
> 
> > 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.
> 
> Noted.
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Oct 2010 15:48:26 -0600

On 10/6/10 1:57 PM, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Peter Saint-Andre
>> [mailto:[email-masked]] Sent: Wednesday, October 06, 2010 10:08
>> AM To: [email-masked] Cc: Jim Schaad; [email-masked];
>> [email-masked] Subject: Re: [certid] section 4.6 rewrite (aka: Bad
>> certificate handling)
>> 
>>>> 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.
>>> 
>> I'd be curious to see what Jim's feedback is on that point, since
>> he suggested the inclusion of text about the certification path.
> 
> I don't care if you remove the word verification.  What I want to say
> is that the presented certificate and it's chain back to the trust
> anchor is the same as when it was first checked by the advanced user.
> If the path has changed then the answer should be re-obtained.
> 
> 
> If the client does not find a presented identifier matching any of
> the reference identifiers, but has previously associated one of the
> reference identifiers with the certificate (a) by a human user during
> a previous interaction with this application service or (b) via
> configuration settings, the server identity check succeeds.  The
> cached name association needs to include the certificate presented
> and the context in which in which it was accepted.  The context
> includes the chain of certificates from the presented certificate to
> the trust anchor.

That seems better. Thanks for the proposed text. Tweaked slightly in our
working copy, as follows:

   If the client does not find a presented identifier matching any of
   the reference identifiers, but has previously associated one of the
   reference identifiers with the certificate (a) because of positive
   acceptance by a human user during a previous interaction with this
   application service or (b) because of configuration settings, then
   the server identity check succeeds.  The cached name association
   needs to take account of both the certificate presented and the
   context in which it was accepted or configured (where the context
   includes the chain of certificates from the presented certificate to
   the trust anchor).

>>> 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.
> 
> I don't any any big issues here with the word cached.  Although you
> might want to use "cached name association"

Yes, I like that phrase.

Peter

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