Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Informational May 9, 2016 Expires: November 10, 2016 Using WebRTC Identity with STIR draft-jennings-stir-rtcweb-identity-00 Abstract This draft outlines the approach to use STIR Passport tokens as the Identity assertions in WebRTC. It outlines some proposed changes to improve identity interoperability for different calling systems. This is a very rough first draft purely to have something to discuss. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 10, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jennings Expires November 10, 2016 [Page 1] Internet-Draft WebRTC and STIR Identity May 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Information Flow . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Mapping to SIP . . . . . . . . . . . . . . . . . . . . . 6 3. Proposed Changes . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Remove Identity Hint Hack . . . . . . . . . . . . . . . . 7 3.2. Fingerprint format. . . . . . . . . . . . . . . . . . . . 7 3.3. Format of identity header . . . . . . . . . . . . . . . . 7 3.3.1. Token type in Identity header to allow multiple identity headers . . . . . . . . . . . . . . . . . . 7 3.3.2. WebRTC support multiple tokens . . . . . . . . . . . 8 3.3.3. Abstract the identity and protocol in the WebRTC assertion . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Future Proofing . . . . . . . . . . . . . . . . . . . . . 8 3.5. TEL URI . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. RFC822 Names . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 3.8. WebRTC Canonical Form . . . . . . . . . . . . . . . . . . 9 3.9. Multi party . . . . . . . . . . . . . . . . . . . . . . . 9 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 5.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Example Cert . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Example Private Key . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This draft is purely to help track the discussion about WebRTC and STIR identity and provide a place to send pull requests. It is not meant to become an RFC - the relevant information will flow into other specifications once we come to some consensus on what needs to be done. It assumes the reader if familiar with [I-D.ietf-rtcweb-security-arch], [I-D.ietf-stir-certificates], [I-D.ietf-stir-passport], and [I-D.ietf-stir-rfc4474bis]. 2. Information Flow This section steps through the logical information flow to use STIR Identity in WebRTC based on what we have in the specifications today. Later sections propose some changes to current specifications. Jennings Expires November 10, 2016 [Page 2] Internet-Draft WebRTC and STIR Identity May 2016 2.1. Actors Cullen, with a phone number of +1 408 555 1212 is using skype.com to call Jon at "sip:jon@example.org". Both people use a WebRTC softphone. Cullen uses an identity provider of att.com. Skype could be the identity provider for this use case but it's easier to understand the flow if you look at it as a separate provider. Before the call ever starts, Cullen's browser fetches the webpage from skype.com and logs on to that website. Cullen then goes to call Jon. The skype JS notes that the Cullen's identity provider is att.com and the JavaScript for the skype web page does a pc.setIdentityProvider("att.com","passport", JSON.stringify( {"otn": "14085551212", "duri": "sip:jon@example.org"})); And start the setup of media to the other side which will eventually generate an SDP offer. The browser will load the IDP JS from IdP at https://att.com/.well-known/idp-proxy/passport (see section 5.6.5 of [I-D.ietf-rtcweb-security-arch]) The browser will then call the IDP javascript code to generate a WebRTC identity assertion. It will pass to the generating function the hint information provided in the setIdentityProvider of { "otn": "14084219990", "duri": "sip:jon@example.org" } The browser also passes the DTLS fingerprints and hash algorithm used to generate them to the JS for the IdP in an array like [ { "algorithm":"sha-256", "digest":"23:E8:6E:28:3F:D1:CF:17:DE:88:0F:EE:5A:AB: AD:03:2D:77:FB:05:17:BA:61:12:1B:37:D4:19:4F:38:DF:EC" } ] All of this information can be sent to the idp.com along with the whatever login flow att.com wants to use to have Cullen authenticated to att.com At this point, the IdP has all the information to create the Passport Token. Jennings Expires November 10, 2016 [Page 3] Internet-Draft WebRTC and STIR Identity May 2016 The DTLS-SRTP fingerprints are reformatted to be in the form "mky": "sha-256 23:E8:6E:28:3F:D1:CF:17:DE:88:0F:EE:5A:AB: AD:03:2D:77:FB:05:17:BA:61:12:1B:37:D4:19:4F:38:DF:EC" The passport header is set to { "typ":"passport", "alg":"RS256", "x5u":"https://cert.att.org/passport.crt" } The current time is used for the iat field and a passport payload is formed. Note the payload also gets called the claims. For example, the payload could look like { "iat":"14443208345", "otn":"14084219990", "duri":"sip:jon@example.org", "mky":"sha-256 23:E8:6E:28:3F:D1:CF:17:DE:88:0F:EE:5A:AB: AD:03:2D:77:FB:05:17:BA:61:12:1B:37:D4:19:4F:38:DF:EC" } This is canonicalized and signed with a certificate valid to sign 14084219990. The URL to fetch the certificate is found in the x5u field of the Passport Header. The canonical headers base64 is eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IlJTMjU2IiwieDV1IjoiaHR0cHM6Ly9jZXJ0 LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9 The canonical payload in base64 is eyJpYXQiOiIxNDQ0MzIwODM0NSIsIm90biI6IjE0MDg0MjE5OTkwIiwiZHVyaSI6InNp cDpqb25AZXhhbXBsZS5vcmciLCJta3kiOiJzaGEtMjU2IDIzOkU4OjZFOjI4OjNGOkQx OkNGOjE3OkRFOjg4OjBGOkVFOjVBOkFCOkFEOjAzOjJEOjc3OkZCOjA1OjE3OkJBOjYx OjEyOjFCOjM3OkQ0OjE5OjRGOjM4OkRGOkVDIn0 The base64 headers and payload are concatenated with a period between them and the SHA 256 of the result is computed which, represented in hex, is 20ac9439ae10df640b39e177d4ec432fe590b2d95f4075957816b5929ca1acb0 Jennings Expires November 10, 2016 [Page 4] Internet-Draft WebRTC and STIR Identity May 2016 This is signed using RSASSA-PKCS1-v1_5 to get a base64 encoded signature of FMgDzm0ZLV3w-6yOSCm3ZorSwEednS38XtF2u29NhRQ5zh8Swh0uSGHASXFwUIQ7DXvG 4pKD1rbBLFYT3_ReDn6OJ36k0S3oNvwMD0FyrRYeji-pAjoh76Q-jsfJsOq-Pi35Fba8 ZYRvG_EgLE0FYXuM2nWm85RUKVSnkx5MBpOxuUxRyTZYJpaQjElVpv9MJKfd_HyuF66q 98tcqeDb8dlrjtPNnQQfOf6AyLTlRwJ64t7iTouGD_R85Lv4Hu4mwu2ZiOL_1jo5svoY -KegM1KJh-M_ux4J52NoVeeLLgKg585qUHLrln6aEjevNQLBUcbdf_DKZ1hyj0oFR9lx rw The above example was done with and RSA key size of 2048 bits. The headers, payload, and signature are concatenated with pereidos between then to form a Passport Token of the form (but with no line breaks) eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IlJTMjU2IiwieDV1IjoiaHR0cHM6Ly9jZXJ0 LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9. eyJpYXQiOiIxNDQ0MzIwODM0NSIsIm90biI6IjE0MDg0MjE5OTkwIiwiZHVyaSI6InNp cDpqb25AZXhhbXBsZS5vcmciLCJta3kiOiJzaGEtMjU2IDIzOkU4OjZFOjI4OjNGOkQx OkNGOjE3OkRFOjg4OjBGOkVFOjVBOkFCOkFEOjAzOjJEOjc3OkZCOjA1OjE3OkJBOjYx OjEyOjFCOjM3OkQ0OjE5OjRGOjM4OkRGOkVDIn0. FMgDzm0ZLV3w-6yOSCm3ZorSwEednS38XtF2u29NhRQ5zh8Swh0uSGHASXFwUIQ7DXvG 4pKD1rbBLFYT3_ReDn6OJ36k0S3oNvwMD0FyrRYeji-pAjoh76Q-jsfJsOq-Pi35Fba8 ZYRvG_EgLE0FYXuM2nWm85RUKVSnkx5MBpOxuUxRyTZYJpaQjElVpv9MJKfd_HyuF66q 98tcqeDb8dlrjtPNnQQfOf6AyLTlRwJ64t7iTouGD_R85Lv4Hu4mwu2ZiOL_1jo5svoY -KegM1KJh-M_ux4J52NoVeeLLgKg585qUHLrln6aEjevNQLBUcbdf_DKZ1hyj0oFR9lx rw The IdP returns this to the IdP JS in the browser which forms an object like Jennings Expires November 10, 2016 [Page 5] Internet-Draft WebRTC and STIR Identity May 2016 { "assertion": "eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IlJTMjU2IiwieDV1IjoiaHR0cHM6Ly9jZXJ0 LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9. eyJpYXQiOiIxNDQ0MzIwODM0NSIsIm90biI6IjE0MDg0MjE5OTkwIiwiZHVyaSI6InNp cDpqb25AZXhhbXBsZS5vcmciLCJta3kiOiJzaGEtMjU2IDIzOkU4OjZFOjI4OjNGOkQx OkNGOjE3OkRFOjg4OjBGOkVFOjVBOkFCOkFEOjAzOjJEOjc3OkZCOjA1OjE3OkJBOjYx OjEyOjFCOjM3OkQ0OjE5OjRGOjM4OkRGOkVDIn0. FMgDzm0ZLV3w-6yOSCm3ZorSwEednS38XtF2u29NhRQ5zh8Swh0uSGHASXFwUIQ7DXvG 4pKD1rbBLFYT3_ReDn6OJ36k0S3oNvwMD0FyrRYeji-pAjoh76Q-jsfJsOq-Pi35Fba8 ZYRvG_EgLE0FYXuM2nWm85RUKVSnkx5MBpOxuUxRyTZYJpaQjElVpv9MJKfd_HyuF66q 98tcqeDb8dlrjtPNnQQfOf6AyLTlRwJ64t7iTouGD_R85Lv4Hu4mwu2ZiOL_1jo5svoY -KegM1KJh-M_ux4J52NoVeeLLgKg585qUHLrln6aEjevNQLBUcbdf_DKZ1hyj0oFR9lx rw", "idp":{ "domain":"https://ks.fluffy.im:10443", "protocol":"passport" } } This object is passed back into the browser user agent which base 64 encodes adds it to the SDP in an header like a=identity:eyJhc3NlcnRpb24iOiJleUowZVhBaU9pSndZWE56Y0c5eWRDSXNJbUZzW nlJNklsSlRNalUySWl3aWVEVjFJam9pYUhSMGNITTZMeTlqWlhKMExtVjRZVzF3YkdVd WIzSm5MM0JoYzNOd2IzSjBMbU55ZENKOS5leUpwWVhRaU9pSXhORFEwTXpJd09ETTBOU 0lzSW05MGJpSTZJakUwTURnME1qRTVPVGt3SWl3aVpIVnlhU0k2SW5OcGNEcHFiMjVBW lhoaGJYQnNaUzV2Y21jaUxDSnRhM2tpT2lKemFHRXRNalUySURJek9rVTRPalpGT2pJN E9qTkdPa1F4T2tOR09qRTNPa1JGT2pnNE9qQkdPa1ZGT2pWQk9rRkNPa0ZFT2pBek9qS kVPamMzT2taQ09qQTFPakUzT2tKQk9qWXhPakV5T2pGQ09qTTNPa1EwT2pFNU9qUkdPa k00T2tSR09rVkRJbjAuRk1nRHptMFpMVjN3LTZ5T1NDbTNab3JTd0VlZG5TMzhYdEYyd TI5TmhSUTV6aDhTd2gwdVNHSEFTWEZ3VUlRN0RYdkcNCjRwS0QxcmJCTEZZVDNfUmVEb jZPSjM2azBTM29OdndNRDBGeXJSWWVqaS1wQWpvaDc2US1qc2ZKc09xLVBpMzVGYmE4W llSdkdfRWdMRTBGWVh1TTJuV204NVJVS1ZTbmt4NU1CcE94dVV4UnlUWllKcGFRakVsV nB2OU1KS2ZkX0h5dUY2NnE5OHRjcWVEYjhkbHJqdFBOblFRZk9mNkF5TFRsUndKNjR0N 2lUb3VHRF9SODVMdjRIdTRtd3UyWmlPTF8xam81c3ZvWVxLZWdNMUtKaE1fdXg0SjUyT m9WZWVMTGdLZzU4NXFVSExybG42YUVqZXZOUUxCVWNiZGZfREtaMWh5ajBvRlI5bHhyd yIsImlkcCI6eyJkb21haW4iOiJodHRwczovL2tzLmZsdWZmeS5pbToxMDQ0MyIsInByb 3RvY29sIjoicGFzc3BvcnQifX0= Which adds about 1K bytes to the SIP message. 2.2. Mapping to SIP A RTCWeb to SIP Gateway can take this assertion, decode it, and extract the Passport Token out of it. It could then insert that into the SIP Invite. It would need to cache the domain and protocol for this flow. Later when a reply came back it, it could take the Jennings Expires November 10, 2016 [Page 6] Internet-Draft WebRTC and STIR Identity May 2016 Passport token in the Identity and create a new assertion using the cached domain and protocol and insert that. This is really gross and we need to figure out a way where the SDP from SIP is the same as the SDP from WebRTC when using the same passport token. 3. Proposed Changes 3.1. Remove Identity Hint Hack Passing JSON.stringify({"otn":"14084219990", "duri":"sip:jon@example.org"}) is sort of a hack. It would be better to pass "14084219990" as the identity hint and have the API support an optional destination hint where we pass "sip:jon@example.org" 3.2. Fingerprint format. Unify the format of the fingerprints between STIR and WebRTC. Proposal move to something more like { "alg":"HS256", "digest":"23:E8:6E:28:3F:D1:CF:17:DE:88:0F:EE:5A:AB: AD:03:2D:77:FB:05:17:BA:61:12:1B:37:D4:19:4F:38:DF:EC" } And perhaps choose a more compact for the digest value - preferably base 64. 3.3. Format of identity header 3.3.1. Token type in Identity header to allow multiple identity headers Have the type of identity token in a standard form outside the actual token so that things that don't understand the token still know what it is So the Identity line would change from something like a=identity:eyJhc3NlNzcG9ydHYxIn19;info=URL to a=identity:eyJhc3NlNzcG9ydHYxIn19;info=URL;type=passport Jennings Expires November 10, 2016 [Page 7] Internet-Draft WebRTC and STIR Identity May 2016 3.3.2. WebRTC support multiple tokens Nice to allow multiple IdP that produce different token types for a given offer in WebRTC. If the SDP had multiple tokens of different types, do we need WebRTC to be able to support this. 3.3.3. Abstract the identity and protocol in the WebRTC assertion Currently the WebRTC token has to have the domain and protocol in a well defined location in the assertion. But when this is represented into SDP, it might be better to have it as optional tags on the Identity line instead of in the actual token. So the Identity line would change from something like a=identity:eyJhc3NlNzcG9ydHYxIn19 to a=identity:eyJhc3NlNzcG9ydHYxIn19; domain=https://ks.fluffy.im:10443;protocol=passport This would allow systems using passport identity to have the same SDP regardless of it the SDP was for WebRTC or SIP This would also Passport Tokens generated in SIP to work for WebRTC 3.4. Future Proofing WebRTC allows future things to be added to the contents object passed to the IdP JS. They have to be conveyed to the far side (see section 5.6.4 of [I-D.ietf-rtcweb-security-arch]). Proposal. Copy them into the claims in the passport token. 3.5. TEL URI For single phone numbers, we already have a way to encode that in certificates using the SAN with a URI containing a tel URI. Proposal. Allow existing cert to be valid STIR certificates. 3.6. RFC822 Names Consider an WebRTC endpoint that initiates a call using WebRTC that is then translated to SIP then translated to XMPP to deliver it to the far end user. Using a name like "sip:fluffy@example.com" is Jennings Expires November 10, 2016 [Page 8] Internet-Draft WebRTC and STIR Identity May 2016 pretty weird at the WebRTC and XMPP end. It might be better to use 822 style names instead of URIs. If this was done, it would likely need to use the work that extends the current X509 specifications to allow i18n names. (For example see [I-D.lbaudoin-iemax] ) 3.7. Encoding We start with a fingerprint in binary and encoding it like "AA:BB:CC" resulting in an expansion of 3 times. It then expands 1.3 times in the base64 encoding of the payload when then expands 1.3 times in the base64 encoding of the identity header making it over 5 times larger than the original. 3.8. WebRTC Canonical Form Ensure the definition of what goes in the WebRTC assertion content array is well specified. Ensure it does not need to be bitwise exact but only the same when compared at JS object level. 3.9. Multi party For a conference call or group MMS, we need to allow multiple destinations. Proposal: making the duri a list. 4. Acknowledgments Thank you to Russ Housley for comments. 5. References 5.1. Normative References [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-11 (work in progress), March 2015. [I-D.ietf-stir-certificates] Peterson, J., "Secure Telephone Identity Credentials: Certificates", draft-ietf-stir-certificates-03 (work in progress), March 2016. Jennings Expires November 10, 2016 [Page 9] Internet-Draft WebRTC and STIR Identity May 2016 [I-D.ietf-stir-passport] Wendt, C. and J. Peterson, "Persona Assertion Token", draft-ietf-stir-passport-01 (work in progress), March 2016. [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-08 (work in progress), March 2016. 5.2. Informative References [I-D.lbaudoin-iemax] Baudoin, L., Chuang, W., and N. Lidzborkski, "Internationalized Electronic Mail Addresses in RFC5280 / X.509 Certificates", draft-lbaudoin-iemax-02 (work in progress), February 2016. Appendix A. Example Cert The cert used to generat the examples is: -----BEGIN CERTIFICATE----- MIIDOzCCAiOgAwIBAgIJANgkZSg8VNNEMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNV BAYTAkNBMQ8wDQYDVQQIDAZBbGJydGExEDAOBgNVBAcMB0NhbGdhcnkxDzANBgNV BAsMBkZsdWZmeTAeFw0xNjA1MDIyMjUxMjZaFw0yNjA0MzAyMjUxMjZaMEExCzAJ BgNVBAYTAkNBMQ8wDQYDVQQIDAZBbGJydGExEDAOBgNVBAcMB0NhbGdhcnkxDzAN BgNVBAsMBkZsdWZmeTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKhn +91RRdt29jwXrUwkAthRA2LQ7UP5bfEy8CpJcgNHEQDryoLQJmQQsP0Hi5qf6CJA dWW3+vmfKZHhbsDblI8iVCMhekKr/kbplMLSJFdNEkg/cWM3BKBVuqMmmArdpki9 62TmHkO2g+Fk+nubmsB8EDhXvp+TLO1mf1mT6vIUW+U5WVTeghLz8YO+kUjrS0fW +GWD2lrgEMwvHfuUeBsTD48elXDDPhRAFrB5+TF044Y5+F1lS4iqpD7d1e2rw/YQ VrHOTJot5T6H33vSvVGGtTZqqDKdTDhCGISb95/IDYSMGT67OoJSlG6/VDyI643V g0tXkEN2N+TWBv+zDT0CAwEAAaM2MDQwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAw GgYDVR0RBBMwEYYPdGVsOjE0MDg0MjE5OTkwMA0GCSqGSIb3DQEBCwUAA4IBAQBT g/mt3vzs7pTsFCTgNA49vPae+M4IPPqgqfuGPzpCPhzYYnly5EiZYoSaFtYJJiUA 6Hwna0n7SVZdLwHEx7uOk3HHEdjAw8RIf4xSSdjv+IWDDyLl5fLVxyPqnJAAvQ9k bOV25stTbbKz0EEXV/VKe7A5bILxc2e+JUKjarff2aAEfO8mk+fSVsn5DnBJk3kS kn8oGaYy5T+5HjdanOfR9ZIZBwTi7XIieSHUzuA7ax5QNugLEgUDPsus1BBxr5Bd A/HwL0pU7iO4/Hsx1QeNBXy/34yC4n5OCFI5FmfOB+VmJWbDmilH6+uByj339Ii2 2zMX9jtye/So5f5PGlRE -----END CERTIFICATE----- which contains Certificate: Data: Jennings Expires November 10, 2016 [Page 10] Internet-Draft WebRTC and STIR Identity May 2016 Version: 3 (0x2) Serial Number: d8:24:65:28:3c:54:d3:44 Signature Algorithm: sha256WithRSAEncryption Issuer: C = CA, ST = Albrta, L = Calgary, OU = Fluffy Validity Not Before: May 2 22:51:26 2016 GMT Not After : Apr 30 22:51:26 2026 GMT Subject: C = CA, ST = Albrta, L = Calgary, OU = Fluffy Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a8:67:fb:dd:51:45:db:76:f6:3c:17:ad:4c:24: 02:d8:51:03:62:d0:ed:43:f9:6d:f1:32:f0:2a:49: 72:03:47:11:00:eb:ca:82:d0:26:64:10:b0:fd:07: 8b:9a:9f:e8:22:40:75:65:b7:fa:f9:9f:29:91:e1: 6e:c0:db:94:8f:22:54:23:21:7a:42:ab:fe:46:e9: 94:c2:d2:24:57:4d:12:48:3f:71:63:37:04:a0:55: ba:a3:26:98:0a:dd:a6:48:bd:eb:64:e6:1e:43:b6: 83:e1:64:fa:7b:9b:9a:c0:7c:10:38:57:be:9f:93: 2c:ed:66:7f:59:93:ea:f2:14:5b:e5:39:59:54:de: 82:12:f3:f1:83:be:91:48:eb:4b:47:d6:f8:65:83: da:5a:e0:10:cc:2f:1d:fb:94:78:1b:13:0f:8f:1e: 95:70:c3:3e:14:40:16:b0:79:f9:31:74:e3:86:39: f8:5d:65:4b:88:aa:a4:3e:dd:d5:ed:ab:c3:f6:10: 56:b1:ce:4c:9a:2d:e5:3e:87:df:7b:d2:bd:51:86: b5:36:6a:a8:32:9d:4c:38:42:18:84:9b:f7:9f:c8: 0d:84:8c:19:3e:bb:3a:82:52:94:6e:bf:54:3c:88: eb:8d:d5:83:4b:57:90:43:76:37:e4:d6:06:ff:b3: 0d:3d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Subject Alternative Name: URI:tel:14084219990 Signature Algorithm: sha256WithRSAEncryption 53:83:f9:ad:de:fc:ec:ee:94:ec:14:24:e0:34:0e:3d:bc:f6: 9e:f8:ce:08:3c:fa:a0:a9:fb:86:3f:3a:42:3e:1c:d8:62:79: 72:e4:48:99:62:84:9a:16:d6:09:26:25:00:e8:7c:27:6b:49: fb:49:56:5d:2f:01:c4:c7:bb:8e:93:71:c7:11:d8:c0:c3:c4: 48:7f:8c:52:49:d8:ef:f8:85:83:0f:22:e5:e5:f2:d5:c7:23: ea:9c:90:00:bd:0f:64:6c:e5:76:e6:cb:53:6d:b2:b3:d0:41: 17:57:f5:4a:7b:b0:39:6c:82:f1:73:67:be:25:42:a3:6a:b7: df:d9:a0:04:7c:ef:26:93:e7:d2:56:c9:f9:0e:70:49:93:79: Jennings Expires November 10, 2016 [Page 11] Internet-Draft WebRTC and STIR Identity May 2016 12:92:7f:28:19:a6:32:e5:3f:b9:1e:37:5a:9c:e7:d1:f5:92: 19:07:04:e2:ed:72:22:79:21:d4:ce:e0:3b:6b:1e:50:36:e8: 0b:12:05:03:3e:cb:ac:d4:10:71:af:90:5d:03:f1:f0:2f:4a: 54:ee:23:b8:fc:7b:31:d5:07:8d:05:7c:bf:df:8c:82:e2:7e: 4e:08:52:39:16:67:ce:07:e5:66:25:66:c3:9a:29:47:eb:eb: 81:ca:3d:f7:f4:88:b6:db:33:17:f6:3b:72:7b:f4:a8:e5:fe: 4f:1a:54:44 Appendix B. Example Private Key The private key for the cert is: -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAqGf73VFF23b2PBetTCQC2FEDYtDtQ/lt8TLwKklyA0cRAOvK gtAmZBCw/QeLmp/oIkB1Zbf6+Z8pkeFuwNuUjyJUIyF6Qqv+RumUwtIkV00SSD9x YzcEoFW6oyaYCt2mSL3rZOYeQ7aD4WT6e5uawHwQOFe+n5Ms7WZ/WZPq8hRb5TlZ VN6CEvPxg76RSOtLR9b4ZYPaWuAQzC8d+5R4GxMPjx6VcMM+FEAWsHn5MXTjhjn4 XWVLiKqkPt3V7avD9hBWsc5Mmi3lPoffe9K9UYa1NmqoMp1MOEIYhJv3n8gNhIwZ Prs6glKUbr9UPIjrjdWDS1eQQ3Y35NYG/7MNPQIDAQABAoIBAF6ELdmi+aAY/k3v w/WN6ILbxRi6xc92uHu86QnyuqiYRDTOIZSVmlZi/9KjX3ji8nf20WzLe3KKH9ye N3jKRHCpBavJ6EJvIYFPK4zEQF03BmHCKbNTd6c9NkjHKmI+0ErXPLweYzIBx7bC 48poJMyPVNMqe/Q3t+lts1/lIuHGHhdnSn7ao6hP+xE7V+PMXic1f/hL7WwpCUvt N0IQp4sgqbrZwfVaGtkDSrzdYELYQb9QHEiMGoYg6oC7uGMoX1zi5B52BRP8MArA 9htEx4r9bAFCBX/lvQkq3QP5Pg6okhAB2eqEk2zUzUJlfHC1kr6aw8744potJmJW ZiOdzkECgYEA2S8aw+CI6h9T07BBbX+xFqQhUot0ngeErW49BgvrOLwLEacI9ofb b4BkNGzcFMejAk2fqRfhwwu53Y8+5u+xMrw3pC/lvrDjFNaXD3nILr1PdlAE/hee hMkb60HQFYSoG6ZcdbqSeYkp1fn5TsN7tAhQT21NVxEWb4J9az02LrkCgYEAxoEh gfczbkFM/dDiCXg2R9LxKTNwiZD2iugVLV0kML4zJryk5/QVK5wumOtZpjfJzVi3 hC0jL7gzhHUymfo6owG72S5qiodbdkhHqpqODVlCLgY+3VTBBiomLO9YWSYzW6QO sOQCA+dwBuL/6IEY4rFX6x/AL8sh4JSXYjcGcKUCgYEA0FKVmtOyoNgh4UkMyUqV hAE1kWcBGmBdzLmUQUuHeikteOY++7K/Mon2FC9jP29rFdd9UYX94MhLpZE0pfG+ h8rwmEX1Wt9zQlbAGXEYKnUeVn9U+qGPRRFe/V9oiGtxkOwXfjnTLE78WSppEDsE WmErH7TZXa2fVqDVStsxMMkCgYBMgPQTDNzLf2tW3yxejfANmmTLhkG3IyGBw5R1 2VHbX1KDeWzs4ItQNW9YDEyO3S1vcOO5k1PeTlW8lRaddW0n6cEmINd68FP1sEG+ pLZeuqng5xNPZhzGbXQtGUmpgimFBiOLVTTZoFbysIYEa8zVgZfqzF/bi6RQ07PM bHyU6QKBgQDYCytiEWCz7vKoSRjE5vng3eNRVtYbbe8AiJv6qjYz8rOosJEMDoMV vPOREdf2EkXdOODvgqCjh0HDCP112qyoMoQB/PC9ihum4ZTZn1KUI5Rj0GHc1GwW d8jDOR91y0tjvnLQv37RLe4j9327ism0cf8NSlMe4tsWJocF6JYNoA== -----END RSA PRIVATE KEY----- Author's Address Cullen Jennings Cisco Systems Email: fluffy@iii.ca Jennings Expires November 10, 2016 [Page 12]