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

[Peter Saint-Andre <[e-mail]>]

On 10/6/10 1:57 PM, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Peter Saint-Andre
>> [mailto:[e-mail]] Sent: Wednesday, October 06, 2010 10:08
>> AM To: [e-mail] Cc: Jim Schaad; [e-mail];
>> [e-mail] Subject: Re: [certid] section 4.6 rewrite (aka: Bad
>> certificate handling)
>> 
>> On 10/5/10 11:47 AM, Martin Rex wrote:
>>> 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,
>> 
>> 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.

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/