draft-ietf-ipsec-pki-profile-01.txt

["Housley, Russ" <rhousley@rsasecurity.com>]

Brian & Eric:

Thanks for pushing this work forward.  I think that it is important if we 
are ever going to achieve interoperability with certificate-based key 
management.

In section 2, you define "Root CA".  How is this different than "trust 
anchor" as defined in RFC 3280?

In section 3.2.2, please reword.  It says: "When comparing the contents of 
ID with the dNSName field in the subjectAltName extension for equality, 
caseless string comparison is performed."  I believe this sentence should 
contain a MUST.  Also, section 3.2.3 contains the same sentence, and it 
should also contain a MUST.

In section 3.2.4, says that address blocks are not supported as name 
forms.  This is true, but some work in this area has been done in 
conjunction with SBGP.  Please review the certificate extension identified by:
     id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }

In section 3.3.8.1, I suggest rewording that avoids the term "trusted 
root," which is not defined. Again, I suggest the term "trust anchor" as 
defined in RFC 3280.

In sections 3.3.8.2 and 3.3.9.2, you should point out that RFC 3280 
prohibits certificates and CRLs with an empty issuer name field.

In section 3.3.9.1, it assumes that the party has ready access to the most 
recent CRLs, and any certificates needed to validate the CRLs.  In a road 
warrior scenario, one of the peers is in a much better situation to obtain 
these than the other.  Should this be discussed?

Please adjust the example description in section 3.3.11.3.  There is no 
requirement that a trust anchor be specified by a self-signed 
certificate.  The peer should never be asked to provide a certificate 
associated with a trust anchor.

In section 3.4.2, should the list also include CRL signatures by CRL issuers?

Shouldn't 3.4.5 be parallel to 3.3.5?  I expected it to recommend against 
the use of ARL.

In section 3.4.10.5, you say: "Implementations MUST be prepared to receive 
certificates and CRLs which are not relevant to the current exchange. 
Implementations MAY discard such keying materials." I agree, but I think 
that the last sentence potentially confusing.  An implementation should 
disregard the extraneous certificates and CRLs, not the symmetric keying 
material that was generated.

In section 4.1.1, I agree that v3 certificates should be required for end 
entity and CA certificates.  However, the same code will likely be used for 
several purposes, and one of them is trust anchors.  Self-signed v1 
certificates are often used to establish trust anchors.

In section 4.1.2.2.2, describing conventions for FQDN Host Names, I think 
that the SHOULD and MAY are backwards.  When a DQDN is carried in the 
subject field of a certificate, the domainComponent attribute SHOULD be 
used.  The commonName attribute MAY be used instead.  I prefer dNSName in 
the SubjectAltName extension to both of these!

In section 4.1.3, I do not understand the second paragraph on the 
criticality bit.  Implementation MUST reject a certificate if it contains 
an extension that it does not know how to handle with the criticality bit 
set to TRUE.

In sections 4.1.3.1, 4.1.3.2, and 4.2.3.1, on the AuthorityKeyIdentifier 
(for certificates and CRLs) and SubjectKeyIdentifier extensions, please 
change "and thus should generate" to "and thus should not generate"

In section 4.1.3.3, I suggest that signature validation operations should 
proceed if either the nonRepudiation or the digitalSignature key usage bit 
is set in an end entity certificate.  In my opinion, digitalSignature is 
preferred, but nonRepudiation should be allowed.

In section 4.1.3.7.1.2, on the iPAddress subjectAltName, a disconnect 
between PKIX and IPsec is pointed out.  You say what MUST NOT be done, but 
you do not say what ought to be done.

    Note that the CIDR [CIDR] notation permitted in the "Name Con-
    straints" section of PKIX is explicitly not permitted by that speci-
    fication for conveying identity information. In other words, the CIDR
    notation MUST NOT be used in the subjectAltName extension.

In section 4.1.3.10, more needs to be said.  Microsoft has received a lot 
of criticism for treating certificates without the basicConstraints 
extension as a CA certificate.  This section permits this behavior.

In section 4.1.3.13, you say that no IPsec extended key usage values have 
been registered.  This is incorrect.  Three extended key usage values for 
use with IPsec have been registered.  Do you propose to deprecate their use?

    id-kp-ipsecEndSystem         OBJECT IDENTIFIER ::= { id-kp 5 }
    id-kp-ipsecTunnel            OBJECT IDENTIFIER ::= { id-kp 6 }
    id-kp-ipsecUser              OBJECT IDENTIFIER ::= { id-kp 7 }

In section 4.1.3.16, you should state that most implementations do not 
support delta CRLs.

In section 4.2.3.5, discussing IssuingDistributionPoint, you incorrectly 
discuss the uses of this extension in support of delta CRLs.  When a CRL is 
not a "full CRL," this extension identifies the subset of information that 
is present.  It also flags indirect CRLs.  I believe that this profile 
should advocate support for "full CRLs," and it should warn that many 
implementations do not support indirect CRLs.

In section 6.1.2.1, I suggest that signature validation operations should 
proceed if either the nonRepudiation or the digitalSignature key usage bit 
is set in an end entity certificate.  In my opinion, digitalSignature is 
preferred, but nonRepudiation should be allowed.

In the References section. please add a reference for PKCS#10.

Russ