Subject: Re: [Gen-art] Gen-ART review of draft-ietf-sip-certs-07.txt

From: Jason Fischl <[email-masked]>
Date: Mon, 13 Jul 2009 14:24:50 -0700

Hi Suresh,

Thank you for your review. Sorry for the *very* extended delay in  
responding.
See comments inline.

Updated document is here:
https://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-certs-08.txt
https://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-certs-08.html

On Wed, Jan 28, 2009 at 2:50 PM, Suresh Krishnan <[email-masked] 
 > wrote:
> I am the assigned Gen-ART reviewer for
> draft-ietf-sip-certs-07.txt
>
> For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Summary: This draft is almost ready for publication as Proposed  
> Standard,
> but I have a few comments.
>
> Substantial
> ===========
>
> * Section 3 deployment scenario 3
>
> How is the password phrase conveyed to the UA if the credential server
> generates the credentials?
>
The text is 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.  Propose to modify 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.6
>
> It is not clear if a UA that PUBLISHES a credential will also  
> subsequently
> SUBSCRIBE in case the credentials are updated from another device.

I don't think it is required for the PUBLISHer to also SUBSCRIBE. It  
is a realistic scenario for a separate user agent to be acting on  
behalf of the user to update the credentials. This configuring UA  
might have no interest in using those credentials. I recommend leaving  
the text as is.

>
> * 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
> Cheers
> Suresh