Certificate Management Service for the Session Initiation Protocol (SIP)
draft-ietf-sip-certs-15

[Ballot comment]
#1) From [RFC5280]:
Throughout: r/self signed/self-signed
Throughout: r/certificate authority/certification authority
Throughout: r/certificate authorities/certification authorities
Throughout: Use either subjectAltName or SubjectAltName; use is mixed throughout the I-D.

#2) Section 2: r/A password used to encrypt/A password used to encrypt and decrypt

#3) Section 3: There are three styles of deployment.  For some protocols, there are statements about what the servers MUST support. I'm not sure how it's done in SIP, are servers required to support all three styles or are they allowed to pick and choose? 

#4) Section 5: Assuming you're talking about encrypting the private key and sticking it in a PKCS#8: r/The UA MAY encrypt the private key with a password phrase supplied by the user./The UA MAY encrypt the private key with a password phrase supplied by the user, as specified in Section 10.5.

#5) Section 6.11: r/certificate server/credential server (X2)

#6) Section 7.4: [RFC5208] is obsoleted by [I-D.turner-asymmetrickeyformat]: r/ The application/pkcs8 body contains a DER-encoded [I-D.turner-asymmetrickeyformat]

#7) Section 7.8: (yes I know this is nitty - the flag is actually "cA"): r/CA/cA

#8) Section 7.9: r/If a CA Basic Constraint is set in the certificate, it is set to false./If a cA Basic Constraint flag is set in the certificate, it is set to false.

#9) Section 8: r/SHA1/SHA-1 and r/SHA256/SHA-256

#10) Section 9.1: I know the public key is in the certificate, but I think you meant certificate not public key: r/Alice's public and private keys/Alice's certificate and private key

#11) Section 10.3: r/trust CA/trust certification authority (CA)

#12) Section 10.5: r/per-standard/pre-standard

#13) Section 10.5: In the last sentence, shouldn't that be client authentication?  That is the client should use a different password to protect their private key than they use when they authenticate themselves to the server?

#14) Section 10.6: Should the "should" be "SHOULD" in the first sentence?

#15) Section 13.1: delete reference to RFC 5208

#16) Section 10.6: I know it's in section 5, but is it worth repeating the bit about generating keys with random #s?

[Ballot discuss]
Great document, well written, and easy to understand.  A couple of things before switching to no objection:

#1) As noted in Section 10 negotiating NULL cipher suites is a bad idea.  So let's explicitly prohibit them.  The concern is that you have to support a good cipher suite, but is that the one that's always going to get chosen?  Text that's been used in the past (could be added to the first section of 10.5):

If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms.

#2) (You need to thank Peter Saint-Andre for this text) I would like to add a section about TLS versions to prohibit negotiating back to SSL 2.0.  This text has been suggested by the IESG recently on a number of I-Ds (https://datatracker.ietf.org/doc/draft-ietf-isms-dtls-tm, https://datatracker.ietf.org/doc/draft-lawrence-sipforum-user-agent-config):

TLS Version Requirements

Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol.  Because of known security vulnerabilities,
clients and servers MUST NOT request, offer, or use SSL 2.0.
See Appendix E.2 of [RFC5246] for further details.

#3) In Section 10, I was really hoping for some kind of motherhood and apple pie statement about the user/server keeping the private key private when stored on the client/server.  There's text about keeping the private key private during transit (did I miss the part about the user keeping the key private?).  Is there some text that we can steal from somewhere about requiring some kind of secure storage for the key or point to it?  Maybe a simple statement like:

The private keys require secure storage.

There's a blurb (modified with []) in RFC 5280 (5th para) that also applies:

The protection afforded private keys is a critical security factor.
On a small scale, failure of [users/servers] to protect
[their/clients] private keys will permit an attacker to masquerade
as [them/client] or decrypt [their/client] personal information.

It is in the SACRED framework so maybe something like the following would suffice as a new 3rd paragraph (want to make the following a MUST NOT?):

As noted in the SACRED Framework, when stored on an end user device, such as a diskette or hard drive, credentials SHOULD NOT be in the clear.

Then again I'm not wedded to the wording.

#4) Because the security of the credential is based on a PBES it might be worth noting the password picking guidance in Section 6 of [I-D.turner-asymmetrickeyformat] (crappy passwords means crappy security).  It's okay to copy it or just point to it (would mean adding reference to NIST SP 800-83, but I think it's worth drawing particular attention to.

[Ballot comment]
#1) From [RFC5280]:
Throughout: r/self signed/self-signed
Throughout: r/certificate authority/certification authority
Throughout: r/certificate authorities/certification authorities
Throughout: Use either subjectAltName or SubjectAltName; use is mixed throughout the I-D.

#2) Section 2: r/A password used to encrypt/A password used to encrypt and decrypt

#3) Section 3: There are three styles of deployment.  For some protocols, there are statements about what the servers MUST support. I'm not sure how it's done in SIP, are servers required to support all three styles or are they allowed to pick and choose? 

#4) Section 5: Assuming you're talking about encrypting the private key and sticking it in a PKCS#8: r/The UA MAY encrypt the private key with a password phrase supplied by the user./The UA MAY encrypt the private key with a password phrase supplied by the user, as specified in Section 10.5.

#5) Section 6.11: r/certificate server/credential server (X2)

#6) Section 7.4: [RFC5208] is obsoleted by [I-D.turner-asymmetrickeyformat]: r/ The application/pkcs8 body contains a DER-encoded [I-D.turner-asymmetrickeyformat]

#7) Section 7.8: (yes I know this is nitty - the flag is actually "cA"): r/CA/cA

#8) Section 7.9: r/If a CA Basic Constraint is set in the certificate, it is set to false./If a cA Basic Constraint flag is set in the certificate, it is set to false.

#9) Section 8: r/SHA1/SHA-1 and r/SHA256/SHA-256

#10) Section 9.1: I know the public key is in the certificate, but I think you meant certificate not public key: r/Alice's public and private keys/Alice's certificate and private key

#11) Section 10.3: r/trust CA/trust certification authority (CA)

#12) Section 10.5: r/per-standard/pre-standard

#13) Section 10.5: In the last sentence, shouldn't that be client authentication?  That is the client should use a different password to protect their private key than they use when they authenticate themselves to the server?

#14) Section 10.6: Should the "should" be "SHOULD" in the first sentence?

#15) Section 13.1: delete reference to RFC 5208

#16) Section 10.6: I know it's in section 5, but is it worth repeating the bit about generating keys with random #s?

[Ballot discuss]
Great document, well written, and easy to understand.  A couple of things before switching to no objection:

#1) As noted in Section 10 negotiating NULL cipher suites is a bad idea.  So let's explicitly prohibit them.  The concern is that you have to support a good cipher suite, but is that the one that's always going to get chosen?  Text that's been used in the past (could be added to the first section of 10.5):

If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms.

#2) (You need to thank Peter Saint-Andre for this text) I would like to add a section about TLS versions to prohibit negotiating back to SSL 2.0.  This text has been suggested by the IESG recently on a number of I-Ds (https://datatracker.ietf.org/doc/draft-ietf-isms-dtls-tm, https://datatracker.ietf.org/doc/draft-lawrence-sipforum-user-agent-config):

TLS Version Requirements

Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol.  Because of known security vulnerabilities,
clients and servers MUST NOT request, offer, or use SSL 2.0.
See Appendix E.2 of [RFC5246] for further details.

#3) In Section 10, I was really hoping for some kind of motherhood and apple pie statement about the user/server keeping the private key private when stored on the client/server.  There's text about keeping the private key private during transit (did I miss the part about the user keeping the key private?).  Is there some text that we can steal from somewhere about requiring some kind of secure storage for the key or point to it?  Maybe a simple statement like:

The private keys require secure storage.

There's a blurb (modified with []) in RFC 5280 (5th para) that also applies:

The protection afforded private keys is a critical security factor.
On a small scale, failure of [users/servers] to protect
[their/clients] private keys will permit an attacker to masquerade
as [them/client] or decrypt [their/client] personal information.

It is in the SACRED framework so maybe something like the following would suffice as a new 3rd paragraph (want to make the following a MUST NOT?):

As noted in the SACRED Framework, when stored on an end user device, such as a diskette or hard drive, credentials SHOULD NOT be in the clear.

Then again I'm not wedded to the wording.

#4) Because the security of the credential is based on a PBES it might be worth noting the password picking guidance in Section 6 of [I-D.turner-asymmetrickeyformat] (crappy passwords means crappy security).  It's okay to copy it or just point to it (would mean adding reference to NIST SP 800-83, but I think it's worth drawing particular attention to.

[Ballot discuss]
ORIGINAL PART OF DISCUSS:

  The document only supports sha1WithRSAEncryption (se Section 9.6).
  If only one is going to be supported, I greatly prefer
  sha256WithRSAEncryption.

  Why not reference RFC 5208 instead of PKCS#8?  RSA has given change
  control for PKCS#8 to the IETF, so a reference to RFC 5208 will allow
  people to find any subsequent versions that the IETF might produce.

LATE ADDITION:

  The document says:

  The PKCS#8 in the clients MUST implement PBES2 with a key derivation
  algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and an
  encryption algorithm of DES-EDE2-CBC-Pad as defined in [RFC2898].

  The use of Triple-DES seems very odd.  I would much rather see
  AES Key Wrap with Padding as specified in RFC 5649.

[Ballot discuss]
The document only supports sha1WithRSAEncryption (se Section 9.6).
  If only one is going to be supported, I greatly prefer
  sha256WithRSAEncryption.

  Why not reference RFC 5208 instead of PKCS#8?  RSA has given change
  control for PKCS#8 to the IETF, so a reference to RFC 5208 will allow
  people to find any subsequent versions that the IETF might produce.

[Ballot comment]
This part was a DISCUSS:

In Section 7.5:

  The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that
  contains both an application/pkix-cert body with the certificate and
  an application/pkcs8 body that has the associated private key
  information for the certificate.  The Content-Disposition MUST be set
  to "signal" as defined in [RFC3204].

  A future extension MAY define other NOTIFY bodies.  If no "Accept"
  header field is present in the SUBSCRIBE, the body type defined in
  this document MUST be assumed.

Question: does the Accept header field body contains "multipart/mixed"
or "application/pkcs8"? How would this work for future extensions if
there is a need to return other media types inside a top level "multipart/mixed"?

---------------------------------------

4.  UA Behavior with Certificates

  The Subscriber needs to decide how long it is willing to trust that
  the certificate it receives is still valid.  If the certificate is
  revoked before it expires, the Notifier will send a notification with
  an empty body to indicate that the certificate is no longer valid.
  If the certificate is renewed before it expires, the Notifier will
  send a notification with a body containing the new certificate.

It would be nice to state the assumption that there is only one certificate per user at any given time earlier in the document.


6.12.  State Agents and Lists

  The certificate server described in this section which serves
  certificates is a state agent and implementations of the certificate
  server MUST be implemented as a state agent.

Question: which document defines the "state agent" term?

7.6.  Subscriber Generation of SUBSCRIBE Requests

  The UA needs to authenticate with the credential service for these
  operations.  The UA MUST use TLS to directly connect to the server
  acting as the credential service or to a server that is authoritative
  for the domain of the credential service.  The UA MUST NOT connect
  through an intermediate proxy to the credential service.

Last sentence: it would be helpful if the document pointed out
how to achieve this.

7.10.  Notifier Processing of PUBLISH Requests

  If the Subscriber submits a PUBLISH request with no body, this
  revokes the current credentials and causes all subscriptions to the
  credential package to be deactivated as described in the previous
  section.

I think you need an explicit section reference number here, section 7.9 is talking about something else.

In Section 9.5:

  The PKCS#8 in the clients MUST implement PBES2 with a key derivation
  algorithm of PBKDF2 using HMAC with SHA1

I think this needs references to HMAC and SHA1 documents.

  and an encryption algorithm
  of DES-EDE2-CBC-Pad as defined in [RFC2898].  It is RECOMMENDED that
  this profile be used when using PKCS#8.  A different passphrase
  SHOULD be used for the PKCS#8 encryption than is used for server
  authentication.

[Ballot comment]
This part was a DISCUSS:

In Section 7.5:

  The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that
  contains both an application/pkix-cert body with the certificate and
  an application/pkcs8 body that has the associated private key
  information for the certificate.  The Content-Disposition MUST be set
  to "signal" as defined in [RFC3204].

  A future extension MAY define other NOTIFY bodies.  If no "Accept"
  header field is present in the SUBSCRIBE, the body type defined in
  this document MUST be assumed.

Question: does the Accept header field body contains "multipart/mixed"
or "application/pkcs8"? How would this work for future extensions if
there is a need to return other media types inside a top level "multipart/mixed"?

---------------------------------------

4.  UA Behavior with Certificates

  The Subscriber needs to decide how long it is willing to trust that
  the certificate it receives is still valid.  If the certificate is
  revoked before it expires, the Notifier will send a notification with
  an empty body to indicate that the certificate is no longer valid.
  If the certificate is renewed before it expires, the Notifier will
  send a notification with a body containing the new certificate.

It would be nice to state the assumption that there is only one certificate per user at any given time earlier in the document.


6.12.  State Agents and Lists

  The certificate server described in this section which serves
  certificates is a state agent and implementations of the certificate
  server MUST be implemented as a state agent.

Question: which document defines the "state agent" term?

7.6.  Subscriber Generation of SUBSCRIBE Requests

  The UA needs to authenticate with the credential service for these
  operations.  The UA MUST use TLS to directly connect to the server
  acting as the credential service or to a server that is authoritative
  for the domain of the credential service.  The UA MUST NOT connect
  through an intermediate proxy to the credential service.

Last sentence: it would be helpful if the document pointed out
how to achieve this.

7.10.  Notifier Processing of PUBLISH Requests

  If the Subscriber submits a PUBLISH request with no body, this
  revokes the current credentials and causes all subscriptions to the
  credential package to be deactivated as described in the previous
  section.

I think you need an explicit section reference number here, section 7.9 is talking about something else.

[Ballot discuss]
This is a good and useful document and I support its publication.
However I have a small set of relatively minor issues I would like to discuss first.

4) In Section 9.5:

  Credential services SHOULD implement the server name indication
  extensions in [RFC5246] and they MUST support a TLS profile of
  TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246] as a profile
  of TLS_RSA_WITH_3DES_EDE_CBC_SHA.

I can't parse this sentence.

  The PKCS#8 in the clients MUST implement PBES2 with a key derivation
  algorithm of PBKDF2 using HMAC with SHA1

(Comment) I think this needs references to HMAC and SHA1 documents.

  and an encryption algorithm
  of DES-EDE2-CBC-Pad as defined in [RFC2898].  It is RECOMMENDED that
  this profile be used when using PKCS#8.  A different passphrase
  SHOULD be used for the PKCS#8 encryption than is used for server
  authentication.

[Ballot comment]
2.  Definitions

      Certificates
      that are signed by a certificate authority can also be used with
      all the mechanisms in this draft, but it is expected that they are
      used purely as a key carrier and that their validity is not
      checked.

I find this statement to be strange, if not wrong.

4.  UA Behavior with Certificates

  The Subscriber needs to decide how long it is willing to trust that
  the certificate it receives is still valid.  If the certificate is
  revoked before it expires, the Notifier will send a notification with
  an empty body to indicate that the certificate is no longer valid.
  If the certificate is renewed before it expires, the Notifier will
  send a notification with a body containing the new certificate.

It would be nice to state the assumption that there is only one certificate per user at any given time earlier in the document.


5.  UA Behavior with Credentials

  Credentials are created by creating a new key pair which will require
  appropriate randomness,

I think an Informative reference to RFC 4086 would be appropriate here:

  [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

6.12.  State Agents and Lists

  The certificate server described in this section which serves
  certificates is a state agent and implementations of the certificate
  server MUST be implemented as a state agent.

Question: which document defines the "state agent" term?

7.6.  Subscriber Generation of SUBSCRIBE Requests

  The UA needs to authenticate with the credential service for these
  operations.  The UA MUST use TLS to directly connect to the server
  acting as the credential service or to a server that is authoritative
  for the domain of the credential service.  The UA MUST NOT connect
  through an intermediate proxy to the credential service.

Last sentence: it would be helpful if the document pointed out
how to achieve this.

7.10.  Notifier Processing of PUBLISH Requests

  If the Subscriber submits a PUBLISH request with no body, this
  revokes the current credentials and causes all subscriptions to the
  credential package to be deactivated as described in the previous
  section.

I think you need an explicit section reference number here, section 7.9 is talking
about something else.

[Ballot discuss]
This is a good and useful document and I support its publication.
However I have a small set of relatively minor issues I would like to discuss first.

1) In Section 6.2:
            etag-param = "etag" EQUAL token

I think this needs a normative reference to RFC 5234 (ABNF).

<>

2) DISCUSS DISCUSS

In Section 7.5:

  The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that
  contains both an application/pkix-cert body with the certificate and
  an application/pkcs8 body that has the associated private key
  information for the certificate.  The Content-Disposition MUST be set
  to "signal" as defined in [RFC3204].

  A future extension MAY define other NOTIFY bodies.  If no "Accept"
  header field is present in the SUBSCRIBE, the body type defined in
  this document MUST be assumed.

Question: does the Accept header field body contains "multipart/mixed"
or "application/pkcs8"? How would this work for future extensions if
there is a need to return other media types inside a top level "multipart/mixed"?

3) DISCUSS DISCUSS

7.10.  Notifier Processing of PUBLISH Requests

(Question to Security ADs):
Excuse my ignorance, but are there any useful checks that can be
performed to see if the application/pkix-cert body
part matches information in the application/pkcs8 body part?

4) In Section 9.5:

  Credential services SHOULD implement the server name indication
  extensions in [RFC5246] and they MUST support a TLS profile of
  TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246] as a profile
  of TLS_RSA_WITH_3DES_EDE_CBC_SHA.

I can't parse this sentence.

  The PKCS#8 in the clients MUST implement PBES2 with a key derivation
  algorithm of PBKDF2 using HMAC with SHA1

(Comment) I think this needs references to HMAC and SHA1 documents.

  and an encryption algorithm
  of DES-EDE2-CBC-Pad as defined in [RFC2898].  It is RECOMMENDED that
  this profile be used when using PKCS#8.  A different passphrase
  SHOULD be used for the PKCS#8 encryption than is used for server
  authentication.

[Ballot discuss]
The document only supports sha1WithRSAEncryption (se Section 9.6).
  If only one is going to be supported, I greatly prefer
  sha256WithRSAEncryption.

  Why not reference RFC 5208 instead of PKCS#8?  RSA has given change
  control for PKCS#8 to the IETF, so a reference to RFC 5208 will allow
  people to find any subsequent versions that the IETF might produce.

  I saw a Last Call comment from Steve Kent asking why PKIX enrollment
  protocols are not supported.  I did not see a response to that query.

[Ballot discuss]
I have reviewed draft-ietf-sip-certs-09, and have one question
that I'd like to discuss before recommending approval of the document:

In Section 7.10, why is the credential service required to check that
one of the SubjectAltNames matches the authorized user (and the basic
constraints)? The final recipient of the certificate will not usually
use that SubjectAltName for anything (so it doesn't really matter what
it contains)... and this check would complicate using CA-issued
certificates (since it requires the credential service to know what
kinds of names that particular CA uses).

(I will probably clear this DISCUSS after the telechat, but would
be interested in knowing the rationale behind this requirement.)

[Ballot discuss]
This is a good document, and I will move to Yes once some issues have been addressed.

As noted in section 2:

                                                                                Certificates
      that are signed by a certificate authority can also be used with
      all the mechanisms in this draft, but it is expected that they are
      used purely as a key carrier and that their validity is not
      checked.

IMHO, the self-signed certificate and credential distribution mechanisms provide a significant incremental improvement in SIP security, and provide a reasonable transition strategy to promote use of certificates for SIP security.  If certificates signed by a trusted third party are used "purely as a key carrier" instead of self-signed certificates, the security achieved is the same in both cases.  However, using certificates issued by trusted third parties can provide a more robust level of security for SIP applications by leveraging the PKIX tool set.  However, the mechanisms for use with certificates from trusted third parties are under-specified so an implementer would not know how or where to integrate these tools into a product if they are available and the additional security is desired.

I would like to see an additional section in the security considerations section that explains the incremental improvement in security provided by validating the chain of certificates associated with the user's third party certificate, pointing to RFC 5280.

[Ballot comment]
2.  Definitions

      Certificates
      that are signed by a certificate authority can also be used with
      all the mechanisms in this draft, but it is expected that they are
      used purely as a key carrier and that their validity is not
      checked.

I find this statement to be strange, if not wrong.

4.  UA Behavior with Certificates

  The Subscriber needs to decide how long it is willing to trust that
  the certificate it receives is still valid.  If the certificate is
  revoked before it expires, the Notifier will send a notification with
  an empty body to indicate that the certificate is no longer valid.
  If the certificate is renewed before it expires, the Notifier will
  send a notification with a body containing the new certificate.

It would be nice to state the assumption that there is only one certificate per user at any given time earlier in the document.


5.  UA Behavior with Credentials

  Credentials are created by creating a new key pair which will require
  appropriate randomness,

I think an Informative reference to RFC 4086 would be appropriate here:

  [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

6.12.  State Agents and Lists

  The certificate server described in this section which serves
  certificates is a state agent and implementations of the certificate
  server MUST be implemented as a state agent.

Question: which document defines the "state agent" term?

7.6.  Subscriber Generation of SUBSCRIBE Requests

  The UA needs to authenticate with the credential service for these
  operations.  The UA MUST use TLS to directly connect to the server
  acting as the credential service or to a server that is authoritative
  for the domain of the credential service.  The UA MUST NOT connect
  through an intermediate proxy to the credential service.

Last sentence: it would be helpful if the document pointed out
how to achieve this.

7.10.  Notifier Processing of PUBLISH Requests

  If the Subscriber submits a PUBLISH request with no body, this
  revokes the current credentials and causes all subscriptions to the
  credential package to be deactivated as described in the previous
  section.

I think you need an explicit section reference number here, section 7.9 is talking
about something else.

[Ballot discuss]
This is a good and useful document and I support its publication.
However I have a small set of relatively minor issues I would like to discuss first.

1) DISCUSS DISCUSS (I am likely to clear this part after the telechat)

In Section 3:

  Bob's UA (Bob2) does a TLS [RFC5246] handshake with the credential
  server to authenticate that the UA is connected to the correct
  credential server.  Then Bob's UA publishes his newly created or
  updated credentials.  The credential server digest challenges the UA
  to authenticate that the UA knows Bob's shared secret.  Once the UA
  is authenticated, the credential server stores Bob's credentials.

As TLS will only be authenticating the server end, it would be
great to use some channel binding facility between TLS and Digest authentication. Is there any work on defining channel bindings for use in SIP?

2) In Section 6.2:
            etag-param = "etag" EQUAL token

I think this needs a normative reference to RFC 5234 (ABNF).

<>

3) DISCUSS DISCUSS

In Section 7.5:

  The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that
  contains both an application/pkix-cert body with the certificate and
  an application/pkcs8 body that has the associated private key
  information for the certificate.  The Content-Disposition MUST be set
  to "signal" as defined in [RFC3204].

  A future extension MAY define other NOTIFY bodies.  If no "Accept"
  header field is present in the SUBSCRIBE, the body type defined in
  this document MUST be assumed.

Question: does the Accept header field body contains "multipart/mixed"
or "application/pkcs8"? How would this work for future extensions if
there is a need to return other media types inside a top level "multipart/mixed"?

4) DISCUSS DISCUSS

7.10.  Notifier Processing of PUBLISH Requests

(Question to Security ADs):
Excuse my ignorance, but are there any useful checks that can be
performed to see if the application/pkix-cert body
part matches information in the application/pkcs8 body part?

5) In Section 9.5:

  Credential services SHOULD implement the server name indication
  extensions in [RFC5246] and they MUST support a TLS profile of
  TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246] as a profile
  of TLS_RSA_WITH_3DES_EDE_CBC_SHA.

I can't parse this sentence.

  The PKCS#8 in the clients MUST implement PBES2 with a key derivation
  algorithm of PBKDF2 using HMAC with SHA1

(Comment) I think this needs references to HMAC and SHA1 documents.

  and an encryption algorithm
  of DES-EDE2-CBC-Pad as defined in [RFC2898].  It is RECOMMENDED that
  this profile be used when using PKCS#8.  A different passphrase
  SHOULD be used for the PKCS#8 encryption than is used for server
  authentication.

[Ballot comment]
Section 6.5., paragraph 3:
>    Implementations which generate large notifications are reminded to
>    follow the message size restrictions for unreliable transports
>    articulated in Section 18.1.1 of SIP.

  It's pretty much guaranteed that NOTIFYs that have S/MIME certs in
  them will be longer than 1300 bytes. It's also pretty much guaranteed
  that the clients will have no idea of the PMTU. According to Section
  18.1.1 of RFC3261 this means that these will need to be sent over TCP.
  How many stacks are really going to support this "upconversion" to
  TCP? I was under the impression that TCP support wasn't really there?

  (I may upgrade this to a discuss, but let's see.)

[Ballot discuss]
Section 12.1., paragraph 4:
>    [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
>              Specification Version 2.0", RFC 2898, September 2000.

  DISCUSS: Downref. (The one to RFC5208 was handled in last-call but not
  this one?)

IANA comments:

ACTION 1:

Upon approval of this document, IANA will make the following
assignments in the "Session Initiation Protocol (SIP) Event
Types Namespace - per [RFC3427]" registry at
http://www.iana.org/assignments/sip-events

Package Name Type Contact Reference
-------------------------- ---------------- --------------- ---------
certificate package Cullen Jennings  [RFC-sip-certs-09]
credential package Cullen Jennings  [RFC-sip-certs-09]


ACTION 2:

Upon approval of this document, IANA will make the following
assignments in the "Header Fields" registry at
http://www.iana.org/assignments/sip-parameters

Header Name compact Reference
----------------- ------- ---------
etag [RFC-sip-certs-09]


ACTION 3:

Upon approval of this document, IANA will make the following
assignments in the "Application Media Types" registry at
http://www.iana.org/assignments/media-types/application/

pkcs8 [RFC-sip-certs-09]

We understand the above to be the only IANA Actions for this document.

Expecting a revision changing the reference to PKCS.8.1993 to point to RFC5208 instead. Then we'll need to rerun a last call for the downref to 5208.

IANA Last Call comments:

Action #1:
Upon approval of this document, IANA will make the following
assignments in the "Session Initiation Protocol (SIP) Event
Types Namespace - per [RFC3427]" registry at
http://www.iana.org/assignments/sip-events

Package Name Type Contact Reference
-------------------------- ---------------- --------------- ---------
certificate package Cullen Jennings  [RFC-sip-certs-07]
credential package Cullen Jennings  [RFC-sip-certs-07]


Action #2:
Upon approval of this document, IANA will make the following
assignments in the "Header Fields" registry at
http://www.iana.org/assignments/sip-parameters

Header Name compact Reference
----------------- ------- ---------
etag [RFC-sip-certs-07]

Action #3:
Upon approval of this document, IANA will make the following
assignments in the "Application Media Types" registry at
http://www.iana.org/assignments/media-types/application/

pkcs8 [RFC-sip-certs-07]

We understand the above to be the only IANA Actions for this document.

The SIP working group hereby requests publication of the document draft-ietf-sip-certs-05 as a Proposed Standard.



(1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is working group chair Dean Willis, who has personally reviewed this version of the document and believes it is ready for forwarding to the IESG for publication.


(1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?  Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has been extensively reviewed within the working group and by external reviewers, including security area review.

(1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No further review required.


(1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.  Has an IPR disclosure related to this document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No concerns.

(1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

This document enjoys a high level of working group concurrence, relative to the majority of security-related documents. Essentially the working group as a whole agree with the document, including the ones who actually understand it.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

This shepherd is unaware of any discontent.

(1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
        not enough; this check needs to be thorough.  Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The shepherd applied idnits 2.06.01. Note that the document does contain a downref to RFC 2898. This downref is explained in the references section of the document and appears to be justified under the procedures of RFC 3967. The following text is quoted from the document:

            This reference is normative.  The mechanisms used in this
            specification from RFC2898 are stable and sutable for use
            in a standards track specification.  RFC2898 has been used
            as a normative reference in several prior standards track
            documents including RFC3185, RFC3370, RFC3962, and
            RFC4656.

The document also received appropriate review from the MIME Types alias and SIP events alias.


(1.h)  Has the document split its references into normative and
        informative?  Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion?  Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are properly split, with one valid downward reference as described above.


(1.i)  Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?  If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?  If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA actions section appears to be correct, and has undergone appropriate expert review.

(1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The document appears to contain no formal language.

(1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up?  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary


This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users.  This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate.  The Credential Service also allows users to store and retrieve their own certificates and private keys. Several operational modes are defined, wherein the credential service may act only as a distributor of the public key, may also act as a distributor of the encrypted private key, or as the repository and distributor of both the public and private key.



        Working Group Summary

The working group process for this draft was unusually long, spanning several years.




        Document Quality
          Are there existing implementations of the protocol?  Have a
          significant number of vendors indicated their plan to
          implement the specification?  Are there any reviewers that
          merit special mention as having done a thorough review,
          e.g., one that resulted in important changes or a
          conclusion that the document had no substantive issues?  If
          there was a MIB Doctor, Media Type or other expert review,
          what was its course (briefly)?  In the case of a Media Type
          review, on what date was the request posted?

We are currently not aware of any publicly announced implementations of this specification, although one can be built relatively trivially on top of general purpose SIP Events servers, and we are aware of at least one internal prototype implemented in this manner.

MIME type review was non-controversial and was initiated on March 12, 2007. Björn Höhrmann raised several points, which were resolved in the -04 version of this specification.

SIP Events review was performed by Adam Roach, with several issues being noted and resolved in -03 of this specification.