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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf