|
I reviewed the document draft-ietf-sip-eku in general and for its operational impact. Operations directorate reviews are solicited primarily to
help the area directors improve their efficiency, particularly when
preparing for IESG telechats, and allowing them to focus on documents requiring
their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a
secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure
to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves
cause the IESG to raise issue with a document. The reviews may, however,
convince individual IESG members to raise concern over a particular document
requiring further discussion. The reviews, particularly those conducted in
last call and earlier, may also help the document editors improve their
documents. -- Review Summary: Intended status: Proposed Standard This specification documents an extended key usage (EKU)
X.509 certificate extension for restricting the applicability of a
certificate to use with SIP. 1. Is the document readable? Yes. 2. Does it contain nits? 3. Is the document class appropriate? Previous EKU extensions (such as [RFC 4334]) have not been
widely deployed, due to the additional operational complexity they
would have introduced, and the limited benefits. Given this, and the potential interoperability impact of
this document, the Experimental classification would probably be more
appropriate. 4. Does the document consider existing solutions? I don't believe that the document adequately discusses
transition issues, or existing practices. See below for detailed comments. 5. Does the solution break existing technology? In situations where there are pre-existing certificates
without the EKU extensions, this specification could result in
interoperability problems if the "local policy" is not carefully
implemented. One concern is that the language on "local policy"
could be used by implementers to justify refusing to support existing
certificate formats. I do not think that the document adequately addresses how to
manage the transition. For example, during an interim period, it
would be necessary for implementations to support both legacy
certificates as well as certificates with the new extensions. At some
point, once the legacy certificates have expired, "local
policy" could be changed to require only certificates with extensions. At various points in the document, I was unsure whether the
term "implementations" was referring to implementations
of this specification, or pre-existing implementations. See below for detailed
comments. 6. Does the solution preclude future activity? Adding this EKU extension on the Standards Track is likely
to create a need for backward compatibility in the future. 7. Is the solution sufficiently configurable? The document does not discuss what kinds of "local
policy" are appropriate in various situations or how the "local policy"
can be configured or managed. Some additional discussion in this area would
be helpful. 8. Can performance be measured? The document does not address performance measurement. 9. Does the solution scale well? Introducing this extension into an existing large scale
certificate deployments would require a lot of care, to avoid
interoperability problems. 10. Is Security Management discussed? The document does not discuss how certificate
interoperability issues can be dealt with, or how operational problems could be diagnosed. ------------------------------------------------ Detailed comments Section 3 " A Certificate Authority issuing a certificate whose
purpose is to bind a SIP domain identity without binding other non-SIP
identities MUST include an id-kp-SIPdomain attribute in the Extended
Key Usage extension value (see Section 3.1). [BA] Question: What is the definition of "SIP domain
identity"? This is not included in the terminology section. Section 4 " Section 7.1 of Domain Certificates in the Session
Initiation Protocol [8] contains the steps for finding an identity (or a set
of identities) in an X.509 certificate for SIP. In order to
determine whether the usage of a certificate is restricted to serve
as a SIP certificate only, implementations MUST perform the step
given below as a part of the certificate validation: " [BA] Not sure how the first sentence relates to the rest of
the paragraph. Is the intent to suggest that the process for finding the
identity needs to be carried out in order to make the determination?
If so, then [8] would be a normative reference. " o If the certificate does not contain any EKU values
(the Extended Key Usage extension does not exist), it is a matter of
local policy whether or not to accept the certificate for
use as a SIP certificate. " [BA] There are a large number of existing certificates
issued without these EKUs. In situations in which these existing certificates are
expected, leaving their acceptance up to "local policy" would seem
likely to create an interoperability problem. " o If the certificate contains the id-kp-sipDomain EKU
extension, then implementations MUST consider the certificate
acceptable for use as a SIP certificate. " [BA] I presume that this means "implementations of this
specification", correct? Pre-existing implementations don't know about these EKU
extensions, and so will make their determination based on other factors. " o If EKU extension exists but does not contain any of
the id-kp- sipDomain, id-kp-anyExtendedKeyUsage,
id-kp-serverAuth, or id-kp- clientAuth EKU values, then implementations MUST NOT
consider the certificate as acceptable for use as a SIP
certificate. " [BA] Here I think you're referring to pre-existing
implementations as well, correct? |
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf