[Sip] updates to draft-ietf-sip-certs

[Jason Fischl <jason.fischl at gmail.com>]

Based on a Gen-ART review, I've updated the document. Thanks to Suresh
Krishnan for the review. Most of these changes were in
draft-ietf-sip-certs-08.

http://www.ietf.org/id/draft-ietf-sip-certs-09.txt.

* Section 3 deployment scenario 3
> How is the password phrase conveyed to the UA if the credential server
> generates the credentials?
>

The text was a bit confusing as it describes two different scenarios.
I think it should really only be describing the scenario where there
is no pass phrase and the credential server itself generates the
credentials.  Modified the text to be:

3.  Deployments where the credential server generates and stores the
certificates
     and private keys. Deployments such as these may not
     use password phrases. Consequently, the private keys are not
     encrypted inside the PKCS#8 objects.  This style of deployment
     would often have the credential server, instead of the devices,
     create the credentials.

>
> * Section 7.9
>
> I think it needs to be mentioned here that the initial publish will not
> contain a SIP-If-Match header as there is no previous etag. If a
> SIP-If-Match header is required even for an initial request, the example in
> section 8.2 needs to be updated.

Good catch. This particular mechanism didn't make sense and wasn't
consistent with RFC 3903.

>
> * Section 9.1
>
> This section does not cover the relationship between the subscription
> duration and the certificate cache duration. It would be nice if you can add
> some text here to say that the UA MUST NOT cache the certificates for a
> period longer than that of the subscription. This way the UE can be notified
> of any revocations or changes in the certificate.

Added a 4th paragraph:
       The UA MUST NOT cache the certificates for a period longer than that
       of the subscription duration. This is to avoid the UA using invalid
       cached credentials when the notifier of the new credentials has been
       prevented from updating the UA.

> Editorial
> =========
>
> * Intended status is missing (I understand this is targeting Proposed
> Standard based on the tracker)
fixed

>
> * Please fix these obsolete references
> -  RFC 3268 (Obsoleted by RFC 5246)
fixed

>
> -  RFC 4366 (Obsoleted by RFC 5246)
fixed

> In May RSA gave change control of PKCS#8 to the IETF.  Any chance
> we can swap out the reference to [PKCS.8.1993] to [RFC5208]?
fixed

Cheers
Jason