Hi Erik, I took a look at DR 394. I have many problems !! The proposed text is worse that the current text. I will attempt to correct the current text. First of all, the first sentence:"A trust anchor is an *entity *that is trusted for the purpose of certificate validation by a relying party".
A trust anchor is NOT an entity.A trust anchor is a public key value and an algorithm identifier associated with some parameters (like a validity period) that are trusted by a relying party for the purpose of validating a signed structure. Such a signed structure may be for example:
a PKC, a CRL, an OCSP response or an Attribute certificate. Then I have problems with the Note: NOTE Trust anchor has in the past been synonymous with the term root-CA.In a strict hierarchy, the CA at the top of the hierarchy is called the root CA and it may be the trust anchor. However, in more complex environments, it may not be possible to identify a root CA. Even when it is possible to identify a root CA, a relying party may not necessarily consider it a trust anchor. An intermediate CA may instead take that role.
I would rephrase it in that way: NOTE In a CA hierarchy, *a *CA at the top of a hierarchy is called a root CA . A trust anchor has in the past been synonymous with the term root CA.A root CA is an entity whereas a trust anchor is a public key value and an algorithm identifier associated with some parameters. At a given time, a root CA has a given set of public key values and associated parameters. Subsequently, it will have another set of public key values and associated parameters. What is trusted by a relying party is a set of public key values and associated parameters for a CA (whether it is a root CA or not), but not necessarily the next set of public key values and associated parameters for that CA.
Finally I like the reference to TBSCertificate and I hate the reference to RFC 5914 since it includes .
TrustAnchorInfo ::= SEQUENCE { version TrustAnchorInfoVersion DEFAULT v1, pubKey SubjectPublicKeyInfo, keyId KeyIdentifier, taTitle TrustAnchorTitle OPTIONAL, certPath CertPathControls OPTIONAL, exts [1] EXPLICIT Extensions OPTIONAL, taTitleLangTag [2] UTF8String OPTIONAL }The reason is the following: the fundamental point is how long you can trust that public key. It is indicated in both Certificate and TBSCertificate, but not in TrustAnchorInfo. So I would deprecate the use of TrustAnchorInfo and recommend the use of TBSCertificate
in the case where Certificate cannot be used. Denis
After some useful discussions, I have prepared an update of DR_394 (see http://x500standard.com/uploads/Ig/DR_394.pdf).I have copied Q.10, as they have some interests in trust. Comments are welcome. Regards, Erik