[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-pki-profile-01.txt
Russ,
Thanks for all the useful feedback. Comments below....
On Monday, November 11, 2002, at 09:25 AM, Housley, Russ wrote:
> 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?
None, and perhaps--given the confusion over what "root" means--
it would be best to use the terminology from 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.
No argument here.
>
> 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.
Ok.
>
> 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?
I thought that 3.4.9 "Using local keying materials" covered this base
by stating that if you've got better keymat around, use it. Perhaps
a pointer from 3.3.9.1 to 3.4.9 would be sufficient, or are you
suggesting something more would be good?
>
> 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.
3.3.11.3 doesn't state that R is a self-signed certificate. I'm
also not sure that Trust Anchor is what most people will think of
when they think of certificates for which they have cached the
validity status. I see what you're saying, but I'm not sure
how best to say it.
>
> In section 3.4.2, should the list also include CRL signatures by CRL
> issuers?
Yes.
>
> Shouldn't 3.4.5 be parallel to 3.3.5? I expected it to recommend
> against the use of ARL.
Ok, I see where the text in 3.3.5 isn't clear. I meant to say that
you request CRLs, but you should be capable of receiving CRL and
ARL payloads back, although CRL is preferable as ARL doesn't
provide any real value over CRL. I'll make that clearer.
>
> 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.
3280 mandates that BasicConstraints appear in CA certificates, but
doesn't appear to state that a self-signed trust anchor can
be treated differently. 3280 does state the following:
When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path.
However, without going back and examining the validation algorithm,
it's difficult to know what this means with regards to BC.
In the context of IPsec, do we see many v1 certificates used for this
purpose? I kinda thought that v1 certificates were a dying breed.
>
> 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.
Yes, that text is confusing, and has been rewritten a number
of unsatisfactory times. The point was that if you support
(and thus are going to process) a given extension, then it
isn't necessary to fail if the criticality bit is different
from what PKIX states it must be. If you don't support an
extension you MUST be critical if PKIX says it must, and
thus you must fail.
recognized
extension? bit in cert PKIX mandate what to do
YES TRUE TRUE ok
YES TRUE FALSE ok
YES FALSE TRUE ok
YES FALSE FALSE ok
NO TRUE TRUE fail
NO TRUE FALSE fail
NO FALSE TRUE fail
NO FALSE FALSE ok
When the bit in the cert matches the PKIX mandate, what
to do should be obvious. I don't recall to what extent
3280 addresses the others.
>
> 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"
Doh!
>
> 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.
Uh oh, you don't really want to start another NR debate, do you? ;)
>
> 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.
Actually, this text is supposed to underscore what PKIX states.
That is, PKIX prohibits CIDR notation in this context but allows CIDR
in some other context. The text here is attempting to keep
people from confusing those two contexts (given they both use
the name Name Constraints syntax). I'll put in better pointers
to see if that clears up the confusion.
>
> 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.
Right, this text was written before the Microsoft/SSL issue.
Updating this section might be a good idea.
>
> 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.
Agreed.
>
> 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
>
-brian
briank@xythos.com