[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Draft-ietf-pkix-proxy-06.txt



1. Section 3.3, para 2:  I think that the MAY in this paragrah should be
lower case.  I do not see these as a protocal statements, but as saying
these are ways that reasonable uniqueness could be obtained for a serial
number.  I assume that other methods of doing this are perfectly
allowable.

2. Section 3.4:  Does the subject name need to be "unique" among all
certificates ever issued by a proxy, or just the active certificates?

3. General:  I am still not comfortable that the issuance of Proxy
Certificates cannot be restricted (or permitted) by a CA when it issues
an EEC.  One method of doing this would be a non-critical ProxyCertInfo
extension with a pCPathLengthConstrant of 0 in the EEC.

4. Section 2.6:  When creating a new PC, where and how is the
negotiations on policy language and policy done?  Should this be
documented as a separate step in the text describing how PCs are
obtained/issued?  Does something need to be done about potentially
asking the relying party as to what policy it requires to perform some
task?

5. Section 3.8.2:  I find the following text

    Note that this 
    verification MUST take place regardless of whether or not the PC 
    itself contains a policy, as other PCs in the signing chain MAY 
    contain conditions that MUST be verified. 

	to be confusing because I always get policyLanguage and policy
mixed up.  I think that all PCs must have policy and so the statement is
difficult to parse.  I don't know that this can be simplified without
renaming the policy field in the extension.  The text in item 1) just
before this refers to policy and should probably refer to
policyLanguage.

6.  Section 4.1.3 next to last paragraph.  Text should be "If steps (a),
(b) or (d) fail,..."

7.  Section 4.2:  I have a complete lack of understanding for the last
three paragraphs in this section.

8.  Section 5.1.2:  Fix "Section Error! Reference source not found"

9.