New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 915369 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 899086



Sign in to add a comment

Path building should exclude candidates with the same (Subject + SPKI)

Project Member Reported by rsleevi@chromium.org, Dec 14

Issue description

Right now, CertIssuersIter won't add new discovered issuers if the new certificate is present in the current certificate path. It does this by comparing the DER-encoded certificates in the current chain with those newly-discovered issuer certificates, and if they're a match, won't add.

This logic is at https://cs.chromium.org/chromium/src/net/cert/internal/path_builder.cc?l=203&rcl=146f80904172432a90a2a8843e8ccc13a9928773

Rather than comparing based on full certificate, we should be comparing based on the (Subject + SPKI) tuple. That's because we should never see the same (Subject + SPKI) tuple duplicated in the current chain, as it would mean we've built a longer chain where the second instance would have sufficed as a shorter chain.

This is covered at greater length in https://tools.ietf.org/html/rfc4158#section-2.4.2 to explain the reason for that.

A similar issue was recently discussed in the context of Go - https://github.com/golang/go/issues/29233
 
The check at https://cs.chromium.org/chromium/src/net/cert/internal/path_builder.cc?l=203&rcl=146f80904172432a90a2a8843e8ccc13a9928773 is for the list of possible issuers to consider for a single cert. We only want to do exact-match deduplication there, since we want to consider different paths with the same subject+spki.

At 
https://cs.chromium.org/chromium/src/net/cert/internal/path_builder.cc?l=447&rcl=d4c1a926a9185194779ca8c26768e85c00954ab7 is where it is checked for duplicate certs within the whole chain, and that does use (subject+san+spki) for deduplication.

There still is a possibility of DOS by using certs with different SPKI, since we don't check the signatures until validating the whole chain. agl made a CL with a general limit on the number of iterations: https://chromium-review.googlesource.com/c/chromium/src/+/1377309
Status: WontFix (was: Untriaged)
Oh, thanks! I missed that logic. It was the context of AGL's CL that got me looking at this and thinking about it.

In that case, I'm going to mark this as WontFix and apologize for the noise. Not checking during path building is definitely consistent with https://tools.ietf.org/html/rfc4158#section-3.2 , and the only other consideration might be https://tools.ietf.org/html/rfc4158#section-3.5.6

Sign in to add a comment