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

["Matt Cooper" <mcooper@xxxxxxxxxxxx>]

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

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] 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 
> PKIs with different assurance levels.

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!)

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

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 
> unintentionally lowers the assurance level.

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.

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

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 
> obtainable.  Suggest deleting trusted root cert from this discussion.

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!