RFC 6072
Certificate Management Service for the Session Initiation Protocol (SIP)
RFC 6072: Certificate Management Service for the Session Initiation Protocol (SIP) 🎀
okay bestie, this is the header info you need to know first 💅
- Authors: C. Jennings from Cisco Systems, and J. Fischl (Ed.) from Skype 🫶
- Category: Standards Track ✨
- ISSN: 2070-1721
- Date: February 2011 📅
- Obsoletes / Updates: this header doesn't list any RFCs that it obsoletes or updates 🦋
Abstract 💖
so this doc defines a credential service that lets SIP User Agents (UAs) use a SIP event package to find other users' certificates 🔍 A UA that wants to contact a given Address-of-Record (AOR) can grab that AOR's certificate by subscribing to the credential service, and the service sends back an authenticated response with the cert inside 🎀 The service also lets users store and retrieve their own certificates and private keys 🔐
Status of This Memo 🌸
this is an Internet Standards Track document 💅
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅ If you want more on Internet Standards, check Section 2 of RFC 5741 📚
for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6072 🦋
Copyright Notice 🌈
Copyright (c) 2011 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) as they're in effect on the date of publication 📜 Please actually read these, bestie, because they explain your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚖️
this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🕰️ The people who control the copyright in some of that older material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😬 So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 🚫 The one exception is formatting it for publication as an RFC, or translating it into languages other than English 🌍
Table of Contents 📚
1. Introduction ....................................................3
2. Definitions .....................................................4
3. Overview ........................................................4
4. UA Behavior with Certificates ...................................7
5. UA Behavior with Credentials ....................................8
6. Event Package Formal Definition for "certificate" ...............9
6.1. Event Package Name .........................................9
6.2. SUBSCRIBE Bodies ...........................................9
6.3. Subscription Duration .....................................10
6.4. NOTIFY Bodies .............................................10
6.5. Subscriber Generation of SUBSCRIBE Requests ...............10
6.6. Notifier Processing of SUBSCRIBE Requests .................11
6.7. Notifier Generation of NOTIFY Requests ....................11
6.8. Subscriber Processing of NOTIFY Requests ..................11
6.9. Handling of Forked Requests ...............................11
6.10. Rate of Notifications ....................................12
6.11. State Agents and Lists ...................................12
6.12. Behavior of a Proxy Server ...............................12
7. Event Package Formal Definition for "credential" ...............12
7.1. Event Package Name ........................................12
7.2. SUBSCRIBE Bodies ..........................................12
7.3. Subscription Duration .....................................12
7.4. NOTIFY Bodies .............................................13
7.5. Subscriber Generation of SUBSCRIBE Requests ...............13
7.6. Notifier Processing of SUBSCRIBE Requests .................14
7.7. Notifier Generation of NOTIFY Requests ....................14
7.8. Generation of PUBLISH Requests ............................15
7.9. Notifier Processing of PUBLISH Requests ...................15
7.10. Subscriber Processing of NOTIFY Requests .................16
7.11. Handling of Forked Requests ..............................16
7.12. Rate of Notifications ....................................16
7.13. State Agents and Lists ...................................16
7.14. Behavior of a Proxy Server ...............................16
8. Identity Signatures ............................................16
9. Examples .......................................................17
9.1. Encrypted Page Mode Instant Message .......................17
9.2. Setting and Retrieving UA Credentials .....................18
10. Security Considerations .......................................19
10.1. Certificate Revocation ...................................21
10.2. Certificate Replacement ..................................22
10.3. Trusting the Identity of a Certificate ...................22
10.3.1. Extra Assurance ...................................23
10.4. SACRED Framework .........................................24
10.5. Crypto Profiles ..........................................24
10.6. User Certificate Generation ..............................25
10.7. Private Key Storage ......................................25
10.8. Compromised Authentication Service .......................26
11. IANA Considerations ...........................................26
11.1. Certificate Event Package ................................27
11.2. Credential Event Package .................................27
11.3. Identity Algorithm .......................................27
12. Acknowledgments ...............................................27
13. References ....................................................28
13.1. Normative References .....................................28
13.2. Informative References ...................................291. Introduction ✨
okay so [RFC3261], as amended by [RFC3853], gives you end-to-end encryption and integrity using Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751] 🔐 A bunch of [RFC3261]'s security properties depend on S/MIME, and yet it's not widely deployed 😭 The big reason is that setting up a reasonable certificate distribution infrastructure is seriously complicated 💀
so this spec proposes a way to handle discovery, retrieval, and management of certificates for SIP deployments 🎀 Paired with the SIP Identity [RFC4474] spec, users can have certificates that aren't signed by any well known certification authority, and the user's identity is still strongly bound to the certificate 🫶
it also gives SIP User Agents like IP phones a way to enroll and get their credentials without any more configuration info than they commonly have today ✨ The end user expends no extra effort 💅
2. Definitions 🦋
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖
Certificate: a Public Key Infrastructure using X.509 (PKIX)-[RFC5280] style certificate containing a public key and a list of identities in the SubjectAltName that are bound to this key 🔑 The certificates discussed in this document are generally self-signed, and they use the mechanisms in the SIP Identity [RFC4474] specification to vouch for their validity 🧚 Certificates signed by a certification authority can also be used with all the mechanisms in this document 🌸 However, the receiver doesn't need to validate them, although the receiver can validate them for extra assurance (see Section 10.3.1) 💜
Credential: for this document, "credential" means the combination of a certificate and the associated private key 🎀
Password Phrase: a password used to encrypt and decrypt a PKCS #8 (Public Key Cryptographic System #8) private key 🔐
3. Overview ✨
okay so bestie, let's talk about the big picture 🦋 the whole idea is a brand new SIP service called a "credential service" 🎀 and it lets SIP User Agents (UAs) subscribe to other people's certificates using a new SIP event package [RFC3265] 💖 the certificate gets delivered to the subscriber inside a matching SIP NOTIFY request 📬
now the trust part is giving main character energy 👑 an authentication service from the SIP Identity [RFC4474] spec can vouch for who sent the certificate 🔐 it does this by signing the NOTIFY request with the sender's proxy domain certificate 🫶 the authentication service is basically saying "yep, this sender is allowed to fill in the SIP From header field value" 💅 and the sender is saying "this is a legit certificate for the user in that From header" 🌸
the credential service can store public certificates AND the user's private keys 🗝️ users can update their credentials with a SIP PUBLISH [RFC3903] request 📝 when a UA is updating a credential it authenticates to the credential service with a shared secret 🤫 and honestly? that's usually the same shared secret the UA already uses to REGISTER with the domain's Registrar, typically through SIP Digest Authentication 🔑 so no extra password drama 🙈
here's the flow, Bob publishing from one device (say his laptop 💻), grabbing his stuff back on another (his phone 📱), and then Alice fetching Bob's cert and messaging him 💌 the SIP 200-class responses got left out so the diagram is easier to read ✨
example.com domain
------------------
Alice Proxy Auth Cred Bob1 Bob2
| | | | TLS Handshake | |
| [ Bob generates ] |<--------------------->|
| [ credentials and ] | PUBLISH (credential) |
| [ publishes them ] |<----------------------|
| | | | Digest Challenge |
| | | |---------------------->|
| | | | PUBLISH + Digest |
| | | |<----------------------|
| | | | |
| | | | time passes... |
| | | | |
| | | | TLS Handshake |
| [ Bob later gets ] |<---------------->|
| [ back his own ] | SUBSCRIBE |
| [ credentials ] | (credential) |
| [ at another ] |<-----------------|
| [ User Agent ] | SUBSCRIBE+Digest |
| | | |<-----------------|
| | | | NOTIFY |
| | | |----------------->|
| | | | Bob decrypts key |
| | | | |
| | | | |
| SUBSCRIBE (certificate) | Alice fetches |
|---------->|----->|----->| Bob's cert |
| | |NOTIFY| |
| NOTIFY+Identity |<-----| |
|<----------+------| | Alice uses cert |
| | | | to encrypt |
| MESSAGE | | | message to Bob |
|---------->|------+------+----------------->|Bob's UA (Bob2) does a Transport Layer Security (TLS) [RFC5246] handshake with the credential server 🔒 so it knows it's talking to the correct credential server 👀 then Bob2 publishes its brand new or updated credentials 🎁 the credential server throws a Digest Authentication challenge to make sure the UA actually knows Bob's shared secret 🕵️ once the UA passes, the credential server stores Bob's credentials 💾
Bob's other UA (Bob1) wants its current credentials back 📲 it does its own TLS [RFC5246] handshake to confirm it's on the correct credential server 🔐 then it subscribes for the credentials 📥 the credential server challenges it to prove it knows the shared secret 🙋♀️ once that's done, the server sends a NOTIFY carrying Bob's credentials 🎉 the private key part may have been encrypted with a secret that only Bob's UA knows (not the credential server!) 🤐 so once Bob's UA decrypts the private key, it's ready to go 🚀 and typically Bob's UA does this when it first registers on the network 🌟
later on Alice wants Bob's certificate, either so she can send him an encrypted message or verify a signature he sent 💌 her UA sends a SUBSCRIBE to Bob's AOR 📨 the proxy in Bob's domain routes it to the credential server through an "authentication service" as defined in [RFC4474] 🛣️ the credential server replies with a NOTIFY containing Bob's public certificate in the body 🎀 that goes through an authentication service which signs off that this message really can claim to be from the AOR "sip:bob@example.com" ✅ and Alice's UA gets the certificate and can encrypt a message to Bob 🥰
It is critical to understand that the only way that Alice can trust that the certificate really is the one for Bob and that the NOTIFY has not been spoofed is for Alice to check that the Identity [RFC4474] header field value is correct. 🚨
the mechanism works for both self-signed certificates and certificates signed by well known certification authorities 🌈 to deploy the CA-signed kind, certification authorities would have to support adding SIP URIs to the SubjectAltName of the certificates they generate 📜 which is something commercial CAs have rarely implemented 😬 however, most UAs would only use self-signed certificates and would use an authentication service as described in [RFC4474] to tie an AOR to the certificates strongly 💪
this mechanism allows for three different styles of deployment 🧁
- deployments where the credential server only stores certificates and never stores any private key information 🙅♀️ if the user has multiple devices, some other scheme (maybe even manual provisioning) would be needed to get the right private keys onto every device 📱💻
- deployments where the credential server stores certificates AND an encrypted version of the private keys 🔐 the credential server wouldn't know or need the password phrase for decrypting the private key 🙈 it helps move the private keys between devices, but the user has to type a password phrase on each device so that device can decrypt (and encrypt) the private key info 🔓
- deployments where the credential server generates and stores the certificates and private keys 🏭 these may not use password phrases, so the private keys are not encrypted inside the PKCS #8 objects 😳 this style would often have the credential server, instead of the devices, create the credentials 🧚
4. UA Behavior with Certificates ✨
okay now let's talk about what the UA actually does with certs 💅 when a UA wants to find someone's certificate, it subscribes to the "certificate" SIP event package described in Section 6 🎀 while that subscription is active, if the certificate gets updated, the Subscriber gets the updated certificate in a notification 🔔
the Subscriber needs to decide how long it's willing to trust that the certificate it got is still valid ⏳ if the certificate is revoked before it expires, the Notifier sends a notification with an empty body to say "nope, not valid anymore" 🚫 if the certificate is renewed before it expires, the Notifier sends a notification with a body holding the new certificate 💖 heads up though: the Subscriber might not get that notification if an attacker blocks the traffic 😱 the amount of time the Subscriber caches a certificate SHOULD be configurable ⚙️ a default of one day is RECOMMENDED 📅
now the subscription duration and the caching or validity time of the certificate are totally separate things 🙅♀️ letting subscriptions stick around after a certificate stops being valid makes sure Subscribers get the replacement certificate in a timely way 🏃♀️ the Notifier could send an immediate notification with the certificate in response to a subscribe request, then end the subscription right away with the reason parameter set to "probation" 🎬 after that the Subscriber will have to poll the Notifier now and then to check the certificate is still valid 🔁
if the UA uses a cached certificate in a request and gets a 437 (Unsupported Certificate) response, it SHOULD remove that certificate from the cache and try fetching it again 🗑️ if the certificate changed, then the UA SHOULD retry the original request with the new one 🔄 this usually means the certificate was recently updated and the Subscriber never got the matching notification 📭 but if the fetched certificate is the same as the one that was already cached, the UA SHOULD NOT try the request again 🙅♀️ that can happen when the request gets retargeted to a different user than the original request 😵💫 the 437 response is defined in [RFC4474] 📖
Note: A UA that has a presence list MAY want to subscribe to the certificates of all the presentities in the list when the UA subscribes to their presence, so that when the user wants to contact a presentity, the UA already has the right certificate 🧚 future specifications might consider fetching the certificates along with the presence documents 🔮
the details of how a UA handles receiving encrypted messages are outside the scope of this spec 🙃 but it's worth noting that if Charlie's User Agent Server (UAS) gets a request encrypted to Bob, it would be valid and legal for that UA to send a 302 redirecting the call to Bob 📞✨
5. UA Behavior with Credentials 🔐
Okay so bestie, here's how a UA (user agent, aka your phone or app 📱) gets its own credentials. It discovers them by subscribing to its AOR with an event type of credential, which is spelled out in Section 7 💖. After a UA registers, it SHOULD retrieve its credentials by subscribing to them as described in Section 6.5. Literally the move 💅
When a UA discovers its credential, the private key information might be encrypted with a password phrase 🙈 The UA SHOULD ask the user to enter that password phrase on the device, and the UA MAY cache it for later use. Efficient and cute 🎀
There are a few different situations where a UA should generate a new credential:
- If the UA receives a NOTIFY with no body for the credential package.
- If the certificate has expired.
- If the certificate's
notAfterdate is within the next 600 seconds, the UA SHOULD attempt to create replacement credentials. It does this by waiting a random amount of time between 0 and 300 seconds. If no new credentials have been received in that time, the UA creates new credentials to replace the expiring ones and sends them in aPUBLISHrequest, following the rules for modifying event state as described in Section 4.4 of [RFC3903] ⏰ - If the user of the device has indicated via the user interface that they wish to revoke the current certificate and issue a new one.
Credentials get made by constructing a new key pair, which needs appropriate randomness as described in [RFC4086], and then creating a certificate as described in Section 10.6 ✨ The UA MAY encrypt the private key with a password phrase supplied by the user, as specified in Section 10.5. Next, the UA updates the user's credential by sending a PUBLISH [RFC3903] request with the credentials or just the certificate, as described in Section 7.8 🦋
If a UA wants to revoke the existing certificate without publishing a new one, it MUST send a PUBLISH with an empty body to the credential server. No replacement, just a clean goodbye 👋
6. Event Package Formal Definition for "certificate" 💜
6.1. Event Package Name
This document defines a SIP event package as defined in [RFC3265]. The event-package token name for this package is:
certificate 🌸
6.2. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. Nothing extra to send, very minimalist 🤍
6.3. Subscription Duration
Subscriptions to this event package can range from no time to weeks. Subscriptions in days are more typical and are RECOMMENDED. The default subscription duration for this event package is one day ⏳
The credential service is encouraged to keep the subscriptions active for AORs that are communicating frequently, but the credential service MAY terminate the subscription at any point in time 💫
6.4. NOTIFY Bodies
The body of a NOTIFY request for this package MUST either be empty or contain an application/pkix-cert body (as defined in [RFC2585]) that contains the certificate, unless an Accept header field has negotiated some other type. The Content-Disposition MUST be set to "signal" as defined in [RFC3204] 🎀
A future extension MAY define other NOTIFY bodies. If no Accept header field is present in the SUBSCRIBE, the body type defined in this document MUST be assumed 🧚
Implementations that generate large notifications are reminded to follow the message size restrictions for unreliable transports articulated in Section 18.1.1 of [RFC3261]. Big notifications, be careful bestie 😭
6.5. Subscriber Generation of SUBSCRIBE Requests
A UA discovers a certificate by sending a SUBSCRIBE request with an event type of "certificate" to the AOR for which a certificate is desired. In general, the UA stays subscribed to the certificate for as long as it plans to use and cache the certificate, so that the UA can be notified about changes or revocations to the certificate 🔔
Subscriber User Agents will typically subscribe to certificate information for a period of hours or days, and automatically attempt to re-subscribe just before the subscription is completely expired 🔁
When a user de-registers from a device (logoff, power down of a mobile device, etc.), Subscribers SHOULD unsubscribe by sending a SUBSCRIBE request with an Expires header field of zero. Tidy exit, no loose ends 🧹
6.6. Notifier Processing of SUBSCRIBE Requests
When a SIP credential server receives a SUBSCRIBE request with the certificate event-type, it is not necessary to authenticate the subscription request. The Notifier MAY limit the duration of the subscription to an administrator-defined period of time. The duration of the subscription does not correspond in any way to the period for which the certificate will be valid. Subscription length and cert lifetime are two separate things, bestie 🙅♀️
When the credential server receives a SUBSCRIBE request for a certificate, it first checks to see if it has credentials for the requested URI. If it does not have a certificate, it returns a NOTIFY request with an empty message body 🫥
6.7. Notifier Generation of NOTIFY Requests
Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current certificate, or an empty body if no certificate is available for the target user. In either case, it forms a NOTIFY with the From header field value set to the value of the To header field in the SUBSCRIBE request 📨
This server sending the NOTIFY needs either to implement an authentication service (as described in SIP Identity [RFC4474]) or else the server needs to be set up such that the NOTIFY request will be sent through an authentication service. Sending the NOTIFY request through the authentication service requires the SUBSCRIBE request to have been routed through the authentication service, since the NOTIFY is sent within the dialog formed by the subscription 🔐
6.8. Subscriber Processing of NOTIFY Requests
The resulting NOTIFY will contain an application/pkix-cert body that contains the requested certificate. The UA MUST follow the procedures in Section 10.3 to decide if the received certificate can be used. The UA needs to cache this certificate for future use. The maximum length of time for which it should be cached is discussed in Section 10.1. The certificate MUST be removed from the cache if the certificate has been revoked (if a NOTIFY with an empty body is received), or if it is updated by a subsequent NOTIFY 🗑️
The UA MUST check that the NOTIFY is correctly signed by an authentication service as described in [RFC4474]. If the identity asserted by the authentication service does not match the AOR that the UA subscribed to, the certificate in the NOTIFY is discarded and MUST NOT be used. Sus identity mismatch, toss it 🚫
6.9. Handling of Forked Requests
This event package does not permit forked requests. At most one subscription to this event type is permitted per resource 🦄
6.10. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per minute ⏱️
6.11. State Agents and Lists
The credential server described in this section that serves certificates is a state agent as defined in [RFC3265], and implementations of the credential server MUST be implemented as a state agent. Main character energy 👑
Implementers MUST NOT use the event list extension [RFC4662] with this event type. It is not possible to make such an approach work, because the authentication service would have to simultaneously assert several different identities. Not possible, not happening 🙅♀️
6.12. Behavior of a Proxy Server
There are no additional requirements on a SIP proxy, other than to transparently forward the SUBSCRIBE and NOTIFY requests as required in SIP. This specification describes the proxy, authentication service, and credential service as three separate services, but it is certainly possible to build a single SIP network element that performs all of these services at the same time 🧩
7. Event Package Formal Definition for "credential" 🌈
7.1. Event Package Name
This document defines a SIP event package as defined in [RFC3265]. The event-package token name for this package is:
credential 💖
7.2. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. Still no extras, still iconic 💅
7.3. Subscription Duration
Subscriptions to this event package can range from hours to one week. Subscriptions in days are more typical and are RECOMMENDED. The default subscription duration for this event package is one day 🗓️
The credential service SHOULD keep subscriptions active for UAs that are currently registered 🫶
7.4. NOTIFY Bodies
An implementation compliant to this specification MUST support the multipart/mixed type (see [RFC2046]). This allows a notification to contain multiple resource documents, including at a minimum the application/pkix-cert body with the certificate and an application/pkcs8 body that has the associated private key information for the certificate. The application/pkcs8 media type is defined in [RFC5958] 🧁
The absence of an Accept header in the SUBSCRIBE indicates support for multipart/mixed and the content types application/pkix-cert and application/pkcs8. If an Accept header is present, these types MUST be included, in addition to any other types supported by the client 📬
The application/pkix-cert body is a Distinguished Encoding Rules (DER)-encoded X.509v3 certificate [RFC2585]. The application/pkcs8 body contains a DER-encoded [RFC5958] object that contains the private key. The PKCS #8 objects MUST be of type PrivateKeyInfo. The integrity and confidentiality of the PKCS #8 objects are provided by the TLS transport. The transport encoding of all the MIME bodies is binary 🔒
7.5. Subscriber Generation of SUBSCRIBE Requests
A Subscriber User Agent will subscribe to its credential information for a period of hours or days, and will automatically attempt to re-subscribe before the subscription has completely expired 🔄
The Subscriber SHOULD subscribe to its credentials whenever a new user becomes associated with the device (a new login). The Subscriber SHOULD also renew its subscription immediately after a reboot, or when the Subscriber's network connectivity has just been re-established 🌤️
The UA needs to authenticate with the credential service for these operations. The UA MUST use TLS to directly connect to the server acting as the credential service or to a server that is authoritative for the domain of the credential service. The UA MUST NOT connect through an intermediate proxy to the credential service. The UA may be configured with a specific name for the credential service; otherwise, normal SIP routing is used. As described in RFC 3261, the TLS connection needs to present a certificate that matches the expected name of the server to which the connection was formed, so that the UA knows it is talking to the correct server. Failing to do this may result in the UA publishing its private key information to an attacker. Bestie, this is the part that matters most 😭🔥 The credential service will authenticate the UA using the usual SIP Digest mechanism, so the UA can expect to receive a SIP challenge to the SUBSCRIBE or PUBLISH requests 🦋
7.6. Notifier Processing of SUBSCRIBE Requests
okay so when a credential service gets a SUBSCRIBE for a credential, it has to authenticate and authorize the UA 🔐 and also check that adequate transport security is being used 💅. Only a UA that can prove it's allowed to register as the AOR is authorized to get the credentials for that AOR 🫶. The credential service MUST challenge the UA to authenticate, then decide whether it's authorized to receive the credentials. If authentication works out, the Notifier MAY limit the subscription to an administrator-defined period of time ⏳. The duration of the subscription MUST NOT be larger than the length of time the certificate is still valid. The Expires header field SHOULD be set so it's not longer than the notAfter date in the certificate 📅.
7.7. Notifier Generation of NOTIFY Requests
once the UA has authenticated with the credential service and the subscription is accepted, the credential service MUST immediately send a Notify request ✨. The authentication service gets applied to this NOTIFY request the same way it does for certificate subscriptions.
okay now the important bit 🚨. If the credential is revoked, the credential service MUST terminate any current subscriptions and force the UA to re-authenticate by sending a NOTIFY with its Subscription-State header field set to "terminated" and a reason parameter set to "deactivated". (This causes a Subscriber to retry the subscription immediately 🏃♀️.) This is so that if a secret for retrieving the credentials gets compromised, the rogue UA can't keep receiving credentials after that secret has been changed. Main character protection 👑.
Any time the credentials for this URI change, the credential service MUST send a new NOTIFY to any active subscriptions with the new credentials 🦋.
The notification MUST be sent over TLS so that it's integrity protected 🔒, and the TLS needs to be directly connected between the UA and the credential service with no intermediaries 🙅♀️.
7.8. Generation of PUBLISH Requests
A User Agent SHOULD be configurable to control whether it publishes the credential for a user or just the user's certificate 🎀.
When it publishes just a certificate, the body contains an application/pkix-cert. When it publishes a credential, the body contains a multipart/mixed containing both an application/pkix-cert and an application/pkcs8 body 🧚.
When the UA sends the PUBLISH [RFC3903] request, it needs to do the following:
- The UA MUST use TLS to directly connect to the server acting as the credential service, or to a server that is authoritative for the domain of the credential service. The UA MUST NOT connect through an intermediate proxy to the credential service. No middlemen allowed 🙅♀️.
- The Expires header field value in the PUBLISH request SHOULD be set to match the time for which the certificate is valid ⏰.
- If the certificate includes Basic Constraints, it SHOULD set the
cAboolean to false.
7.9. Notifier Processing of PUBLISH Requests
when the credential service receives a PUBLISH request to update credentials, it MUST authenticate and authorize this request in the same way as for subscriptions for credentials 🛡️. If the authorization succeeds, then the credential service MUST perform the following checks on the certificate:
- The notBefore validity time MUST NOT be in the future.
- The notAfter validity time MUST be in the future.
- If a
cABasicConstraints boolean is set in the certificate, it is set toFALSE.
If all of these succeed, the credential service updates the credential for this URI, processes all the active certificates and credential subscriptions to this URI, and generates a NOTIFY request with the new credential or certificate 💌. Note the SubjectAltName SHOULD NOT be checked, as that would restrict which certificates could be used and offers no additional security guarantees 🙄.
If the Subscriber submits a PUBLISH request with no body and Expires=0, this revokes the current credentials 💀. Watchers of these credentials will receive an update with no body, which tells them they MUST stop any previously stored credentials. Note that subscriptions to the certificate package are not terminated. Each Subscriber to the certificate package gets a notification with an empty body 🫥.
7.10. Subscriber Processing of NOTIFY Requests
when the UA receives a valid NOTIFY request, it should replace its existing credentials with the new ones it got 🔄. If the UA cannot decrypt the PKCS #8 object, it MUST send a 437 (Unsupported Certificate) response 🙈. Later, if the user provides a new password phrase for the private key, the UA can subscribe to the credentials again and try to decrypt with the new password phrase 🔑.
7.11. Handling of Forked Requests
this event package does not permit forked requests 🚫🍴.
7.12. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per minute. Chill, bestie 🐢.
7.13. State Agents and Lists
the credential server described in this section, the one that serves credentials, is a state agent. Implementations of the credential server MUST be implemented as a state agent 🧠.
Implementers MUST NOT use the event list extension [RFC4662] with this event type 🚷.
7.14. Behavior of a Proxy Server
the behavior is identical to what's described for certificate subscriptions in Section 6.12. Same energy, no notes 💅.
8. Identity Signatures
okay so the [RFC4474] authentication service defined a signature algorithm based on SHA-1 called rsa-sha1. This specification adds a signature algorithm that's roughly the same, but it's based on SHA-256 and it's called rsa-sha256 🌈.
When using the rsa-sha256 algorithm, the signature MUST be computed in exactly the same way as described in Section 9 of [RFC4474], with one exception: instead of using sha1WithRSAEncryption, the computation is done using sha256WithRSAEncryption as described in [RFC5754] ✍️.
Implementations of this specification MUST implement both rsa-sha1 and rsa-sha256. The IANA registration for rsa-sha256 is defined in Section 11.3 📋.
9. Examples
in all of these examples, large parts of the messages are left out so we can focus on what matters for this document 🔍. The lines in the examples that start with $ are encrypted blocks of data 🔐.
9.1. Encrypted Page Mode Instant Message
in this example, Alice sends Bob an encrypted page mode instant message 💌. Alice doesn't already have Bob's public key from earlier chats, so she fetches it from Bob's credential service 🕵️♀️:
SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0
...
Event: certificateThe credential service responds with the certificate in a NOTIFY 🎁.
NOTIFY alice@atlanta.example.com SIP/2.0
Subscription-State: active; expires=7200
....
From: <sip:bob@biloxi.example.com>;tag=1234
Identity: ".... stuff removed ...."
Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha256
....
Event: certificate
Content-Type: application/pkix-cert
Content-Disposition: signal
< certificate data >Next, Alice sends a SIP MESSAGE to Bob, and she can encrypt the body using Bob's public key, like this 🫶:
MESSAGE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: application/pkcs7-mime
Content-Disposition: render
$ Content-Type: text/plain
$
$ < encrypted version of "Hello" >9.2. Setting and Retrieving UA Credentials
when Alice's UA wants to publish Alice's certificate and private key to the credential service, it sends a PUBLISH request like the one below 📤. This must be sent over a TLS connection directly to the domain of the credential service 🔒. The credential service presents a certificate where the SubjectAltName contains an entry that matches the domain name in the request line of the PUBLISH request, and it challenges the request to authenticate her 🛂.
PUBLISH sips:alice@atlanta.example.com SIP/2.0
...
Event: credential
Content-Type: multipart/mixed;boundary=boundary
Content-Disposition: signal
--boundary
Content-ID: 123
Content-Type: application/pkix-cert
< Public certificate for Alice >
--boundary
Content-ID: 456
Content-Type: application/pkcs8
< Private Key for Alice >
--boundaryIf one of Alice's UAs subscribes to the credential event, the credential service will challenge the request to authenticate her 🔑, and the NOTIFY will include a body similar to the one in the PUBLISH example above ✨.
10. Security Considerations 💅
okay bestie, this is the serious part 🥺 but it's still iconic, I promise. Here's the high-level message flow from a security point of view. The 200 responses are removed from the figure because they don't really matter for security.
In this figure, authC means authentication and authZ means authorization.
Alice Server Bob UA
| | TLS Handshake | 1) Client authC/Z server
| |<---------------->|
| | PUBLISH | 2) Client sends request
| |<-----------------| (write credential)
| | Digest Challenge | 3) Server challenges client
| |----------------->|
| | PUBLISH + Digest | 4) Server authC/Z client
| |<-----------------|
| | time... |
| | |
| | TLS Handshake | 5) Client authC/Z server
| |<---------------->|
| | SUBSCRIBE | 6) Client sends request
| |<-----------------| (read credential)
| | Digest Challenge | 7) Server challenges client
| |----------------->|
| | SUBSCRIBE+Digest | 8) Server authC/Z client
| |<-----------------|
| | NOTIFY | 9) Server returns credential
| |----------------->|
| |
| SUBSCRIBE | 10) Client requests certificate
|---------->|
| |
|NOTIFY+AUTH| 11) Server returns user's certificate and signs that
|<----------| it is valid using certificate for the domain
| |So when the UA labeled Bob first made a credential for Bob, it got stored on the credential server 📦. The UA checked the server using the certificates from the TLS handshake. The server checked the UA with a digest-style challenge that uses a shared secret 🔑.
Now Bob's UA wants its credentials back from the server. First it sets up a TLS connection to the server, which gives integrity and privacy protection and also authenticates the server to Bob's UA 🔒. Next, the UA asks for its credentials with a SUBSCRIBE request. The server challenges that SUBSCRIBE request to authenticate Bob's UA. The server and Bob's UA share a secret that's used for this. If the authentication works, the server sends the credentials to Bob's UA. The private key inside the credentials may have been encrypted with a shared secret that the server doesn't know 👀.
Publishing new credentials works in a similar way. Bob's UA sends a PUBLISH request with the new credentials. When that happens, all the other UAs subscribed to Bob's credentials get a NOTIFY with the new credentials 🔔.
Alice wants to find Bob's certificate, so she sends a SUBSCRIBE to the server, and the server sends the response in a NOTIFY. This doesn't need to go over a privacy or integrity protected channel, because the authentication service described in [RFC4474] already provides integrity protection for this info and signs it with the certificate for the domain 🛡️.
This whole scheme is super dependent on trusting the operators of the credential service and trusting that the credential service won't get compromised 😬. If the credential service gets compromised, the security of all the users gets compromised too.
Note: There has been significant discussion about avoiding deployments where the credential servers store the private keys, even in some encrypted form that the credential server can't decrypt. Various schemes were considered to avoid this, but they all end up either moving the problem to some other server, which doesn't really make things better, or giving each device its own credential. For deployments where each user has only one device, that's fine. But for deployments with multiple devices, when Alice went to contact Bob, Alice would have to provide messages encrypted for all of Bob's devices. The SIPPING Working Group did consider this architecture and decided it wasn't appropriate, because of the information it revealed about the devices and users, and because of the amount of signaling needed to make it work.
This specification requires that TLS be used for the SIP communications to place and retrieve a UA's private key. That gives security in two ways 🎀:
- Confidentiality is provided for the Digest Authentication exchange, which protects it from dictionary attacks.
- Confidentiality is provided for the private key, which protects it from being exposed to passive attackers.
To prevent man-in-the-middle attacks, TLS clients MUST check that the SubjectAltName of the certificate for the server they connected to exactly matches the server they were trying to connect to 🚨. The TLS client has to be directly connected to the correct server. Otherwise, any intermediaries in the TLS path can compromise the certificate and instead provide a certificate for which the attacker knows the private key 💀. That can make the UA that relies on this compromised certificate lose confidential info. Not using TLS, or picking a bad cipher suite (like NULL encryption), can end up with credentials, including private keys, being sent unencrypted over the network, and that will make the whole system totally useless 😭.
Checking chained certificates correctly, as specified in TLS [RFC5246], is critical for the client to authenticate the server 🔗. If the client doesn't authenticate that it's talking to the correct credential service, a man-in-the-middle attack is possible.
10.1. Certificate Revocation
If a particular credential needs to be revoked, the new credential just gets published to the credential service 🗞️. Every device with a copy of the old credential or certificate in its cache will have a subscription and will rapidly (order of seconds) be notified and replace its cache ⚡. Clients that aren't subscribed will subscribe the next time they need to use the certificate and will get the new certificate.
An attacker could try a denial-of-service (DoS) attack so that the UA that cached a certificate never gets the NOTIFY with its revocation 🙈. To protect against this, the UA needs to limit how long it caches certificates. After that time, the UA invalidates the cached info, even if no NOTIFY was ever received because the attacker was blocking it.
How long this cached info lasts is kind of like a device deciding how often to check a Certificate Revocation List (CRL) 📋. For many applications, a default time of one day is suggested. But for some applications it may be desirable to set the time to zero, so that no certificates are cached at all and the credential gets checked for validity every time the certificate is used 🧐.
The UA MUST NOT cache the certificates for a period longer than the subscription duration. This avoids the UA using invalid cached credentials when the Notifier of the new credentials has been stopped from updating the UA 🚫.
10.2. Certificate Replacement
The UAs in the system replace certificates close to the time they would expire ⏰. If a UA has used the same key pair to encrypt a very large volume of traffic, the UA MAY choose to replace the credential with a new one before the normal expiration 🔄.
10.3. Trusting the Identity of a Certificate
When a UA wants to find the certificate for sip:alice@example.com, the UA subscribes to the certificate for alice@example.com and gets a certificate in the body of a SIP NOTIFY request 📬. The term "original URI" describes the URI that was in the To header field value of the SUBSCRIBE request. So in this case, the original URI would be sip:alice@example.com.
If the certificate is signed by a trusted certification authority, and one of the names in the SubjectAltName matches the original URI, then this certificate MAY be used, but only for exactly the original URI and not for other identities found in the SubjectAltName 🎯. Otherwise, there are several steps the UA MUST perform before using this certificate:
- The From header field in the NOTIFY request MUST match the original URI that was subscribed to.
- The UA MUST check the Identity header field as described in the Identity [RFC4474] specification, to validate that bodies have not been tampered with and that an authentication service has validated this From header field 🕵️.
- The UA MUST check the validity time of the certificate and stop using the certificate if it's invalid. (Implementations are reminded to verify both the notBefore and notAfter validity times ⏳.)
- The certificate MAY have several names in the SubjectAltName, but the UA MUST only use this certificate when it needs the certificate for the identity asserted by the authentication service in the NOTIFY. This means the certificate should only be indexed in the certificate cache by the AOR that the authentication service asserted, and not by the value of all the identities found in the SubjectAltName list 🗂️.
These steps make a chain of bindings that creates a trusted binding between the original AOR that was subscribed to and a public key 🔗💖. The original AOR is forced to match the From header field. The authentication service checks that this request really came from the identity claimed in the From header field value, and that the bodies carrying the certificate haven't been tampered with. The certificate in the body contains the public key for the identity. Only the UA that can authenticate as this AOR, or devices with access to the private key of the domain, can tamper with this body. That stops other users from providing a fake public key 🚫. This chain of assertion, from original URI to From to body to public key, is critical to the security of the mechanism described in this specification. If any of the steps above aren't followed, the chain breaks and the system won't work 💀.
10.3.1. Extra Assurance
Even though the certificates used with this document don't need to be validatable to a trust anchor via PKIX [RFC5280] procedures, certificates that can be validated may also be distributed through this mechanism ✨. Those certificates potentially offer an extra level of security, because they can be used with the secure (and partially isolated) certification authority user verification and key issuance toolset, instead of depending on the security of generic SIP implementations 🏰.
When a relying party gets a certificate that isn't self-signed, it MAY attempt to validate the certificate using the rules in Section 6 of [RFC5280]. If the certificate validates successfully and the names correctly match the user's AOR (see Section 10.6), then the implementation SHOULD give some indication that the certificate has been validated by an external authority 🥇. In general, failing to validate a certificate through this mechanism SHOULD NOT be used as a reason to reject the certificate 🙅. However, if the certificate is revoked, then the implementation SHOULD reject it 🚫🎀.
10.4. SACRED Framework ✨
okay so this spec has a mechanism that lets end users share the same credentials across all their devices, and it's giving main character energy 💅. It's based on the one from the Securely Available Credentials (SACRED) Framework [RFC3760]. We fully describe it right here, but if you want the deeper requirements and background tea, [RFC3760] has it all 🧚.
Specifically, Sections 7.5, 7.6, and 7.9 follow the TLS with Client Authentication (cTLS) architecture from Section 4.2.2 of [RFC3760]. The client authenticates the server using the server's TLS certificate 🔒. The server authenticates the client using a SIP Digest transaction inside the TLS session. The TLS sessions form a strong session key that protects the credentials being exchanged 🫶.
10.5. Crypto Profiles 🔐
Credential services SHOULD implement the server name indication extensions in [RFC4366]. As specified in [RFC5246], credential services MUST support the TLS cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. In addition, they MUST support the TLS cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 as specified in [RFC5246]. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms. Absolutely no NULL vibes allowed 🙅♀️.
Implementations of TLS typically support multiple versions of the Transport Layer Security protocol, as well as the older Secure Socket Layer (SSL) protocol. Because of known security vulnerabilities, clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details 💀.
The PKCS #8 encryption in the clients MUST implement PBES2 with a key derivation algorithm of PBKDF2 using HMAC. Clients MUST implement this HMAC with both SHA-1 [RFC3370] and SHA-256 [RFC5754]. Clients MUST implement an encryption algorithm of id-aes128-wrap-pad as defined in [RFC5649]. Some pre-standard deployments of this specification used DES-EDE2-CBC-Pad as defined in [RFC2898], so for some implementations, it may be desirable to also support that algorithm. A different password SHOULD be used for the PKCS #8 encryption than is used for authentication of the client. It is important to choose sufficiently strong passwords 🔑. Specific advice on the password can be found in Section 6 of [RFC5959].
10.6. User Certificate Generation 📜
The certificates need to be consistent with [RFC5280]. The sha1WithRSAEncryption and sha256WithRSAEncryption algorithms for the signatureAlgorithm MUST be implemented. The Issuers SHOULD be the same as the subject. Given the ease of issuing new certificates with this system, the Validity field can be relatively short. A Validity value of one year or less is RECOMMENDED. The SubjectAltName must have a URI type that is set to the SIP URL corresponding to the user AOR. It MAY be desirable to put some randomness into the length of time for which the certificates are valid, so that it does not become necessary to renew all the certificates in the system at the same time 🎲.
When creating a new key pair for a certificate, it is critical to have appropriate randomness as described in [RFC4086]. This can be challenging on some embedded devices, such as some IP phones, so implementers should pay particular attention to this point 👀.
It is worth noting that a UA can discover the current time by looking at the Date header field value in the 200 response to a REGISTER request ⏰.
10.7. Private Key Storage 🗝️
The protection afforded private keys is a critical security factor. On a small scale, failure of devices to protect the private keys will permit an attacker to masquerade as the user or decrypt their personal information. As noted in the SACRED Framework, when stored on an end-user device, such as a diskette or hard drive, credentials SHOULD NOT be in the clear. It is RECOMMENDED that private keys be stored securely in the device. More specifically, encrypt them using tamper-resistant hardware encryption and expose them only when required. For example, the private key is decrypted when necessary to generate a digital signature, and re-encrypted immediately to limit exposure in the RAM to a short period of time. Some implementations may limit access to private keys by prompting users for a PIN prior to allowing access to the private key 🔢.
On the server side, the protection of unencrypted PKCS #8 objects is equally important. Failure of a server to protect the private keys would be catastrophic, as attackers with access to unencrypted PKCS #8 objects could masquerade as any user whose private key was not encrypted 😱. Therefore, it is also recommended that the private keys be stored securely in the server, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required.
FIPS 140-2 [FIPS-140-2] provides useful guidance on secure storage 📘.
10.8. Compromised Authentication Service 🚨
One of the worst attacks against the Certificate Management Service described in this document would be if the authentication service were compromised. This attack is somewhat analogous to a certification authority being compromised in traditional PKI systems. The attacker could make a fake certificate for which it knows the private key, use it to receive any traffic for a given use, and then re-encrypt that traffic with the correct key and forward the communication to the intended receiver. The attacker would thus become a "man in the middle" in the communications. Iconic villain behavior, truly 😈.
There is not too much that can be done to protect against this type of attack.
A UA MAY subscribe to its own certificate under some other identity to try to detect whether the credential server is handing out the correct certificates. It will be difficult to do this in a way that does not allow the credential server to recognize the user's UA 🕵️♀️.
The UA MAY also save the fingerprints of the cached certificates and warn users when the certificates change significantly before their expiry date 📌.
The UA MAY also allow the user to see the fingerprints of the cached certificates, so that they can be verified by some other out-of-band means 🦋.
11. IANA Considerations 🧾
This specification defines two new event packages that IANA has added to the "Session Initiation Protocol (SIP) Event Types Namespace" registry 💌.
11.1. Certificate Event Package
To: ietf-sip-events@iana.org
Subject: Registration of new SIP event package
Package Name: certificate
Is this registration for a template-package: No
Published Specification(s): This document
New Event header parameters: This package defines no
new parameters
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>11.2. Credential Event Package
To: ietf-sip-events@iana.org
Subject: Registration of new SIP event package
Package Name: credential
Is this registration for a template-package: No
Published Specification(s): This document
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>11.3. Identity Algorithm
IANA added the following entry to the "Identity-Info Algorithm Parameter Values" registry 🧩.
"alg" Parameter Name Reference
---------------------- ---------
rsa-sha256 [RFC6072]12. Acknowledgments 🫶
Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy, and Sean Turner for significant help, discussion, and text 🙌. Many others provided useful comments and text, including Kumiko Ono, Peter Gutmann, Yaron Pdut, Aki Niemi, Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer, Pasi Eronen, Alexey Melnikov, Tim Polk, John Elwell, Jonathan Rosenberg, and Lyndsay Campbell. The whole crew 💖.
13. References 📚
13.1. Normative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for
ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, January 2010.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption
Standard (AES) Key Wrap with Padding Algorithm",
RFC 5649, September 2009.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
August 2010.
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package
Content Type", RFC 5959, August 2010.13.2. Informative References 📚✨
Okay bestie, this is the last stretch! These are the background reads that help explain the spec. 🌸
[RFC2898]Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000. 🔐[RFC3760]Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, April 2004. 🎀[RFC3853]Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004. 🦋[RFC4662]Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. 💜[RFC5751]Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. 💌[FIPS-140-2]NIST, "Security Requirements for Cryptographic Modules", May 2001,http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf. 🧚
Authors' Addresses 💖
Cullen Jennings
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Jason Fischl (editor)
Skype
3210 Porter Drive
Palo Alto, CA 94304
USA
Phone: +1-415-202-5192
EMail: jason.fischl@skype.net📦 where this page comes from
- ietf: rfc6072 2011-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms