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

["Alice Sturgeon" <asturgeon@xxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On
Behalf Of Peter Hesse
Sent: Friday, October 03, 2003 9:18 AM
To: ietf-pkix@xxxxxxx
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt


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                    pmhesse@xxxxxxxxxxxxxxxxxx     |
| 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