Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt

From: [email-masked]
Date: Thu, 02 Oct 2003 10:50:53 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure:       
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow et al.
	Filename	: draft-ietf-pkix-certpathbuild-01.txt
	Pages		: 67
	Date		: 2003-10-2
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-certpathbuild-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certpathbuild-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Peter Hesse" <[email-masked]>
Date: Fri, 3 Oct 2003 09:17:55 -0400

All,

To save everyone the trouble of trying to read through our entire
internet draft a second time, the following lists outline the main
changes made in the document since version 00.

Overall changes:
- made certain terminology more consistent ("certification 
   path" throughout the document instead of "certificate path", 
   "cert path", etc.)
- softened the tone; made it clear that the document provides 
   informational recommendations and does not prescribe a 
   particular method for certification path building
- removed statements on the document providing guidance based 
   on "best practices" but instead explicitly defined the 
   motivation and purpose behind the document, as well as the 
   criteria that led to the guidance provided. 
- removed some non-ascii characters that had snuck in

Specific changes:
- Thoroughly updated section 1.1 (Motivation) and 1.2 (Purpose)
- updated terminology section to include a few additional terms
- updated mesh PKI figure to better differentiate it from other
   structures
- included a section (2.2) that clearly identifies the authors'
   criteria for a path building implementation
- broke up section 2.4 (How to Build a Certification Path) with
   some subsections
- added section 3.3 (Representing the Decision Tree 
   Programmatically)
- updated section 3.5 to include additional information about 
   the sorting methods that follow.  Sorting methods are no 
   longer called "rules".
- added section 5.4 (Distinguished Name Encoding)
- added section 6.3 (Subject Information Access)

Cheers,

--Peter Hesse

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, October 02, 2003 10:51 AM
To: IETF-Announce:; [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pkix-certpathbuild-01.txt".

Send a message to:
	[email-masked].
In the body type:
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: "Alice Sturgeon" <[email-masked]>
Date: Tue, 21 Oct 2003 11:41:47 -0400

Hi all,
This is an important effort and it is going to be very helpful once
finalized.
A few comments (with the humble caveat that those of you who wrote this I-D,
and with whom you consulted, are considerably more knowledgeable on this
subject than I am!):

Terminology, on "certification path building" and its aka's:  How can
"building" be the same as "discovery", which would be more like the
validation process?  Also, using the verb "obtain" does not make it clear
whether it is the building (construction, development) or the discovery
(finding, validating) that is being described, although, given the subject
of the I-D, we only assume it is the former (building).  As the authors
state in Purpose, other documents, notably RFC 3280, go into cert path
validation, and so this I-D does not go there.

Terminology, on "subscriber" - You might consider stating something like:
"also referred to as 'user' or, in a certification hierarchy, 'End Entity'".
Many use "subscriber" and "user" synonymously and so it might be helpful to
clarify that (or your thinking on the two terms), and you use End Entity,
and so your view on its relationship to "subscriber" as certificate subject
would be helpful.  Stating these equivalents here would also avoid having to
do so in the later text (e.g., in 1.4, "end entities' (subscribers')" in 1st
para.).

Terminology: In view of your last two terms, you might consider trying to
define "trust" - rather critical to the whole I-D concept.  While you use
the term extensively in the Introduction, it does seem to be assumed that
the concept is understood - and it is in a general sense, but it might be
prudent to define explicitly for this context.  For example, are there well
defined security attributes that make up "trust" - confidentiality,
integrity, accountability, authenticity, or (gulp) non-repudiation?

With respect to 1.4.3 and the text on figure 4, and the two principal
concerns about vulnerability:  If the cert path building software is written
correctly, then transitive trust should be impossible.  Secondly, I would
think that cert policy mapping should prohibit the cross-certification of
PKIs with different assurance levels.

1.4.4 says:
However, when connecting PKIs in this way, the number and variety of PKIs
involved results in a non-hierarchical environment, such as the one as
depicted in Figure 5.
I don't think this is quite true, or perhaps just a simplification: The
overall environment or framework (or super-structure) is non-hierarchical,
but within that framework there is indeed a hierarchical environment.  This
is an important point, because it shows how the bridge, as non-hierarchical
framework, can simplify the one or many hierarchical structure(s) within it
for the purpose of cross-certification.

1.5 - First reason given for supporting the bridge structure is gratuitous -
Use it because it is used...  I think this point (1) detracts from point
(2), which is a much more important reason.

RFC 3280 6.2 states:  While each certification path begins with a specific
trust anchor, ...
So why is path building beginning with the trusted root called "reverse"?  I
assume this is because for cert path validation, one logically starts with
the EE cert.
So - different purposes, different terminology?

2.4.1, last sentence of 1st indented paragraph says:
"In other words, consumption of such paths by relying parties could
potentially yield trust in unintended ways."
Assuming (perhaps incorrectly) that "trust in unintended ways" means
"unintended trust", then the path actually creates a vulnerability, does it
not?
Second point also could be identified as a vulnerability, in that the path
unintentionally lowers the assurance level.

2.4 states:
"The BCA also has issued four certificates, one to each of the trust roots."
But then 2.4.2 states:
"It is not possible to build forward direction paths into the
infrastructures behind CAs W, Y, and Z, because W, Y, and Z have not been
issued certificates by any other CAs."
I'm missing something on this point.

From the References: [RFC 1738]  Berners-Lee, T., L. Masinter and M.
McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
You may wish to reference, instead or in addition, RFC 2396 URI
Berners-Lee, T., Fielding, R., Irving, U.C., and L. Masinter. "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.  RFC 2396 updates
and merges RFC 1738 (as well as "Relative Uniform Resource Locators"
[RFC1808]), although 2396 excludes the portions of RFC 1738 that define the
specific syntax of individual URL schemes.  (And you use "URI" much more
frequently than "URL".)
Are the references intended to be Normative or Informative?  I believe it is
necessary now to distinguish references now on this basis.

8. Security Considerations - In the 2nd and 3rd sentences, you state the
need to protect the trusted root cert, as well as the trusted root keys.  It
is necessary that the root cert be available for the path. It is root keys
that need to be "kept safe" and of course only the public key should be
obtainable.  Suggest deleting trusted root cert from this discussion.

Editorial notes:

Section 1, 1st para., last sentence: There should be an "s" on
"certificate".
1.4, 1st sentence, the phrase "often times" does not translate well nor may
not be as clear as, simply, "often".

1.4.4, 4th sentence (beginning with "Since each PKI...") is not a sentence:
There is one subordinate clause (beginning with "Since"), with two parts to
it (joined by "and") but no principal clause.  The sense of it is that the
next sentence should be the principal clause, but since that would make a
horribly long sentence, I would suggest simply removing the "Since" and
making that a stand-alone (and proper) sentence.

2, last sentence reads (not well):
Rather, guidance is provided on the technical issues that surround the path
building process, and the capabilities path building implementations require
in order to build certification paths successfully, irrespective of PKI
structures.
To make this easier to read (I had trouble), insert "on" before "...the
capabilities path...", and add the letter "d" to "require"
("...implementations required in order to build...")

The A's, B's, and C's in figure 6 are a little confusing.  It can be
understood but it might be easier to do so if you used a combination of
numbers and letters.

All for now.

Alice Sturgeon
Chair, Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC 1/SC 27
and
System Policy Architect & Manager Standards
SPYRUS

Office:  613-232-2350
Mobile: 613-291-0331

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Peter Hesse
Sent: Friday, October 03, 2003 9:18 AM
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt

All,

Overall changes:

Specific changes:

Cheers,

--Peter Hesse

---

From: "Matt Cooper" <[email-masked]>
Date: Tue, 21 Oct 2003 15:03:13 -0400

Hi Alice,

Thanks for the thorough reading! You made a lot of good suggestions that
will help clarify the I-D. Please see my comments below.

Best Regards,
Matt

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alice Sturgeon
 
> Terminology, on "certification path building" and its aka's:  
> How can "building" be the same as "discovery", which would be 
> more like the validation process?  Also, using the verb 
> "obtain" does not make it clear whether it is the building 
> (construction, development) or the discovery (finding, 
> validating) that is being described, although, given the 
> subject of the I-D, we only assume it is the former 
> (building).

We had a few rounds of discussion on the term to use here and settled on
building. You are correct, the focus is on constructing a likely to validate
path, not validating it. I think the connotations of each aka also vary
according to whom you ask. =) I also agree that "obtain" should be replaced
with a better verb. How about "assemble"? I think that is more in line with
what we meant.

> Terminology, on "subscriber" - You might consider stating 
> something like: "also referred to as 'user' or, in a 
> certification hierarchy, 'End Entity'". Many use "subscriber" 
> and "user" synonymously and so it might be helpful to clarify 
> that (or your thinking on the two terms), and you use End 
> Entity, and so your view on its relationship to "subscriber" 
> as certificate subject would be helpful.  Stating these 
> equivalents here would also avoid having to do so in the 
> later text (e.g., in 1.4, "end entities' (subscribers')" in 
> 1st para.).

This is tricky to dance around and I obviously didn't do too great a job!
The "End Entity" of the path is not necessarily a subscriber/user. For
example, you may be building a path for a CRL signer. Hence, I tried to
steer clear of the subscriber/user terms unless an example was specifically
citing that type of cert. I think it ended up a little messy. I will review
for this usage and see what I can do to make it more consistent.

> Terminology: In view of your last two terms, you might 
> consider trying to define "trust" - rather critical to the 
> whole I-D concept.  While you use the term extensively in the 
> Introduction, it does seem to be assumed that the concept is 
> understood - and it is in a general sense, but it might be 
> prudent to define explicitly for this context.  For example, 
> are there well defined security attributes that make up 
> "trust" - confidentiality, integrity, accountability, 
> authenticity, or (gulp) non-repudiation?

I agree, but I'm a little concerned about trying to boil down what is a
fairly broad concept as it is applied to PKI in a definition. Perhaps a to
the point definition with 3280 as suggested reading?  It may make sense for
us to explicitly point out in the introduction that that the I-D assumes the
reader understands the contents of 3280 and related documents. I'll give
this some more thought.

> With respect to 1.4.3 and the text on figure 4, and the two 
> principal concerns about vulnerability:  If the cert path 
> building software is written correctly, then transitive trust 
> should be impossible.  

It's not so much a vulnerability as a result of many cooks in the kitchen.
If I cross certify with you today, and tomorrow you cross certify with ACME
PKI, I may now trust ACME PKI without intending to. Of course, there are
ways to design the certificates to prevent this. Problem is in my mind, as
the number of variables (cross certified infrastructures) grows, it becomes
increasingly difficult to keep track of the possibilities. IMO, limiting the
number of combinations is one of the very nice properties of having a single
bridge rather than "meshing" the infrastructures.

> Secondly, I would think that cert 
> policy mapping should prohibit the cross-certification of 

Agree, it _should_. =) Again, the worry is similar what I described just
above. If I give you a cert with high assurance, and you certify a lower
assurance PKI and map the policy to it, then I have a problem without
realizing it. Or perhaps, you correctly give ACME PKI the high assurance
cert, and they in turn cross certify with a lower assurance PKI and keep the
policy intact. Again, you can control all these things to varying degrees
with name constraints, path length cons, etc., but I think we have to take
the human factor of PKI design into consideration and be somewhat realistic
with our expectations.

> 1.4.4 says:
> However, when connecting PKIs in this way, the number and 
> variety of PKIs involved results in a non-hierarchical 
> environment, such as the one as depicted in Figure 5. I don't 
> think this is quite true, or perhaps just a simplification: 
> The overall environment or framework (or super-structure) is 
> non-hierarchical, but within that framework there is indeed a 
> hierarchical environment.  This is an important point, 
> because it shows how the bridge, as non-hierarchical 
> framework, can simplify the one or many hierarchical 
> structure(s) within it for the purpose of cross-certification.

I'm not sure I'm understanding what you are saying. Are you saying we should
at this point stress that although the overall graph is non-hierarchical,
that the trust framework is still hierarchical?

> 1.5 - First reason given for supporting the bridge structure 
> is gratuitous - Use it because it is used...  I think this 
> point (1) detracts from point (2), which is a much more 
> important reason.

I agree and see no problem removing that and focusing on (2).

> RFC 3280 6.2 states:  While each certification path begins 
> with a specific trust anchor, ... So why is path building 
> beginning with the trusted root called "reverse"?  I assume 
> this is because for cert path validation, one logically 
> starts with the EE cert. So - different purposes, different 
> terminology?

I think this is throw back to prior terminology for cross certificates. The
reverse cross certificates are those issued from a CA, the forward are those
issued to the CA. If building from the EE, you use the forward, when
building from the TR, you use the reverse, hence the naming of the
respective building directions. I think, though I may start a religious
debate here, "forward" was chosen as a natural result of that being the
intended/designed direction for path building. (It certainly isn't forward
with respect to issuance!)

> "In other words, consumption of such paths by relying parties 
> could potentially yield trust in unintended ways." Assuming 
> (perhaps incorrectly) that "trust in unintended ways" means 
> "unintended trust", then the path actually creates a 
> vulnerability, does it not?

Yes, and I agree with you, but I did intentionally soft pedal that.
Basically, if everyone did everything just right, there should, in theory,
not be any unintended trust. The problem is to my mind that allowing these
unnecessarily convoluted paths increases the number of variables
exponentially; making it next to impossible for a PKI designer to consider
every possible outcome, and therefore, every possible trust path. More to
the point, I don't think the convoluted path in and of itself is a
vulnerability, but I think it creates the potential for masking a
vulnerability/unintended trust.

> Second point also could be 
> identified as a vulnerability, in that the path 

Agree to an extent as well; but this has been a topic of much debate in the
past with no clear winner. Hence the "may be considered lost" verbiage as
opposed to "is lost." I'm in the latter school of thought and I personally
would like to see this become part of path validation rather than a
recommended approach to path building. Perhaps it is time for the list to
re-visit this topic...

> 2.4 states:
> "The BCA also has issued four certificates, one to each of 
> the trust roots." But then 2.4.2 states: "It is not possible 
> to build forward direction paths into the infrastructures 
> behind CAs W, Y, and Z, because W, Y, and Z have not been 
> issued certificates by any other CAs." I'm missing something 
> on this point.

I agree this isn't clear enough and I think we should try to clarify this
point because it is an important one to my mind. The idea is, for example,
suppose I'm building a (forward) path from E to TR-X. It isn't possible for
my forward path builder to go astray and wander into the infrastructure
behind TR-W because TR-W was not issued certificates by either F or G. (The
builder would be forced to "go back" at W)  However, the same example
flipped around building (in reverse) from TR-X to E, the path builder could
wander into the infrastructure behind TR-W using the certificates issued
from TR-W to F and/or G. The reverse builder than may not recurse back until
all paths behind TR-W are exhausted.

> McCahill, "Uniform Resource Locators (URL)", RFC 1738, 
> December 1994. You may wish to reference, instead or in 
> addition, RFC 2396 URI Berners-Lee, T., Fielding, R., Irving, 
> U.C., and L. Masinter. "Uniform Resource Identifiers (URI): 
> Generic Syntax", August 1998.  RFC 2396 updates and merges 
> RFC 1738 (as well as "Relative Uniform Resource Locators" 
> [RFC1808]), although 2396 excludes the portions of RFC 1738 
> that define the specific syntax of individual URL schemes.  
> (And you use "URI" much more frequently than "URL".) Are the 
> references intended to be Normative or Informative?  I 
> believe it is necessary now to distinguish references now on 
> this basis.

You are correct; we need to update this section.

> 8. Security Considerations - In the 2nd and 3rd sentences, 
> you state the need to protect the trusted root cert, as well 
> as the trusted root keys.  It is necessary that the root cert 
> be available for the path. It is root keys that need to be 
> "kept safe" and of course only the public key should be 

I agree the key is all that matters, but wrote it this way so as to not
diminish the importance of protecting the cert if that is the source of the
key. Perhaps a re-wording would be better:

The only exception to this is the appropriate protection of the trusted root
key(s) (or trusted root certificates if they are the source of the trusted
keys) used for validating paths.

?

> Editorial notes:

Thank you for these as well; we will address these items in the next
revision.

Thanks again for your efforts!