Subject: [pkix] Trust anchors

From: "Erik Andersen" <[email-masked]>
Date: Thu, 14 Jul 2011 18:44:55 +0200

To prove I am an optimist, I have produced a first draft for a subclause on
trust anchors to be included in X.509.

I will appreciate any constructive comment.  

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik

---

From: [email-masked]
Date: Fri, 15 Jul 2011 11:40:55 +0200

Erik,

You are walking on a field of mines. Nevertheless, it is good to have a 
ball rolling.

Since, I don't like the proposal, I will explain shortly why and will 
attach a counter proposal.

The first sentence is meaningless for me: "A trust anchor is an entity 
that is trusted by 
a certificate-using system supporting a relying party". 

The second sentence introduces the concept of "trust anchor store". 
This concept originally introduced in the PKIX WG is too restrictive.

I do know that several vendors have adopted a model where all CA are 
equally trusted, 
but this is far too restrictive and this should not be the general rule.

Trust anchors may be grouped under a set of rules usually called a 
"validation policy" or a "signature policy". 
In a given set of rules there are trust anchors and, for each trust 
anchor, conditions that shall apply to every certificate of a to-be-tested 

certification path that ends to that trust anchor, like OIDs for 
certification policies, key usages, etc ...

Trust anchors cannot be  be simply grouped in "trust anchor stores", since 
different constraints may apply to every trust anchor.

This is the reason why I have deleted the text related to the"trust anchor 
store".

Denis

De :    "Erik Andersen" <[email-masked]>
A :     "PKIX" <[email-masked]>
Date :  14/07/2011 18:46
Objet : [pkix] Trust anchors
Envoyé par :    [email-masked]

To prove I am an optimist, I have produced a first draft for a subclause 
on trust anchors to be included in X.509.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
 [pièce jointe "trust-anchor.pdf" supprimée par Denis PINKAS/FR/BULL] 
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 15 Jul 2011 15:22:05 +0200

Hi Denis,

Thanks for your comments. I understand that you believe that trust anchor
storage shall not be mentioned in X.509 at all.

X.509 is not that well structured, as it has been written by different
people at different times during a period where concepts and terms were
being developed.

As an example, the term trust anchor is used with any previous introduction.
An innocent reader does not necessarily know what a trust anchor is.
Following your proposal, the term trust anchor would still be used without
any introduction.

The proposed subclause is intended to be just before a subclause introducing
the concept of certification path. Some of your proposed text fits nicely in
here.

It was important to me to emphasise that a trust anchor is some trusted
entity by a relying party and not necessarily trusted by the end-entity. 

New player from new countries are coming into the PKI area. X.509 should be
written in such a way that it is understandable for newcomers. Many PKI
specifications can only be understood by those that are already (so-called)
expert.

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

 <http://www.x500.eu/> http://www.x500.eu/

 <http://www.x500standard.com/> http://www.x500standard.com/

Fra: [email-masked] [mailto:[email-masked]] 
Sendt: 15. juli 2011 11:41
Til: Erik Andersen
Cc: PKIX
Emne: RE: [pkix] Trust anchors

Erik, 

You are walking on a field of mines. Nevertheless, it is good to have a ball
rolling. 

Since, I don't like the proposal, I will explain shortly why and will attach
a counter proposal. 

The first sentence is meaningless for me: "A trust anchor is an entity that
is trusted by 
a certificate-using system supporting a relying party". 

I do know that several vendors have adopted a model where all CA are equally
trusted, 
but this is far too restrictive and this should not be the general rule. 

Trust anchors may be grouped under a set of rules usually called a
"validation policy" or a "signature policy". 
In a given set of rules there are trust anchors and, for each trust anchor,
conditions that shall apply to every certificate of a to-be-tested 
certification path that ends to that trust anchor, like OIDs for
certification policies, key usages, etc ... 

Denis 

  _____  

  
Erik Andersen 
Andersen's L-Service 
Elsevej 48, 
DK-3500 Vaerloese 
Denmark 
Mobile: +45 2097 1490 
e-amail: [email-masked] 
Skype: andersen-erik 
 <http://www.x500.eu/> http://www.x500.eu/ 
 <http://www.x500standard.com/> http://www.x500standard.com/ 
 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik 
 [pièce jointe "trust-anchor.pdf" supprimée par Denis PINKAS/FR/BULL]
_______________________________________________
pkix mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Jul 2011 07:36:26 -0700

On Jul 14, 2011, at 9:44 AM, Erik Andersen wrote:

> To prove I am an optimist, I have produced a first draft for a subclause on trust anchors to be included in X.509.

Errr, why are we discussing changes to the X.509 spec on this list? That should be done in the ITU following the ITU's rules, it seems. 

--Paul Hoffman

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 15 Jul 2011 16:57:52 +0200

X.509 is also an ISO/IEC standard (ISO/IEC 9594-8), so currently we are
following mostly the ISO/IEC rules. We are currently in a ballot process.
Very few people participate in the official ballot process. It is important
the input to the ballot process is the result of consensus among experts. It
is the intension that the result of the discussions will be part of the
ITU-T comments into the ISO/IEC ballot process, so we are following the
rules.

I have felt that we should not update X.509 without consulting all
interesting parties. Those not interested can just stay out of the
discussion.

It could interested to know whether other than Paul has this negative
attitude.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Paul Hoffman [mailto:[email-masked]] 
Sendt: 15. juli 2011 16:36
Til: Erik Andersen
Cc: PKIX
Emne: Re: [pkix] Trust anchors

Errr, why are we discussing changes to the X.509 spec on this list? That
should be done in the ITU following the ITU's rules, it seems. 

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Jul 2011 08:26:49 -0700

> It could interested to know whether other than Paul has this negative

The "negative attitude" is based on long experience with SDOs such as ITU-T bristling when they think that the IETF is infringing on their territory. Starting a discussion for ITU-T work in an IETF WG could easily be considered such infringement. Thus, my comment about the discussion happening under ITU-T rules. I have no idea if ISO/IEC is either allowed to start new X.509 work, and if they are, if they are allowed to do so in an IETF WG. That is something for the SDO's various liaisons to discuss, not us.

--Paul Hoffman

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 15 Jul 2011 17:44:58 +0200

We are not actually proposing new work for X.509, but is primarily concerned
with making the text consistent and up-to-date with the current thinking.

I have been in the business so long that I am little tired of competition
between different groups, where we should cooperate and benefit from each
other experiences to get good and non-diverged specifications. 

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Paul Hoffman [mailto:[email-masked]] 
Sendt: 15. juli 2011 17:27
Til: Erik Andersen
Cc: 'PKIX'
Emne: Re: SV: [pkix] Trust anchors

> It could interested to know whether other than Paul has this negative

The "negative attitude" is based on long experience with SDOs such as ITU-T
bristling when they think that the IETF is infringing on their territory.
Starting a discussion for ITU-T work in an IETF WG could easily be
considered such infringement. Thus, my comment about the discussion
happening under ITU-T rules. I have no idea if ISO/IEC is either allowed to
start new X.509 work, and if they are, if they are allowed to do so in an
IETF WG. That is something for the SDO's various liaisons to discuss, not
us.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Jul 2011 09:03:57 -0700

> with making the text consistent and up-to-date with the current thinking.

The first part of that sentence doesn't match with the second.

> other experiences to get good and non-diverged specifications. 

Fully, fully agree. PKIX vs. X.509 is a stellar example of how silly the competition can be.

--Paul Hoffman

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 15 Jul 2011 15:44:15 -0400

Erik Andersen wrote:
> As an example, the term trust anchor is used with[out] any previous 
> introduction. An innocent reader does not necessarily know what a trust 
> anchor is.

Your text nicely addresses this issue. It is clear, concise, and not 
misleading to me: obviously, a trust anchor store may include additional 
information so that is is used according to a local signature validation 
policy.

 From someone ever climbing the learning curve with respect to applied 
PK crypto.

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: Stephen Kent <[email-masked]>
Date: Sat, 16 Jul 2011 10:15:39 -0400

Erik,

Thanks for the heads up. Since PKIX tries to maintain alignment with the
X.509 base standard, I think it is appropriate for you to raise this 
question on the PKIX list.

As I noted in my reply to Martin, I have long been in favor of 
including the data that may be associated with a trust anchor, and 
which can be expressed in a cert (e.g., extensions), as part of the 
path validation process. (Sharon Boyen can attest to my views in this 
regard, from several years ago.) This does not translate into 
including a TA in a cert path wrt transmission.

Steve