Or phrased differently, split out trust anchor constraints as separate structures during validation/path building.

Right now for convenience we treat trust anchors as just another certificate in the path, and fully process its basic constraints, expiration, key usage, etc.

(Mea culpa!)

For compatible operation we should instead treat trust anchors as in RFC 5280 -- a named SPKI with associated anchor constraints.

For more details on anchor constraints and how they apply during validation see RFC 5947.

This shouldn't change much -- we will still save a canonical certificate for trust anchors (can relax that later), however any additional constraints encoded in that certificate are not necessarily processed.

Note: The current consumer of the library, Cast, _does_ have anchor constraints, so when transitioning the API we must ensure it continues using the constraints encoded in its self-signed root certificate.
 

Or phrased differently, split out trust anchor constraints as separate structures during validation/path building.

Right now for convenience we treat trust anchors as just another certificate in the path, and fully process its basic constraints, expiration, key usage, etc.

(Mea culpa!)

For compatible operation we should instead treat trust anchors as in RFC 5280 -- a named SPKI with associated anchor constraints.

For more details on anchor constraints and how they apply during validation see RFC 5937.

This shouldn't change much -- we will still save a canonical certificate for trust anchors (can relax that later), however any additional constraints encoded in that certificate are not necessarily processed.

Note: The current consumer of the library, Cast, _does_ have anchor constraints, so when transitioning the API we must ensure it continues using the constraints encoded in its self-signed root certificate.