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 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
