Subject: [Sipping] Re: draft-ietf-sipping-certs-00

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2004 14:36:14 -0500

1) cert caching

                             "The UA needs to cache this certificate for
    future use.  The certificate MUST be removed from the cache if it has
    expired, if it is updated by a subsequent NOTIFY, or if the
    subscription has been terminated."

This implies that I must have an active subscription to anyone I may 
want to call. Since there tends to be very little call locality, that 
means a lot of subscriptions active all the time, or else establishing 
and ending a subscription for each call. Why not just admit that caching 
may be done after the subscription terminates, until the cert expires, 
at the risk of missing a revocation?

2) NOTIFY addressing

   "When the Credential Server receives a SUBSCRIBE for a certificate, it
    first checks to see if it has credentials for the requested URI.  If
    it does not it returns a response indicating the user was not found.
    Otherwise it sets up a subscription and forms a NOTIFY with the
    certificate in the body and the From header field value set to the
    request URI of the SUBSCRIBE."

The credential server has no choice about what to put in the From header 
of the Notify - it is determined by the dialog of the subscription, and 
will equal the To header of the Subscribe. It is likely that the To 
header and request header will be the same in this case, but that is not 
certain.

3) Server storing private keys

Having the credential server store the private keys means they are 
potentially in the hands of an organization subject to legal 
requirements for key disclosure. As a result, sessions secured with 
these credentials may be subject to wire tap. As a work-around to this, 
how about making the secret key optional when publishing and subscribing 
to the credentials. If a credential is published without a secret key, 
it will be distributed without. Then only those endpoints that have the 
private key can successfully use the credential - typically the device 
that published it.

4) multipart/alternative and offer

   "If a UA receives both an unencrypted and an encrypted SDP offer in an
    multipart/alternative body, it interprets these as it would a normal
    multipart alternative as defined in RFC 2046 [16], which means it
    picks the last alternative that it can support.  Any bodies that
    cannot be decrypted are treated as unsupportable.  The sending UA
    should generally put encrypted offers after unencrypted ones, since
    encrypted ones are preferred."

There is an issue of knowing whether an encrypted offer is in fact an 
offer or not. Offers (and answers) are recognized by Content-Disposition 
  of session. But in case of encrypted sdp, we have no rules that say 
what the content-disposition of the encrypted body must be - it will 
only be after decryption that the content disposition of the encrypted 
body was.

It may be that when using multipart/alternative, we specify that *it* 
must contain a content-disposition, which matches that of everything in 
it, and that a application/pkcs7-mime must also be tagged with the c-d 
of its content.

5) multipart/alternative and answer

                                  "The UA constructs the answer to the
    offer as it normally would and may include both encrypted and
    unencrypted versions of the answer using multipart/alternative."

Is this necessary? Is there a case where the answerer doesn't know 
whether the offerer will be able to decrypt the answer? For that matter, 
if the offer was encrypted, does it ever make sense for the answer to 
not be encrypted?

6) event type for certs

     SUBSCRIBE sip:[email-masked] SIP/2.0
     ...
     Event: certificate

Isn't the event type supposed to be pkix-cert? (According to section 4.)

	Paul

P.S. "I'm over at Osama's house at 21.25'24"N 39.49'24"E" -
      I see you did your homework. Or were you carrying a GPS
      when you visited? :-)

_______________________________________________
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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 11 Nov 2004 14:44:19 -0500

Great comments - thanks for catching this stuff will fix.

> at the risk of missing a revocation?

will add more text - your interpretation is correct. There is a strong
locality with people I call and people who's presence I monitor

> header and request header will be the same in this case, but that is not

Yes - will fix.
 
> private key can successfully use the credential - typically the device

Good point. The pkcs8 data can be encrypted with a symmetric passphrase - I
will add text

> it, and that a application/pkcs7-mime must also be tagged with the c-d

I will work with you on getting wording correct here

> if the offer was encrypted, does it ever make sense for the answer to

will think about this but if offer indicates one can do S/MIME, seems like
safe assumption should be that it can do S/MIME on answer

> Isn't the event type supposed to be pkix-cert? (According to section 4.)

oops - typo - thanks