An MTC CA has both a trust anchor ID and an X.509 name, so it could use either trust_anchors or certificate_authorities, in principle.
However, both the standalone and landmark-relative form of the certificate have the same issuer name. But while a certificate_authorities match is broadly sufficient for the standalone certificate, it's not sufficient for the landmark-relative certificate. That needs a finer-grained trust anchor match (the landmark itself).
Possible fixes here:
- Say that landmark-relative and standalone certificate have different issuer names in the X.509 representation. Put the landmark number in the landmark-relative certificate's issuer.
- Say that authenticating parties somehow know to ignore
certificate_authorities for the landmark-relative certificate, but the standalone certificate can match.
- Say that authenticating parties somehow know to never match
certificate_authorities to an MTC, landmark-relative or standalone
- Say that relying parties never send an MTC CA's X.509 name in
certificate_authorities, only trust_anchors.
(1) seems natural in that it restores an X.509 invariant around certificate matching. But it breaks a different X.509 invariant. Certificates are revoked and referenced via (issuer, serial) tuples, but we want the two certificates to be revoked together.
(2) requires that TLS server software distinguish the two forms. While they could either parse out the certificate, or we introduce a new certificate property, this seems needlessly fiddly.
(3) is less fiddly, but does mean "this credential requires some kind of issuer match" and "this credential requires specifically a trust_anchors match" are now different settings on the credential, and different certificate properties. (Our stack currently uses the same setting, but it should be easy to split them.)
At that point, if they never apply to MTCs, we may as well do (4), since the relying party necessarily needs to know it's offering MTCs anyway.
An MTC CA has both a trust anchor ID and an X.509 name, so it could use either
trust_anchorsorcertificate_authorities, in principle.However, both the standalone and landmark-relative form of the certificate have the same issuer name. But while a
certificate_authoritiesmatch is broadly sufficient for the standalone certificate, it's not sufficient for the landmark-relative certificate. That needs a finer-grained trust anchor match (the landmark itself).Possible fixes here:
certificate_authoritiesfor the landmark-relative certificate, but the standalone certificate can match.certificate_authoritiesto an MTC, landmark-relative or standalonecertificate_authorities, onlytrust_anchors.(1) seems natural in that it restores an X.509 invariant around certificate matching. But it breaks a different X.509 invariant. Certificates are revoked and referenced via (issuer, serial) tuples, but we want the two certificates to be revoked together.
(2) requires that TLS server software distinguish the two forms. While they could either parse out the certificate, or we introduce a new certificate property, this seems needlessly fiddly.
(3) is less fiddly, but does mean "this credential requires some kind of issuer match" and "this credential requires specifically a
trust_anchorsmatch" are now different settings on the credential, and different certificate properties. (Our stack currently uses the same setting, but it should be easy to split them.)At that point, if they never apply to MTCs, we may as well do (4), since the relying party necessarily needs to know it's offering MTCs anyway.