Subject: RE: [Sipping] draft-ietf-sipping-certs-01

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Feb 2005 09:20:04 +0000

Cullen,

In section 3: "The private key portion of the credential may have been
encrypted with a secret that only Bob's UA (and not the credential server)
knows." If Bob's second UA doesn't already have Bob's credentials, it is
unlikely to already have a decryption key. Perhaps you intended the key to
be derived from a passphrase that Bob himself has to enter? This does appear
to be the case from section 5.

"Some time later Alice decides that she wishes to discover Bob's certificate
so that she can send him an encrypted message." Or so that she can verify a
signed message from Bob.

In section 4: "If the UA uses a cached certificate in a request and receives
a 493 (Undecipherable) response, it SHOULD remove the certificate it used
from the cache, attempt to fetch the certificate again, and retry the
original request again." I believe a 493 response can arise because of
retargeting to a UAS with different credentials. Simply refreshing the
certificate in this situation will not do. Until we have a solution to
response identity or a ruling on the use of retargeting versus redirection,
we can't solve this. However, it should at least be mentioned.

Section 8 seems to be missing subscriber generation of PUBLISH requests.

I think it would also be useful to be able to use the credential service in
a mode in which it generates credentials (and perhaps gets them signed by a
CA) and makes them available to UAs, rather than accepting credentials via
PUBLISH. In this case the passphrase would be generated at the server and
communicated to the user by out of band means. This may be preferred by some
organisations. Also it might help avoid a possible situation where, without
Bob noticing a hacker gets access to Bob's UA and instructs the UA to
generate new credentials for Bob, along with a new passphrase. Only the
hacker knows the passphrase, so Bob would find that his other UAs have new
private keys that Bob cannot unlock.
 
John 

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings
	Sent: 23 February 2005 01:24
	To: sipping
	Subject: [Sipping] draft-ietf-sipping-certs-01

	I submitted a new version of the draft "Certificate Management
Service for The Session Initiation Protocol (SIP)". This version is much
more specific about all the normative details - I would greatly appreciate a
careful read on this as people are starting to implement it. You can find
the HTML version at 

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sipping-certs-01
.html
	
	(and change html to txt for text version)
	
	Thanks, Cullen

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP