[x500standard] Re: Trust anchor information
- From: DP-Security-Consulting <dp.sec.consulting@xxxxxxx>
- To: x500standard@xxxxxxxxxxxxx
- Date: Mon, 07 Apr 2014 15:15:56 +0200
Hi Erik,
First of all, thank you for this loooong response.
The wording "Trust anchor" is also being used in RFC 5280.
RFC 2459 and the following RFCs (as well as X.509) were originally only
constructed to validate a certificate with respect to the current date
and time.
However, most people are still thinking that a CA has just being
established and so has only one public key.
Very few people were really taking care of CA key rollovers.
There is an exception in RFC 4210 in sections 6.2 and 4.1.1:
*6.2. Root CA Key Update
CA keys (as all other keys) have a finite lifetime and will have to
be updated on a periodic basis. The certificates NewWithNew,
NewWithOld, and OldWithNew (see Section 4.4.1) MAY be issued by the
CA to aid existing end entities who hold the current self-signed CA
certificate (OldWithOld) to transition securely to the new self-
signed CA certificate (NewWithNew), and to aid new end entities who
will hold NewWithNew to acquire OldWithOld securely for verification
of existing data.*
This means that, at a given time, there are at least two different
public keys that can be used to validate a certificate.
RFC 5280 and X.509 are fully silent about this aspect.
RFC 5280 states that the algorithm present in section 6 validates a
certificate with respect to the current date and time.
RFC 5280 also states: "A conforming implementation MAY also support
validation with respect to some point in the past",
but there is not the single information on how to proceed.
You claim that there is a clear difference between trust anchor and
trust anchor information.
Well, what do you think about this sentence which is included in RFC 5280:
"When the trust anchor is provided in the form of a self-signed
certificate, ..."
I am still using the 2005 edition from X.509, since I do not want to pay
for the latest, it states:
3.3.60 trust anchor: A trust anchor is a set of the following
information in addition to the public key: algorithm
identifier, public key parameters (if applicable), distinguished
name of the holder of the associated private key (i.e., the
subject CA) and optionally a validity period. The trust anchor may
be provided in the form of a self-signed certificate.
A trust anchor is trusted by a certificate using system and used for
validating certificates in certification paths.
I have no problem with this definition, but I have problem with the
defect report that was raised and accepted.
The best would be to rollback to that definition !
Once it has been demonstrated that the current wording of RFC 5280 is
simply "bad", in particular because it is ignoring the fact that a CA
has more than one key at a time,
it may be interesting to take a look at the vocabulary being used by
ETSI to perform path validations in the past, e.g. for verifying
electronic signatures
and time-stamp tokens.
ETSI documents are using the wording "trust point", instead of "trust
anchor"
and this might be the way to solve the issue by deprecating the use of
the wording "trust anchor".
When a signature policy is defined in XML, there is the following structure:
<xsd:element name="TrustPoint"
type="ds:X509CertificateType"/>
This means that ETSI only considers certificates whether they are
self-signed or not, i.e. whether at the top of a CA hierarchy or not.
We have in X.509:
8.1.5 Self-issued certificates
A certification authority may issue a certificate to itself under
three circumstances:
a) as a convenient way of encoding the public key associated with
the private key used to sign the certificate,
so that it can be communicated to, and *stored as trust anchors*
by, its certificate using systems;
It is clear that a self-issued certificate may be stored as a trust anchor.
However, the most important section of X.509 relative to this topic is
section 10.1: 10.1 Path processing inputs
The second item from the list is:
b)a trusted public key value or key identifier (if the key is stored
internally to the certification path processing module), for use in
verifying the first certificate in the certification path;
The text does not use the term trust anchor !
X.509 is currently not consistent in the few places where the term is
being used and would need to be fixed far later than simply by
attempting to modify definitions.
Anyway, IMO, the old text and the new proposed text are both "bad".
Whatever, in X.509 rather than saying:
A trust anchor has in the past been synonymous with the term root CA.
It would be better to state:
"A trust anchor has in the past been confused with the term root CA".
The co-editors of RFC 5914 are R. Housley, S. Ashmore and C. Wallace.
So I can understand why Carl would like this RFC to be referenced,
but this would add more confusions. Remember that when the third odd
format was proposed, I asked for changes but at that time the response was
that it had already be implemented and thus no change was possible.
I am still against any reference to RFC 5914 (a standard which should
have never existed on the standards track).
Denis
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
Other related posts:
