s/mime and certs cullen jennings [email protected]
TRANSCRIPT
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
b.com
1. Callee with address [email protected] publishes public certificate at b.com (or retrieves certificate + private key)– Does with SIP Publish with Identity
2. Caller wants to call [email protected] and gets the certificate from b.com– 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
12
3
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?