S/MIME and Certs Cullen Jennings

What changed since IETF 59 Asked to resolve difference and similarities between “cert” draft and “identity” draft. Many possibilities considered. Focus on cleanly separating orthogonal parts of the problem. Came to solution that we can migrate to given what is deployed today.

Model Callee Caller b.com 1.Callee with address publishes public certificate at b.com (or retrieves certificate + private key) –Does with SIP Publish with Identity 2.Caller wants to call and gets the certificate from –Done with SIP Subscribe with Identity 3.Caller encrypts stuff for Callee –Uses S/MIME in SIP 4.Callee fetches caller certificate (from a.com) to verify Caller certificate –Use SIP Subscribe with Identity a.com 4

The Sacred Choice Earlier versions had each device having it’s own credentials. Required caller to encrypt with all possible credentials. Decided this was unworkable. Moved to model where an AOR has (mostly) one credential and moves it using the Sacred framework. Is this OK?

Fetching Credentials Need to use notify to find out the credential has changed Could use notification or config framework to receive credentials

Fetching Certificates Current draft: –Identity mechanism provides strong identity and integrity protection of body. –Subscribe/Notify provides revocation notices. Previous Versions: –HTTPS requires some additional UA check on domain of AOR and HTTP host. –Only revocation mechanism is to have a limited lifetime of certificate. –Could be used by other services that don’t have SIP.

Moving forward … People want to implement this What do we need to do before we decide we want to move forward? Other proposals? Reasons this will not work? Harm this causes?