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

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

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

> 
> > 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"
> 
> 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).
> 
> > 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.
> 
> Aha, I see your point now. Thanks for explaining it in more detail.
> 
> > 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.
> 
> Yes, point taken.
> 
> > 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,
> 
> 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
> > 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.
> 
> > 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.
> 
> 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/