[x500standard] Re: Defect on definition of trust anchor, etc.

  • From: "Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>
  • To: <x500standard@xxxxxxxxxxxxx>
  • Date: Wed, 23 Sep 2009 12:35:44 -0400

I absolutely agree at the conceptual level.  But as with OIDs, once one
has been assigned, its definition should not be changed.  I believe
Trust Anchor has a preponderance of evidence (after filtering out the
noise) in favor of the data definition.  (Perhaps I am influenced by
long exposure to "trust anchor management" - I manage what I can
control, such as the trust store on the devices for which I am
responsible.  I cannot manage my suppliers, I can only decide whether or
not to accept them.)

A new term, such as "Trust Anchor Organization", "Trusted Authority" or
the like, should be established to refer to the organization.

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/
> 
>      
> 

-- 
-------------------------------------------------------------
The Israeli group Breaking the Silence has just released a collection of
testimonies by Israeli soldiers that took part in the Gaza attack last
December and January. The testimonies expose significant gaps between 
the official stances of the Israeli military and events on the ground.

See  http://www.shovrimshtika.org/news_item_e.asp?id=30

The Israeli government defies Obama, and continues its settlement
expansion

Israel plans to allocate $250 million over the next two years for 
settlements

http://www.palestinecampaign.org/index7b.asp?m_id=1&l1_id=4&l2_id=24&Con
tent_ID=698

whilst simultaneously continuing to bulldoze Palestinian homes

http://salsa.democracyinaction.org/o/301/t/9462/campaign.jsp?campaign_KE
Y=27357

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxx
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site:
http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.

-----
www.x500standard.com: The central source for information on the X.500 Directory 
Standard.

Other related posts:

  1. Home
  2. x500standard
  3. Archive
  4. 09-2009