[x500standard] Re: Trust anchor information
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Mon, 7 Apr 2014 16:05:53 +0200
Hi Denis,
You bring up number of issues that needs more attention. I will save you
message in my archive of things to be done, although it is getting pretty
long.
Kind regards,
Erik
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of
DP-Security-Consulting
Sent: Monday, April 07, 2014 3:16 PM
To: x500standard@xxxxxxxxxxxxx
Subject: [x500standard] Re: Trust anchor information
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>
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of
DP-Security-Consulting
Sent: Monday, April 07, 2014 10:00 AM
To: x500standard@xxxxxxxxxxxxx <mailto: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:
