Don't treat trust anchors as certificates during path building.

Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support describing anchor constraints

BUG=634509, 410574
Committed: https://crrev.com/96739b74597dba66dce7104b3f058028950d2ce1
Cr-Commit-Position: refs/heads/master@{#411231}

[eroman, 2016-08-06 01:14:08]

eroman@chromium.org changed reviewers:
+ mattm@chromium.org

[eroman, 2016-08-06 01:22:57]

The CQ bit was checked by eroman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-06 01:23:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[eroman, 2016-08-06 01:26:29]

Description was changed from

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 (as being just an SPKI + name).

This does not yet support specifying anchor constraints (RFC 5937) on the trust
anchors.

The Cast code was previously implicitly getting anchor constraints
applied, using the extensions specified in its self-signed root
certificates. After this change that is no longer the case. (Will
follow-up on that -- it does not seem that those anchor constraints
were critical to that PKI so should be lose this temporarily).

BUG=634509
==========

to

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 (as being just an SPKI + name).

This does not yet support specifying anchor constraints (RFC 5937) on the trust
anchors -- will address that in crbug.com/635200.

The Cast code was previously getting anchor constraints
applied from extensions/policy on their self-signed root certificates. After
this change, that will no longer the case.

I will follow-up on this through crbug.com/635200, however do not believe from
their PKI that this temporary loss will be a security concern (since the
intermediates it issues are already constrained).

BUG=634509
==========

[commit-bot: I haz the power, 2016-08-06 01:37:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-06 01:37:17]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[eroman, 2016-08-08 19:56:21]

The CQ bit was checked by eroman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-08 19:57:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mattm, 2016-08-09 00:59:21]

https://codereview.chromium.org/2225493003/diff/20001/components/cast_certifi...
File components/cast_certificate/cast_crl.cc (right):

https://codereview.chromium.org/2225493003/diff/20001/components/cast_certifi...
components/cast_certificate/cast_crl.cc:174: for (const auto& cert :
result.paths[result.best_result_index]->path.certs) {
ok that this doesn't check the trust_anchor?

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/trust...
File net/cert/internal/trust_store.cc (right):

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/trust...
net/cert/internal/trust_store.cc:30: DCHECK(cert.get());
cert_

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/verif...
File net/cert/internal/verify_certificate_chain_pkits_unittest.cc (right):

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/verif...
net/cert/internal/verify_certificate_chain_pkits_unittest.cc:56: // PKITS lists
chains from trust anchor to target, VerifyCertificateChainXXX
?

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
File components/cast_certificate/cast_cert_validator.cc (right):

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
components/cast_certificate/cast_cert_validator.cc:76: auto anchor =
I think using auto for these Foo::Create calls don't meet the style guide
recommendation of only using it when the type is obvious. (See also various
chromium-dev threads about auto and smart pointers)

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
File net/cert/internal/path_builder.cc (left):

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
net/cert/internal/path_builder.cc:117:
present_issuers_.insert(root->der_cert().AsStringPiece());
Since this is removed there would be the possibility of trying to continue
building paths past the anchor if verification fails for that path (and one of
the CertIssuerSource has the anchor cert).

I think that would even be the case if the anchor is self signed.. 
eg, you'd get two failed paths:
certs=target->intermediate, trust_anchor=root
certs=target->intermediate->root, trust_anchor=root

Maybe add a test of that case? and do you think we should also have a
present_anchors_ keyed on name+SPKI and check any certs against that before
adding them to issuers_?

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
File net/cert/internal/path_builder_unittest.cc (right):

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
net/cert/internal/path_builder_unittest.cc:718: // rest of the certificate
cannot be verified).
Seems reasonable, maybe add a test where this should succeed (eg, because the
issuer of the anchor is also a trust_anchor, or because the anchor is
self-signed).

[eroman, 2016-08-09 01:37:20]

https://codereview.chromium.org/2225493003/diff/20001/components/cast_certifi...
File components/cast_certificate/cast_crl.cc (right):

https://codereview.chromium.org/2225493003/diff/20001/components/cast_certifi...
components/cast_certificate/cast_crl.cc:174: for (const auto& cert :
result.paths[result.best_result_index]->path.certs) {
On 2016/08/09 00:59:21, mattm wrote:
> ok that this doesn't check the trust_anchor?

I will make sure to raise that with cast reviewer.

There is no longer the concept of an expiration on trust anchor.

That said in this case there is a single trust anchor (cast CRL root) baked into
the browser binary. So the only meaning of expiring it would be to change it. So
at least currently I don't believe there is meaningful distinction.

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/trust...
File net/cert/internal/trust_store.cc (right):

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/trust...
net/cert/internal/trust_store.cc:30: DCHECK(cert.get());
On 2016/08/09 00:59:21, mattm wrote:
> cert_

Oops! Good spot.

I will make sure to test debug mode...

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/verif...
File net/cert/internal/verify_certificate_chain_pkits_unittest.cc (right):

https://codereview.chromium.org/2225493003/diff/20001/net/cert/internal/verif...
net/cert/internal/verify_certificate_chain_pkits_unittest.cc:56: // PKITS lists
chains from trust anchor to target, VerifyCertificateChainXXX
On 2016/08/09 00:59:21, mattm wrote:
> ?

Fixed

(Left over note, thanks for spotting).

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
File components/cast_certificate/cast_cert_validator.cc (right):

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
components/cast_certificate/cast_cert_validator.cc:76: auto anchor =
On 2016/08/09 00:59:21, mattm wrote:
> I think using auto for these Foo::Create calls don't meet the style guide
> recommendation of only using it when the type is obvious. (See also various
> chromium-dev threads about auto and smart pointers)

Done.

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
File net/cert/internal/path_builder.cc (left):

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
net/cert/internal/path_builder.cc:117:
present_issuers_.insert(root->der_cert().AsStringPiece());
On 2016/08/09 00:59:21, mattm wrote:
> Since this is removed there would be the possibility of trying to continue
> building paths past the anchor if verification fails for that path (and one of
> the CertIssuerSource has the anchor cert).
> 
> I think that would even be the case if the anchor is self signed.. 
> eg, you'd get two failed paths:
> certs=target->intermediate, trust_anchor=root
> certs=target->intermediate->root, trust_anchor=root
> 
> Maybe add a test of that case? and do you think we should also have a
> present_anchors_ keyed on name+SPKI and check any certs against that before
> adding them to issuers_?

I am not sure that limiting is needed for correctness in this case, although in
failure cases it may reduce the paths attempted.

On a related note, I wonder, is it possible for a supplemental certificate
provided to path building, that has the same name/spki as a trust anchor, to end
up making a valid path whereas the shorter version that goes up to trust anchor
fails?

I guess technically this may be possible when we expose extension points for
rejecting paths, if somehow the client prefers the path through self-signed
cert.

Hmm..

I will think more about this and add some tests as you suggested.

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
File net/cert/internal/path_builder_unittest.cc (right):

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
net/cert/internal/path_builder_unittest.cc:718: // rest of the certificate
cannot be verified).
On 2016/08/09 00:59:21, mattm wrote:
> Seems reasonable, maybe add a test where this should succeed (eg, because the
> issuer of the anchor is also a trust_anchor,

We have this case in the test "TargetIsTrustAnchor"

> or because the anchor is self-signed).

I think we have this somewhere, but I will confirm that or add an explicit test
for it and get back to you.

[eroman, 2016-08-09 01:46:13]

The CQ bit was checked by eroman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-09 01:46:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-09 02:41:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-09 02:41:22]

Dry run: This issue passed the CQ dry run.

[mattm, 2016-08-09 19:51:04]

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
File components/cast_certificate/cast_cert_validator.cc (right):

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
components/cast_certificate/cast_cert_validator.cc:76: auto anchor =
On 2016/08/09 01:37:20, eroman wrote:
> On 2016/08/09 00:59:21, mattm wrote:
> > I think using auto for these Foo::Create calls don't meet the style guide
> > recommendation of only using it when the type is obvious. (See also various
> > chromium-dev threads about auto and smart pointers)
> 
> Done.

There are a few in other files too (cast_crl.cc, cast_crl_unittest.cc,
path_builder_pkits_unittest.cc, path_builder_unittest.cc,
verify_certificate_chain_pkits_unittest.cc)

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
File net/cert/internal/path_builder.cc (left):

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
net/cert/internal/path_builder.cc:117:
present_issuers_.insert(root->der_cert().AsStringPiece());
On 2016/08/09 01:37:20, eroman wrote:
> On 2016/08/09 00:59:21, mattm wrote:
> > Since this is removed there would be the possibility of trying to continue
> > building paths past the anchor if verification fails for that path (and one
of
> > the CertIssuerSource has the anchor cert).
> > 
> > I think that would even be the case if the anchor is self signed.. 
> > eg, you'd get two failed paths:
> > certs=target->intermediate, trust_anchor=root
> > certs=target->intermediate->root, trust_anchor=root
> > 
> > Maybe add a test of that case? and do you think we should also have a
> > present_anchors_ keyed on name+SPKI and check any certs against that before
> > adding them to issuers_?
> 
> I am not sure that limiting is needed for correctness in this case, although
in
> failure cases it may reduce the paths attempted.

Yeah, I was thinking of avoiding unnecessary work and also of not returning
redundant/confusing chains in the result.

> On a related note, I wonder, is it possible for a supplemental certificate
> provided to path building, that has the same name/spki as a trust anchor, to
end
> up making a valid path whereas the shorter version that goes up to trust
anchor
> fails?
> 
> I guess technically this may be possible when we expose extension points for
> rejecting paths, if somehow the client prefers the path through self-signed
> cert.

Yeah I can't think of a way that would happen with just the 5280 rules.
 
> Hmm..
> 
> I will think more about this and add some tests as you suggested.

[eroman, 2016-08-09 22:15:52]

Description was changed from

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 (as being just an SPKI + name).

This does not yet support specifying anchor constraints (RFC 5937) on the trust
anchors -- will address that in crbug.com/635200.

The Cast code was previously getting anchor constraints
applied from extensions/policy on their self-signed root certificates. After
this change, that will no longer the case.

I will follow-up on this through crbug.com/635200, however do not believe from
their PKI that this temporary loss will be a security concern (since the
intermediates it issues are already constrained).

BUG=634509
==========

to

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties
of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support
describing anchor constraints

BUG=634509
==========

[eroman, 2016-08-09 22:16:58]

The CQ bit was checked by eroman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-09 22:17:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[eroman, 2016-08-09 23:41:19]

The CQ bit was checked by eroman@chromium.org to run a CQ dry run

[eroman, 2016-08-09 23:42:07]

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
File components/cast_certificate/cast_cert_validator.cc (right):

https://codereview.chromium.org/2225493003/diff/60001/components/cast_certifi...
components/cast_certificate/cast_cert_validator.cc:76: auto anchor =
On 2016/08/09 19:51:04, mattm wrote:
> On 2016/08/09 01:37:20, eroman wrote:
> > On 2016/08/09 00:59:21, mattm wrote:
> > > I think using auto for these Foo::Create calls don't meet the style guide
> > > recommendation of only using it when the type is obvious. (See also
various
> > > chromium-dev threads about auto and smart pointers)
> > 
> > Done.
> 
> There are a few in other files too (cast_crl.cc, cast_crl_unittest.cc,
> path_builder_pkits_unittest.cc, path_builder_unittest.cc,
> verify_certificate_chain_pkits_unittest.cc)

Done.

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
File net/cert/internal/path_builder.cc (left):

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
net/cert/internal/path_builder.cc:117:
present_issuers_.insert(root->der_cert().AsStringPiece());
On 2016/08/09 19:51:04, mattm wrote:
> On 2016/08/09 01:37:20, eroman wrote:
> > On 2016/08/09 00:59:21, mattm wrote:
> > > Since this is removed there would be the possibility of trying to continue
> > > building paths past the anchor if verification fails for that path (and
one
> of
> > > the CertIssuerSource has the anchor cert).
> > > 
> > > I think that would even be the case if the anchor is self signed.. 
> > > eg, you'd get two failed paths:
> > > certs=target->intermediate, trust_anchor=root
> > > certs=target->intermediate->root, trust_anchor=root
> > > 
> > > Maybe add a test of that case? and do you think we should also have a
> > > present_anchors_ keyed on name+SPKI and check any certs against that
before
> > > adding them to issuers_?
> > 
> > I am not sure that limiting is needed for correctness in this case, although
> in
> > failure cases it may reduce the paths attempted.
> 
> Yeah, I was thinking of avoiding unnecessary work and also of not returning
> redundant/confusing chains in the result.
> 
> > On a related note, I wonder, is it possible for a supplemental certificate
> > provided to path building, that has the same name/spki as a trust anchor, to
> end
> > up making a valid path whereas the shorter version that goes up to trust
> anchor
> > fails?
> > 
> > I guess technically this may be possible when we expose extension points for
> > rejecting paths, if somehow the client prefers the path through self-signed
> > cert.
> 
> Yeah I can't think of a way that would happen with just the 5280 rules.
>  
> > Hmm..
> > 
> > I will think more about this and add some tests as you suggested.

Thanks, I have added that as a test.

I have some concerns with adding a de-duplication on name+SPKI for the
anchor-as-supplemental-cert case, since I think that could cause some problems
and complicate the de-duping. Given that we build the shorter path first I think
it is fine to start do this expansion for now.

Are you OK with me adding a TODO and more tests, and exploring this further in a
follow-up?

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
File net/cert/internal/path_builder_unittest.cc (right):

https://codereview.chromium.org/2225493003/diff/60001/net/cert/internal/path_...
net/cert/internal/path_builder_unittest.cc:718: // rest of the certificate
cannot be verified).
On 2016/08/09 01:37:20, eroman wrote:
> On 2016/08/09 00:59:21, mattm wrote:
> > Seems reasonable, maybe add a test where this should succeed (eg, because
the
> > issuer of the anchor is also a trust_anchor,
> 
> We have this case in the test "TargetIsTrustAnchor"
> 
> > or because the anchor is self-signed).
> 
> I think we have this somewhere, but I will confirm that or add an explicit
test
> for it and get back to you.

Done. I have added some tests.

[commit-bot: I haz the power, 2016-08-09 23:42:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-10 01:49:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-10 01:49:55]

Dry run: This issue passed the CQ dry run.

[mattm, 2016-08-10 19:46:01]

lgtm

https://codereview.chromium.org/2225493003/diff/140001/net/cert/internal/path...
File net/cert/internal/path_builder_unittest.cc (right):

https://codereview.chromium.org/2225493003/diff/140001/net/cert/internal/path...
net/cert/internal/path_builder_unittest.cc:240: // but with different data).
Maybe mention that the difference here is that the target cert is in the trust
store too.

https://codereview.chromium.org/2225493003/diff/140001/net/cert/internal/path...
net/cert/internal/path_builder_unittest.cc:287: // The (exraneous) trust anchor
D(D) is supplied as a certificate, as is the
s/exraneous/extraneous

[eroman, 2016-08-10 19:57:09]

The CQ bit was checked by eroman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-10 19:57:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[eroman, 2016-08-10 20:39:04]

eroman@chromium.org changed reviewers:
+ ryanchung@chromium.org, sheretov@chromium.org

[eroman, 2016-08-10 20:39:05]

+sheretov,ryanchung for Cast review. Detailed explanation below:

There are some slight semantic changes from this CL that impact Cast's
verification. Here is my analysis of the differences based on the current
self-signed roots cast uses:

1. Cast CRL root (kCastCRLRootCaDer)
 1.1. Will no longer check for the root's expiration during verification
 1.2. Will no longer enforce pathlen=1 anchor constraint during verification

2. Cast Root (kCastRootCaDer)
 2.1. Will no longer check for the root's expiration during verification
 2.2 Will no longer enforce pathlen=2 anchor constraint during verification

3. Eureka Root (kEurekaRootCaDer)
 3.1 Will no longer check for the root's expiration during verification

I intend to add back the pathlen constraints on these trust anchors in a
follow-up CL, as part of issue 635200.

However I would like to review/submit these as independent CLs for simplicity of
review. Are you OK with that? It does mean there will be a period of time when
the above differences are in effect. My justification for why I think this is
safe to do (whether temporary or longer term):

Regarding lack of expiration check on trust anchors (1.1, 2.1, 3.1):

  * Expiration is many years in the future, so this won't be a factor right now.
  * Losing expiration on trust anchor should be safe anyway -- when these
anchors expire we would probably just remove them from the built-in trust store
anyway, which has the same effect as if they were expired.

Regarding no longer enforcing pathlen constraint on 2 of the trust anchors (1.2,
2.2):

  * From what I can tell the intermediates issued by kCastRootCaDer are always
path constrained. So losing the constraint check on trust anchor is really just
losing a safety-check for intermediates that we (incorrectly issued) that were
not pathlen constrained). (Pathlen constraints are still enforced on paths, just
from the intermediate down)

  * As for the Cast CRL authority, I am not sure our practice around this, but I
think a similar argument applies. As long as we are issuing constrained
intermediates then there is no real loss during verification (other than not
catching intermediates which were issued without a path constraint).


Are you OK with me tackling these as a follow-up? (Makes the review process
simpler as the CLs are more focused). Thanks!

https://codereview.chromium.org/2225493003/diff/140001/net/cert/internal/path...
File net/cert/internal/path_builder_unittest.cc (right):

https://codereview.chromium.org/2225493003/diff/140001/net/cert/internal/path...
net/cert/internal/path_builder_unittest.cc:240: // but with different data).
On 2016/08/10 19:46:00, mattm wrote:
> Maybe mention that the difference here is that the target cert is in the trust
> store too.

Done.

https://codereview.chromium.org/2225493003/diff/140001/net/cert/internal/path...
net/cert/internal/path_builder_unittest.cc:287: // The (exraneous) trust anchor
D(D) is supplied as a certificate, as is the
On 2016/08/10 19:46:00, mattm wrote:
> s/exraneous/extraneous

Done.

[commit-bot: I haz the power, 2016-08-10 21:22:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-10 21:22:07]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[ryanchung, 2016-08-10 21:23:18]

Thanks for the detailed explanation.
lgtm

[sheretov, 2016-08-10 21:26:59]

On 2016/08/10 21:23:18, ryanchung wrote:
> Thanks for the detailed explanation.
> lgtm

Same for me.  lgtm

[eroman, 2016-08-10 21:31:38]

Description was changed from

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties
of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support
describing anchor constraints

BUG=634509
==========

to

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties
of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support
describing anchor constraints

BUG=634509,410574
==========

[eroman, 2016-08-10 21:31:53]

The CQ bit was checked by eroman@chromium.org

[eroman, 2016-08-10 21:31:54]

The patchset sent to the CQ was uploaded after l-g-t-m from mattm@chromium.org
Link to the patchset: https://codereview.chromium.org/2225493003/#ps160001
(title: "address moar feedback")

[commit-bot: I haz the power, 2016-08-10 21:33:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-10 23:13:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-10 23:13:40]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[eroman, 2016-08-10 23:20:37]

The CQ bit was checked by eroman@chromium.org

[commit-bot: I haz the power, 2016-08-10 23:21:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-11 02:33:59]

Description was changed from

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties
of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support
describing anchor constraints

BUG=634509,410574
==========

to

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties
of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support
describing anchor constraints

BUG=634509,410574
==========

[commit-bot: I haz the power, 2016-08-11 02:34:00]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-08-11 02:35:21]

Description was changed from

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties
of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support
describing anchor constraints

BUG=634509,410574
==========

to

==========
Don't treat trust anchors as certificates during path building.

This clarifies the abstraction for trust anchors, and treats them as
described in RFC 5280 -- as being just an SPKI + name.

Previously anchors were passed around as certificates, wheres this CL:

* Introduces TrustAnchor to describe trust anchor for path validation/building
* Introduces CertPath to describe trust anchor + certificates
* TrustAnchor may optionally have an associated certificate, however properties
of that certificate are not processed during validation.
* TrustAnchor will be extended in a follow-up CL (issue 635200) to support
describing anchor constraints

BUG=634509,410574

Committed: https://crrev.com/96739b74597dba66dce7104b3f058028950d2ce1
Cr-Commit-Position: refs/heads/master@{#411231}
==========

[commit-bot: I haz the power, 2016-08-11 02:35:22]

Patchset 9 (id:??) landed as
https://crrev.com/96739b74597dba66dce7104b3f058028950d2ce1
Cr-Commit-Position: refs/heads/master@{#411231}