Dave
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of David Chadwick
Sent: Wednesday, September 23, 2009 11:53 AM
To: x500standard@xxxxxxxxxxxxx
Subject: [x500standard] Re: Defect on definition of trust anchor, etc.
Hi David
what we are trying to get across is that there is trust between people
and organisations, and there is trust built into software systems. Trust
Anchor is the human side of things. Relying parties trust certain
organisations and authorities to act as Trust Anchors. Trust anchor
information on the other hand is the data that is fed into software
systems in order to perform chain validation. If you agree at the
conceptual level with what we are saying then we can wordsmith the text
to fit this.
regards
David
Kemp, David P. wrote:
The proposed definition of trust anchor ("an entity that is trusted by
a
certificate using system and used for validating certificates in
certification paths") is ambiguous - is the "entity" an organization
that is trusted by the humans running the certificate-using system, or
is the "entity" a set of data stored within the certificate using
system? The word "entity" implies the former, but an "organization"
cannot be "used for validating certificates".
You might try to distinguish between "trust anchor" as the entire
stored
data object (e.g. a self-signed certificate) and "trust anchor
information" as the required subset of the trust anchor (i.e. the
portion of the stored data that is not ignored during path validation
and subsequent usage). But is it worth defining two terms just to
make
that distinction?
RFC 5280 talks in conflicting terms about trust anchors ("The trust
anchor is an input to the [path validation] algorithm.") and trust
anchor information ("describing a CA that serves as a trust anchor for
the certification path. The trust anchor information includes: ...").
This is patent nonsense - as with the proposed DR definition, a "CA"
obviously cannot be "an input to the algorithm".
The TA Management Requirements I-D is consistent with the current
X.509,
defining Trust Anchor to be the data and not attempting to name the
organization:
Trust Anchor: A trust anchor represents an authoritative entity
via
a public key and associated data. The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information for which the trust anchor is
authoritative. A relying party uses trust anchors to determine
if
a digitally signed object is valid by verifying a digital
signature using the trust anchor's public key, and by enforcing
the constraints expressed in the associated data for the trust
anchor.
Although the existing X.509 definition of Trust Anchor could be
improved, it is better than the proposed replacement. Thus I do not
agree with this defect report.
Dave Kemp
*From:* x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] *On Behalf Of *Santosh
Chokhani
*Sent:* Wednesday, September 23, 2009 9:50 AM
*To:* x500standard@xxxxxxxxxxxxx
*Subject:* [x500standard] Re: Defect on definition of trust anchor,
etc.
The current text says:
"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 constrains on its use including a
validity period. The trust anchor information may be provided in the
form of a self-signed certificate or a normal CA public-key
certificate"
I have couple of unrelated concerns regarding this. One is that we
should start encouraging forcing validity period on a trust anchor.
If
the trust anchor integrity is violated at the relying party, we got
bigger problems. If the trust anchor integrity is not violated,
validity period enforcement is a perfectly fine thing.
Another is that the ongoing work in IETF permits couple of other
formats
for trust anchors: These include a to-be-signed certificate and
another
trust anchor format that is not certificate like, albeit has many of
the
information.
Based on this, I would say the definition should be as follows:
"Trust anchor information is at least the: distinguished name of the
trust anchor, associated public key, algorithm identifier, public key
parameters (if applicable), validity period, and any constrains on its
use. The trust anchor information may be provided in the form of a
self-signed certificate, a normal CA public-key certificate, a
to-be-signed certificate, or TrustAnchorInfo as defined the TBD RFC"
------------------------------------------------------------------------
*From:* x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] *On Behalf Of *Erik
Andersen
*Sent:* Wednesday, September 23, 2009 9:31 AM
*To:* Directory list
*Subject:* [x500standard] Defect on definition of trust anchor, etc.
Hi Folks,
Please consider the attached draft DR to correct some definitions
in
X.509. This draft was produced as part of the ongoing meeting.
May we have your comments?
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@xxxxxxx
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
