Hi Denis, We had the discussion as to whether a trust anchor is an entity or just information many moons ago. At that time I made an analysis of the texts at the time. I have attached this old analysis. What is the term for the entity that signs the first CA-certificate in a certification path? It cannot be a trust anchor in your definition. In your term it something in a relying party trust anchor store. Such a trust anchor cannot sign anything. Many documents use the term root-CA as synonymous with trust anchor. A CA is an entity. We have also had a long discussion on a definition of root-CA. We had so many different proposals, but it was impossible to get an agreed definition. You might have your definition, but I am sure others will disagree. If trust anchor is information, the term trust anchor information makes no sense although it is used in many places. Way back in 8 October 2009 I issued a defect report 348 (see http://x500standard.com/index.php?n=Ig.DefectReports). It later becomes part off Corrigendum 3 to the fifth edition (2005 edition) and Corrigendum 1 to the sixth edition (2008). These corrigenda went through the SC6 ballot and through ITU-T last call, so X.509 has in last three editions had the following definitions: 3.5.66 trust anchor: A trust anchor is an entity that is trusted by a relying party and used for validating certificates in certification paths. 3.5.67 trust anchor information: Trust anchor information is at least the: distinguished name of the trust anchor, associated public key, algorithm identifier, public key parameters (if applicable), and any constraints on its use including a validity period. The trust anchor information may be provided as a self-signed CA-certificate or as a normal CA-certificate (i.e., cross-certificate). As to RFC 5914, I was at first reluctant to add TrustAnchorInfo when the subject was brought up by Carl Wallace. Adding just another format would be anti-standardisation I felt, but came later to the conclusion, that it could be useful. PKI is going to be used in new areas, where traditional PKI thinking is not sufficient (or even harmful). An example from smart grid: A substation within the grid has very stringent communication requirements. From an incident is detected and processed by some entity, a command is prepared to another entity, transmitted over high-speed LAN, processed and reacted by another entity max 4-10 ms may elapse. During his period the receiver has to authenticate the sender of the command. There is very little time for certification path processing, CRL or OCSP checking, etc. Anything that can speed up the process should be considered. Simplified trust anchor information is one small step, bringing trust anchor information close to the relying party is another small step. It is useful to make clear that trust anchor can act as an end-entity to sign different things, e.g. attribute certificates. You should also see my proposal for DNS name attribute as a result of this thinking allowing very compact distinguished names for entities having a domain name. I am now involved in IEC TC 57/WG 15, which is responsible for smart grid security specifications. Currently they have 11 parts completed or underway and are heavy users of PKI, but they are not exactly sure how to apply PKI. I have an obligation to defend the interests of this group within the PKI area. Attribute certificates are also interesting here for Role Based Access Control (RBAC), which appears to be an important aspect of smart grid security. I have some wild ideas about a concept called whitelisting (different from the thinking in connection with OCSP). It is resulting from a definite requirements from IEC TC 57/WG 15 , from a document out of that group (draft IEC 62351-9), from RFC 5914 and from my own twisted brain. You will probably not like that idea either. I have also many other wild ideas. Regards, Erik From: x500standard-bounce@xxxxxxxxxxxxx [mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of DP-Security-Consulting Sent: Monday, April 07, 2014 10:00 AM To: x500standard@xxxxxxxxxxxxx Subject: [x500standard] Re: Trust anchor information 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
Attachment:
trustAnchor.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
