Review of draft-ietf-sip-eku

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

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]