draft-ietf-pkix-rfc2510bis-08.txt

[Ted Hardie <hardie@qualcomm.com>]

DISCUSS.

In section 1.2.1, it defines the Personal Security Environment
as "local trusted storage", where later use seems to define
this to be the data in that local storage; see section
2.2.2.1 for an example.  Adjusting the definition seems to
be closer to the meaning of the overall document, but it
should be brought together one way or the other.

Section 1.3, item 2, says "PKI management must conform to the
other parts of this series.", but it has no pointers or references.

In section 2.4, the text says that it applies only to Root CAs,
but since a "root CA" is any CA which is "directly trusted",
how does a CA know if it is a root CA for all classes of user?
This occurs again in 3.2.5.

In section 4.5, is the statement "The CA must
respond to the request by providing...." an RFC 2119 MUST?

Appendix D takes defintions from rfc2511bis; it would
be useful to indicate which is normative in the case
of changes or updates to rfc2511bis.



Notes:

In section 1.3, what does "The use of confidentiality in PKI
management protocols must be kept to a minimum in order
to ease regulatory problems." mean?

In section 1.3, item 12, the (but, of course, not the same key!)
should have more text, as it is not that obvious to the lay reader.

On page 11, there is a list of transport protocols for conveying
the messages listed.  If these are not required, I'd leave the list
out.  If we do need to have it, it might be better to use the protocol
names rather than "www" or "e-mail".

In Notes 2., section 2.4, the text notes that the validity period of
the CA key pair must be greater than the validity period of any
certificate issued by that CA using that key pair.  It seems, however,
that the validity period of old+new must be greater than any certificate
issued by old.  Admittedly, since the validity period of new is not
known until issued,  these are functionally equivalent (since new
might be valid for a very short time), but they are different and
in some cases that might be important.

In the security section, the item discussing the security risks
of exposing a private key to the CA/RA seems a little weak,
and the target should not be to implementers, but to users
(since Implementers will not know whether an RA or CA
should be trusted to handle the material).

A forward pointer to Appendix E from the appropriate
area of the main text would be useful.