Re: [Sip] comments on draft-kupwade-sip-iba-00

[Dean Willis <[e-mail]>]

On Feb 26, 2008, at 11:41 PM, Eric Rescorla wrote:
>
>> What about intellectual
>> property issues?
>
> Yes, there are a number of patents in the field. I don't know about
> these specific algorithms, but given that they post-date the
> original Boneh-Franklin IBE patent, it wouldn't be surprising
> if they were covered by patents. Dean?

We expect to have IPR on some related material, but I don't believe it  
is required for the subject discussed in the draft.

There are rumors that Boneh's folks have a lot of IPR in the area.

...

>> I agree with Ekr that the primary advantage from a pure signature
>> perspective is the ability to eliminate the fetching of the  
>> certificate.
>> I think this is more beneficial than just 'compression'. Identity- 
>> Info
>> presents the certificate by reference. The increasing numbers of  
>> NAT and
>> firewalls and SBCs are making me increasingly worried that the  
>> ability
>> to reach across the network, back to the originator, and fetch  
>> ANYTHING
>> over http, will be really hard in SIP deployments. So there is  
>> value in
>> eliminating this IMHO.
>
> Sure, but we could just shove the certificate into the message
> in a new header or in the body, at which point we are talking
> about compression. Moreover, there's no requirement that the
> certificate be on the UAC's machine. If people care about this,
> then it seems pretty likely that the CA can operate a site
> which hosts your certificate for you. This is especially true
> when we're talking about one certificate per domain as assumed
> by RFC 4474.

The real benefit is not just the elimination of cert-fetching, but the  
reduction of effort for cert validation. The entire validation tree is  
essentially encoded in the mathematics. If it works at all, the key  
was "good" (which doesn't say anything about whether it has been  
compromised and/or revoked).

There's also some benefit to using time-limited identities to reduce  
the massive problem of CRL management.

Here's a novel thing:

Let's say I know your identity is sip:[e-mail], and  
that your relationship with the PKG allows you to retrieve keys for  
parameterized versions of that identity.

I can construct a new cryptographic identity for you, perhaps "sip:[e-mail];ID=2009121222 
" and use that to sign a message to you. You've never seen this  
identity before and don't yet even have the private key for it. You  
then go to your PKG and retrieve said key and use it to verify the  
message.

I didn't need to check a CRL (or worry about known-text attacks, etc.)  
for your cert, because I in effect forced the creation of a new one.


>> I must say I didn't understand how revocation works. From the
>> description of the algorithm it seemed untenable. The verifier never
>> needs to obtain a cert and the public key is generated statically  
>> from
>> the identity. Once they have the private key, the sender can always  
>> sign
>> with it, so I don't see how revocation is possible.
>
> The way this is done is with what's effectively short-lived
> identities (you could do the same thing with short-lived
> certificates) you treat the time as part of the identity.
> E.g., you might be "[e-mail]:March-April, 2008". So,
> the user needs to periodically refresh his private key to match
> the new identity. If the key has been revoked you don't issue
> new keys.

Right, that's a variation of the technique I outlined above.

If one has a convention for encoding the duration into the identity,  
then it can be made to work very smoothly.

--
Dean
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip