Subject: Re: [Sipping] Question and comments on sipping-certs

From: Rohan Mahy <[email-masked]>
Date: Sun, 5 Jun 2005 09:38:16 -0700

Hi Aki,

I was actually responsible for the ETag addition, so I will respond to
that point.

As a certificate is about to expire, there is a race condition where
two instances could generate a new certificate and PUBLISH them at
roughly the same time.  Since a potentially large number of folks
could be subscribed to the cert package, many of them would get two
notifications in rapid succession with the "first" and then the
"second" certificate.  This is undesirable for traffic engineering
reasons, but the biggest problem is that this makes it harder for all
my instances to get teh same credentials and all of my peers to get
the corresponding (same) certificate. (It significantly increases the
chance that one of my UAs will get a request encrypted with the wrong
certificate.)

This problem is easily prevented if the credential publication relies
on a specific ETag.  The "second" publication will fail, and the
second instance will wait to get the new credential in a NOTIFY (which
has probably been sent already).  Subscribers to the cert package get
only one notification with the "first" new certificate.  Life is good.

This is explained is Section 5.  Would it help to add a new subsection
to Section 8 on subscriber publication?

btw:  subscription and publication expirations are orthogonal to the
lifetime/validity of the certificate.  I think there is some text to
that effect, but it sounds like that point could be called out more.

thanks,
-rohan

On 5/9/05, Aki Niemi <[email-masked]> wrote:
> Hi,
> 
> Reading sipping-certs-01, I wasn't quite sure how the publication of
> credentials is supposed to work. More specifically, the usage of etags
> to make sure UAs for the same AOR don't end up publishing conflicting
> credentials seems unnecessary.
> 
> Since there is only one set of credentials for an AoR, and each new
> publication automatically overwrites any existing credentials (and an
> empty body deletes them), then this can happen regardless of whether the
> etag is shared among the wathcers or not. So why does the NOTIFY carry
> the etag value?
> 
> Also, is the expiration of a publish in any way related to the lifetime
> of the certificate?
> 
> For what purpose is the Content-Disposition set to "signal" in
> credential publication? Where is "signal" defined?
> 
> Third paragraph in chapter 8.5, 3rd sentence should be removed.
> 
> That's all for now!
> 
> Cheers,
> Aki
> 
> 
> 
> 
> _______________________________________________
> 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
>

_______________________________________________
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: Aki Niemi <[email-masked]>
Date: Mon, 06 Jun 2005 14:57:26 +0300

Hi Rohan,

Thanks for the reply. Inline.

> only one notification with the "first" new certificate.  Life is good.

You'd be able to prevent this race condition simply by specifying that 
when a client decides to generate fresh credentials, it wouldn't simply 
do at n minutes before expiration, but rather n + random minutes before 
the cert expires.

The reason I was asking is that without having to carry etags out to the 
subscribers, you could both manually install credentials (e.g., scp them 
to your $HOME/.cert or equivalent) and even when using the PUBLISH 
method, write to disk without having to keep any metadata whatsoever 
around for the credentials.

> that effect, but it sounds like that point could be called out more.

That point was clear for the subscriptions (and well understood), but 
for publications it wasn't very clear.

And the implication of course is that effectively the publication is 
hard state. And that's fine by me (again less metadata to keep around), 
just making sure.

Cheers,
Aki