At 10:30 AM 2/27/2008, Harsh Kupwade wrote: >Forcing a signer to send a certificate is fine, but if the signer's >root CA is not same as the receiver's root CAs, then the receiver >has to go through a complex path construction process which is not a >trivial problem.
I think this was what I was asking about... and it appears as if it might be a hindrance ><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> >Diana Berbecaru, Antonio Lioy and Marius Marian "On the Complexity >of Public-Key Certificate Validation" > ><http://www.springerlink.com/content/1c77by87fcm34pp9/>http://www.springerlink.com/content/1c77by87fcm34pp9/ > > >Eric Rescorla <[EMAIL PROTECTED]> wrote: >At Wed, 27 Feb 2008 10:02:21 -0600, >James M. Polk wrote: > > > > At 11:41 PM 2/26/2008, Eric Rescorla wrote: > > > > 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 "[EMAIL PROTECTED]: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. > > > > naive question > > > > what burden does this put on a peer (or all peers) to (conceivably) > > have to constantly discover JDR's public key, for example (because > > they don't know how long the private key is good for)? > > > > Or is this problem known/expected or solved easily already? > >Well, the feature of IBE schemes is that once you have the public >parameters for the KG, you can compute the public key without >fetching further data from the CA/KG. This is a lot more interesting >for encryption than it is for signature, since, as I said, you >can force the signer to just send you a new certificate, so the >retrieval cost is minimized. > >-Ekr >_______________________________________________ >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 > > > >Be a better friend, newshound, and know-it-all with Yahoo! Mobile. ><http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>Try > >it now. >_______________________________________________ >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 _______________________________________________ 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
