RFC 2660
The Secure HyperText Transfer Protocol
RFC 2660 💖: The Secure HyperText Transfer Protocol 🎀
Okay bestie, this one is RFC 2660, and it's called The Secure HyperText Transfer Protocol 🔐. E. Rescorla (RTFM, Inc.) and A. Schiffman (Terisa Systems, Inc.) wrote it, it's dated August 1999, and it's marked as Experimental 🧪. It comes from the Network Working Group. The header doesn't list anything it obsoletes or updates, so it's kinda its own main character ✨.
Status of This Memo 📜
This memo is an Experimental Protocol for the Internet community, so it's not an Internet standard of any kind. The authors want feedback and suggestions for making it better 🫶. Distribution is unlimited, so share it with whoever's curious 💌.
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🌸
This memo describes a syntax for securing messages sent over HTTP, the Hypertext Transfer Protocol that the World Wide Web is built on 🕸️. Secure HTTP (S-HTTP) gives you security services you can apply independently: transaction confidentiality, authenticity/integrity, and non-repudiability of origin 🔒.
It's super flexible too 💅. It lets the two parties negotiate options for each transaction, so you get to pick your key management mechanisms, security policies, and cryptographic algorithms.
Table of Contents 📚
1. Introduction .................................................. 3
1.1. Summary of Features ......................................... 3
1.2. Changes ..................................................... 4
1.3. Processing Model ............................................ 5
1.4. Modes of Operation .......................................... 6
1.5. Implementation Options ...................................... 7
2. Message Format ................................................ 7
2.1. Notational Conventions ...................................... 8
2.2. The Request Line ............................................ 8
2.3. The Status Line ............................................. 8
2.4. Secure HTTP Header Lines .................................... 8
2.5. Content .....................................................12
2.6. Encapsulation Format Options ................................13
2.6.1. Content-Privacy-Domain: CMS ...............................13
2.6.2. Content-Privacy-Domain: MOSS ..............................14
2.6.3. Permitted HTTP headers ....................................14
2.6.3.2. Host ....................................................15
2.6.3.3. Connection ..............................................15
3. Cryptographic Parameters ......................................15
3.1. Options Headers .............................................15
3.2. Negotiation Options .........................................16
3.2.1. Negotiation Overview ......................................16
3.2.2. Negotiation Option Format .................................16
3.2.3. Parametrization for Variable-length Key Ciphers ...........18
3.2.4. Negotiation Syntax ........................................18
3.3. Non-Negotiation Headers .....................................23
3.3.1. Encryption-Identity .......................................23
3.3.2. Certificate-Info ..........................................23
3.3.3. Key-Assign ................................................24
3.3.4. Nonces ....................................................25
3.4. Grouping Headers With SHTTP-Cryptopts .......................26
3.4.1. SHTTP-Cryptopts ...........................................26
4. New Header Lines for HTTP .....................................26
4.1. Security-Scheme .............................................26
5. (Retriable) Server Status Error Reports .......................27
5.1. Retry for Option (Re)Negotiation ............................27
5.2. Specific Retry Behavior .....................................28
5.3. Limitations On Automatic Retries ............................29
6. Other Issues ..................................................30
6.1. Compatibility of Servers with Old Clients ...................30
6.2. URL Protocol Type ...........................................30
6.3. Browser Presentation ........................................31
7. Implementation Notes ..........................................32
7.1. Preenhanced Data ............................................32
7.2. Note:Proxy Interaction ......................................34
7.2.1. Client-Proxy Authentication ...............................34
8. Implementation Recommendations and Requirements ...............34
9. Protocol Syntax Summary .......................................35
10. An Extended Example ..........................................36
Appendix: A Review of CMS ........................................40
Bibliography and References ......................................41
Security Considerations ..........................................43
Authors' Addresses ...............................................44
Full Copyright Statement..........................................451. Introduction ✨
The World Wide Web (WWW) is a distributed hypermedia system that's gotten seriously popular with Internet users 🌍. Browsers can talk to other older Internet protocols too, but the main one between WWW clients and servers is the HyperText Transfer Protocol (HTTP) [RFC-2616] 🕸️. Because the Web is so easy to use, people started using it as a client/server setup for all kinds of apps 📱. A lot of those apps need the client and server to authenticate each other and swap sensitive info privately 🥺. The original HTTP spec barely supported the crypto stuff that kind of transaction needs 😭.
Secure HTTP (S-HTTP) is the fix 🔥. It gives an HTTP client-server pair secure ways to talk, so spontaneous commercial transactions can happen across tons of different apps 💸. The big design goal is flexibility 💅. It supports several operation modes, key management mechanisms, trust models, cryptographic algorithms, and encapsulation formats, all picked through option negotiation between the two parties for each transaction 🎀.
1.1. Summary of Features 💅
S-HTTP is a secure, message-oriented protocol built to work with HTTP 🎁. It's designed to coexist with HTTP's messaging model, so it plugs into HTTP apps pretty smoothly 🧚.
It gives HTTP clients and servers a bunch of security mechanisms, with the security options matched to the many different ways the World Wide Web gets used 🌈. Both sides are treated equally, meaning requests and replies get equal treatment, and both parties' preferences count 🫶. It also keeps HTTP's transaction model and implementation traits intact ✨.
Several cryptographic message format standards can be built into S-HTTP clients and servers, mainly [CMS] and [MOSS], though it isn't limited to those 🔑. S-HTTP works across lots of different implementations and is compatible with HTTP 🤝. S-HTTP-aware clients can talk to S-HTTP-oblivious servers and the other way around, though those exchanges obviously won't use the S-HTTP security features 🙈.
S-HTTP does not require client-side public key certificates (or public keys), because it supports symmetric key-only operation modes 🗝️.
This is a big deal 🤯. It means private transactions can happen spontaneously without every user needing an established public key. S-HTTP can totally take advantage of widespread certification infrastructures, but it doesn't need them to work 💖.
S-HTTP supports end-to-end secure transactions 🔐. The original HTTP authorization mechanisms made the client try to access something, get denied, and only then use the security mechanism. S-HTTP skips that awkward dance 💀. Clients can be "primed" to start a secure transaction, usually with info supplied in message headers, and this can be used to encrypt fill-out forms, for example 📝. With S-HTTP, no sensitive data ever has to cross the network in the clear 🙌.
S-HTTP gives full flexibility over cryptographic algorithms, modes, and parameters 🎛️. Option negotiation lets clients and servers agree on transaction modes (like whether the request should be signed or encrypted or both, and the same question for the reply) ✍️. It also covers cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, and so on) 🧮, and certificate selection (like "please sign with your Block-buster Video certificate") 📼😂.
S-HTTP avoids assuming one particular trust model 👑. Its designers did, though, consciously aim to make multiply-rooted hierarchical trust easy to do, and they expect that principals may have lots of public key certificates 🏰.
S-HTTP is different from Digest-Authentication, described in [RFC-2617] 🔍. It supports public key cryptography, which means digital signature capability, and it also provides confidentiality 🔏.
1.2. Changes 🦋
This document describes S-HTTP/1.4 🆕. It's different from the previous memo because it supports the Cryptographic Message Syntax (CMS) [CMS], which is the successor to PKCS-7 💫. Because of that, it now supports the Diffie-Hellman and the (NIST) Digital Signature Standard cryptosystems 🥳. CMS used in RSA mode is bits-on-the-wire compatible with PKCS-7 🫡.
1.3. Processing Model 🧠
1.3.1. Message Preparation 🎀
Making an S-HTTP message is like a function with three inputs 🧁:
- The cleartext message. This is either an HTTP message or some other data object. The cleartext message gets carried transparently, headers and all, so any version of HTTP can ride inside an S-HTTP wrapper 📦.
- The receiver's cryptographic preferences and keying material. The receiver either specifies this explicitly or it falls back to some default set of preferences 🎯.
- The sender's cryptographic preferences and keying material. This one is kinda implicit, since it only lives in the sender's memory 🤫.
So to create an S-HTTP message, the sender merges their own preferences with the receiver's 🤝. The result is a list of cryptographic enhancements to apply, plus the keying material to apply them with 🗝️. Sometimes this needs a bit of user input, like when there are multiple keys available to sign the message 🙋♀️. (See Section 3.2.4.9.3 for more on this topic.) Then the sender applies those enhancements to the cleartext message and ends up with the S-HTTP message 💅.
The processing steps that turn the cleartext message into the S-HTTP message are described in Sections 2 and 3 📖. The steps for merging the sender's and receiver's preferences are described in Sections 3.2 🧩.
1.3.2. Message Recovery ✨
Okay bestie, recovering an S-HTTP message is a function with four inputs 🧚
- The S-HTTP message. 💌
- The receiver's stated cryptographic preferences and keying material. The receiver has the chance to remember what cryptographic preferences it gave so this document could be dereferenced. 🧠
- The receiver's current cryptographic preferences and keying material. 🔑
- The sender's previously stated cryptographic options. The sender may have said it would perform certain cryptographic operations in this message. (Again, see sections 4 and 5 for details on how to do this.) 📝
So to recover the message, the receiver reads the headers to figure out which cryptographic transformations were applied. Then it removes them using some combination of the sender's and receiver's keying material, while taking note of which enhancements were applied. Main character energy 👑
The receiver may also choose to verify that the applied enhancements match the enhancements the sender said it would apply (input 4 above) and the ones the receiver requested (input 2 above), plus the current preferences, to see whether the S-HTTP message was appropriately transformed. This can require checking in with the user to make sure the enhancements are okay with them 🫶 (See Section 6.4 for more on this topic.)
1.4. Modes of Operation 🦋
Message protection can be provided on three orthogonal axes: signature, authentication, and encryption. Any message may be signed, authenticated, encrypted, or any combination of these (including no protection). Mix and match, it's giving options 💅
Multiple key management mechanisms are supported, including password-style manually shared secrets and public-key key exchange. In particular, there's provision for prearranged symmetric session keys (set up in an earlier transaction or out of band), so you can send confidential messages to people who don't have a public key pair 🔐
Additionally, there's a challenge-response ("nonce") mechanism so parties can make sure a transaction is fresh 🌸
1.4.1. Signature ✍️
If the digital signature enhancement is applied, an appropriate certificate may either be attached to the message (possibly along with a certificate chain), or the sender may expect the recipient to obtain the required certificate (chain) independently. Either way, the cert situation is handled 🎀
1.4.2. Key Exchange and Encryption 🗝️
To support bulk encryption, S-HTTP defines two key transfer mechanisms: one uses public-key enveloped key exchange, and the other uses externally arranged keys.
In the former case, the symmetric-key cryptosystem parameter is passed encrypted under the receiver's public key.
In the latter mode, the content is encrypted using a prearranged session key, with key identification information specified on one of the header lines 🧚
1.4.3. Message Integrity and Sender Authentication 🛡️
Secure HTTP gives you a way to verify message integrity and sender authenticity through a Message Authentication Code (MAC). That's computed as a keyed hash over the document using a shared secret, which could have been arranged in a number of ways, e.g.: manual arrangement or 'inband' key management. This technique doesn't need public key cryptography or encryption. Lightweight and iconic ✨
This mechanism is also useful when it's appropriate for parties to identify each other reliably in a transaction without providing (third-party) non-repudiability for the transactions themselves. The reason this exists is that the designers think "signing" a transaction should be explicit and conscious for the user. Many authentication needs (like access control) can be met with a lighter-weight mechanism that still keeps the scalability advantages of public-key cryptography for key exchange 💜
1.4.4. Freshness ⏰
The protocol provides a simple challenge-response mechanism, letting both parties insure the freshness of transmissions. The integrity protection given to HTTP headers also lets implementations consider the Date: header allowable in HTTP messages as a freshness indicator, where appropriate. (This does require implementations to make allowances for maximum clock skew between parties, which the document chooses not to specify. Not my problem, bestie 🙈)
1.5. Implementation Options 🧩
To encourage widespread adoption of secure documents for the World-Wide Web, despite the broad scope of application requirements, variability of user sophistication, and disparate implementation constraints, Secure HTTP deliberately caters to a variety of implementation options. See Section 8 for implementation recommendations and requirements. 🌈
2. Message Format 💌
Syntactically, Secure HTTP messages are the same as HTTP. They consist of a request or status line followed by headers and a body. However, the range of headers is different, and the bodies are typically cryptographically enhanced 🎀
2.1. Notational Conventions 📖
This document uses the augmented BNF from HTTP [RFC-2616]. You should refer to that document for a description of the syntax.
2.2. Request Line 🚀
To tell S-HTTP messages apart from HTTP messages and allow for special processing, the request line should use the special Secure method and the protocol designator Secure-HTTP/1.4. That means Secure-HTTP and HTTP processing can be intermixed on the same TCP port, e.g. port 80. To prevent leaking potentially sensitive information, the Request-URI should be *. For example:
Secure * Secure-HTTP/1.4When communicating via a proxy, the Request-URI should consist of the AbsoluteURI. Typically, the rel path section should be replaced by * to minimize the information passed in the clear (e.g. http://www.terisa.com/*). Proxies should remove the appropriate amount of this information to minimize the threat of traffic analysis. See Section 7.2.2.1 for a situation where providing more information is appropriate. 🕵️♀️
2.3. The Status Line 🚦
S-HTTP responses should use the protocol designator Secure-HTTP/1.4. For example:
Secure-HTTP/1.4 200 OKNote that the status in the Secure HTTP response line doesn't tell you anything about the success or failure of the unwrapped HTTP request. Servers should always use 200 OK provided that the Secure HTTP processing is successful. This prevents anyone from analyzing success or failure for any request. The correct recipient can figure that out from the encapsulated data 🔒 All case variations should be accepted.
Real talk: the response line is basically a blank face. Only the right recipient gets the tea from the encapsulated data 🍵
2.4. Secure HTTP Header Lines 📋
The header lines described in this section go in the header of a Secure HTTP message. All except Content-Type and Content-Privacy-Domain are optional. The message body shall be separated from the header block by two successive CRLFs.
All data and fields in header lines should be treated as case insensitive unless otherwise specified. Linear whitespace [RFC-822] should be used only as a token separator unless otherwise quoted. Long header lines may be line folded in the style of [RFC-822].
This document refers to the header block that follows the S-HTTP request/response line and comes before the successive CRLFs collectively as "S-HTTP headers". 🫧
2.4.1. Content-Privacy-Domain 🎭
The two values defined by this document are MOSS and CMS. CMS refers to the privacy enhancement specified in section 2.6.1. MOSS refers to the format defined in [RFC-1847] and [RFC-1848]. Two options, pick your fighter 🥊
2.4.2. Content-Type for CMS 💖
Under normal conditions, the terminal encapsulated content (after all privacy enhancements have been removed) would be an HTTP message. In this case, there shall be a Content-Type line reading:
Content-Type: message/httpThe message/http content type is defined in RFC-2616.
If the inner message is an S-HTTP message, then the content type shall be application/s-http. (See Appendix for the definition of this.)
It is intended that these types be registered with IANA as MIME content types. 🌷
The terminal content may be of some other type, provided that the type is properly indicated by the use of an appropriate Content-Type header line. In this case, the header fields for the encapsulation of the terminal content apply to the terminal content (the 'final headers'). But in any case, final headers should themselves always be S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are never passed unenhanced. Protect everything, always 🛡️
S-HTTP encapsulation of non-HTTP data is a useful mechanism for passing pre-enhanced data (especially presigned data) without requiring that the HTTP headers themselves be pre-enhanced. 🧁
2.4.3. Content-Type for MOSS 🎀
The Content-Type for MOSS shall be an acceptable MIME content type describing the cryptographic processing applied (e.g. multipart/signed). The content type of the inner content is described in the content type line corresponding to that inner content. For HTTP messages, it shall be message/http.
2.4.4. Prearranged-Key-Info 🔑
This header line is intended to convey information about a key that has been arranged outside of the internal cryptographic format. One use of this is to permit in-band communication of session keys for return encryption, in the case where one of the parties doesn't have a key pair. This should also be useful if the parties choose some other mechanism, for instance, a one-time key list 🧚♀️
This specification defines two methods for exchanging named keys: Inband and Outband. Inband indicates that the session key was exchanged previously, using a Key-Assign header of the corresponding method. Outband arrangements imply that agents have external access to key materials corresponding to a given name, presumably via database access or perhaps supplied immediately by a user from keyboard input. The syntax for the header line is:
Prearranged-Key-Info =
"Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID
CoverKey-ID = method ":" key-name
CoveredDEK = *HEX
method = "inband" | "outband"While chaining ciphers require an Initialization Vector (IV) [FIPS-81] to start off the chaining, that information is not carried by this field. Instead, it should be passed internal to the cryptographic format being used. The bulk cipher used is specified in this fashion too 🌈
Hdr-Cipher should be the name of the block cipher used to encrypt the session key (see section 3.2.4.7).
CoveredDEK is the protected Data Encryption Key (a.k.a. transaction key) under which the encapsulated message was encrypted. It should be appropriately (randomly) generated by the sending agent, then encrypted under the cover of the negotiated key (a.k.a. session key) using the indicated header cipher, and then converted into hex. 💫
In order to avoid name collisions, cover key namespaces must be maintained separately by host and port. 🙅♀️ Name clashes are not it.
Note that some Content-Privacy-Domains, notably likely future revisions of MOSS and CMS, may have support for symmetric key management.
The Prearranged-Key-Info field need not be used in such circumstances. Rather, the native syntax is preferred. Keys exchanged with Key-Assign, however, may be used in this situation. 🦋
2.4.5. MAC-Info ✨
okay so MAC-Info is the header that carries a Message Authenticity Check 🔐. It gives you message authentication and integrity, computed from the message text, the time (optional, bc it helps stop replay attacks 👀), and a shared secret between client and server. The MAC should be computed over the encapsulated content of the S-HTTP message. S-HTTP/1.1 said MACs get computed with this algorithm ('||' means concatenation):
MAC = hex(H(Message||[<time>]||<shared key>))The time is an unsigned 32 bit quantity, counting seconds since 00:00:00 GMT January 1, 1970 (the UNIX epoch), in network byte order. The shared key format is a local matter 🗝️
Now the tea ☕. [VANO95] showed some weaknesses in that approach, so this memo brings in a new construction, derived from [RFC-2104]. For backwards compatibility, the old constructions keep their old names. But there's also a new set of names (see Section 3.2.4.8 for them) that follows a different construction, one that's hopefully stronger 💪 (^ means bitwise XOR)
HMAC = hex(H(K' ^ pad2 || H(K' ^ pad1 ||[<time>]|| Message)))
pad1 = the byte 0x36 repeated enough times to fill out a
hash input block. (I.e. 64 times for both MD5 and SHA-1)
pad2 = the byte 0x5c repeated enough times to fill out a
hash input block.
K' = H(<shared key>)The original HMAC construction is meant for a key the same length as the hash output. Using a key of a different length is considered safe [KRAW96b], and a key's strength can't go past the length of the hash function itself, but it can drop if you use a shorter key 📉. We hash the original key so you can use shared keys (like passphrases) that are longer than the hash. It's noteworthy (though obvious) that this doesn't make short keys any stronger 🙃
The format of the MAC-Info line is:
MAC-Info =
"MAC-Info" ":" [hex-time],
hash-alg, hex-hash-data, key-spec
hex-time = <unsigned seconds since Unix epoch represented as HEX>
hash-alg = <hash algorithms from section 3.2.4.8>
hex-hash-data = <computation as described above represented as HEX>
Key-Spec = "null" | "dek" | Key-IDKey-IDs can point to keys bound with the Key-Assign header line, or to keys bound the same way as the Outband method described later 🔑. A 'null' key-spec means a zero length key was used, so the MAC just represents a hash of the message text and (optionally) the time. The special key-spec 'DEK' refers to the Data Exchange Key that encrypts the following message body. Using the DEK key-spec when the following message body is unencrypted is an error 🚫
If the time is left out of the MAC-Info line, it should simply not be included in the hash ⏰
This header line can give you a more advanced version of the old HTTP Basic authentication mode, since the user can be asked for a username and password. The difference is the password stays private and message integrity can still be assured 🥹 And the best part is you can do all of this without any encryption at all 🎀
MAC-Info also gives you fast message integrity checks (you lose non-repudiability though) for messages, as long as the participants share a key. That key might have been passed with Key-Assign in an earlier message 🏃♀️
Last thing: some Content-Privacy-Domains, notably likely future revisions of MOSS and CMS, may support symmetric integrity protection. In that case the MAC-Info field doesn't need to be used. The native syntax is preferred instead. Keys exchanged with Key-Assign can still be used in that situation 🔐✨
2.5. Content
the content depends mostly on the values of the Content-Privacy-Domain and Content-Transfer-Encoding fields 📦
For a CMS message with '8BIT' Content-Transfer-Encoding, the content should just be the CMS message itself 💌
If the Content-Privacy-Domain is MOSS, the content should be a MOSS Security Multipart, as described in RFC1847 🧩
Once the privacy enhancements are removed, the resulting (possibly protected) contents are expected to be a normal HTTP request. Or the content might be another Secure-HTTP message. In that case you keep unwrapping privacy enhancements until you get clear content or they can't be removed anymore 🪆 (This lets enhancements nest, like sequential Signed and Enveloped ones.) As long as every enhancement can be removed, the final de-enhanced content should be a valid HTTP request (or response), unless the Content-Type line says otherwise 🫶
This recursive wrapping can also let security enhancements get applied or removed for the benefit of intermediaries in the transaction between a client and server. Think a proxy that needs client authentication 🚪 How those intermediaries should show that they did this processing is covered in Section 7.2.1 👀
2.6. Encapsulation Format Options
2.6.1. Content-Privacy-Domain: CMS
Content-Privacy-Domain 'CMS' follows the form of the CMS standard (see Appendix) 📜
Message protection can happen on two orthogonal axes: signature and encryption. Any message can be signed, encrypted, both, or neither 💅 Note that the 'auth' protection mode of S-HTTP is provided independently of CMS coding, through the MAC-Info header of section 2.3.6. That's because CMS doesn't support a 'KeyDigestedData' type, even though it does support a 'DigestedData' type 🙃
2.6.1.1. Signature
This enhancement uses the 'SignedData' type of CMS. When digital signatures are used, an appropriate certificate can either be attached to the message (maybe with a certificate chain), as CMS specifies, or the sender can expect the recipient to get its certificate (and/or chain) on its own 🔏 An explicitly allowed case is a certificate signed with the private component that matches the public component being attested to. This is called a self-signed certificate. How much weight to give one is a purely local matter 🧐 Either way, a purely signed message is precisely CMS compliant ✅
2.6.1.2. Encryption
2.6.1.2.1. Encryption -- normal, public key
This enhancement is done precisely as enveloping (using 'EnvelopedData' types) under CMS. A message encrypted this way, signed or not, is CMS compliant 🔒 To have a message that's both signed and encrypted, you just create the CMS SignedData production and wrap it in EnvelopedData, as CMS describes 💖
2.6.1.2.2. Encryption -- prearranged key
This uses the 'EncryptedData' type of CMS. Here we encrypt the content using a DEK, which is itself encrypted under cover of a prearranged session key (how that key gets exchanged is discussed later 👀). The key identification info goes on one of the header lines. The IV lives in the EncryptedContentInfo type of the EncryptedData element 🧁 To have a message that's both signed and encrypted, you create the CMS SignedData production and wrap it in EncryptedData, as CMS describes 🌸
2.6.2. Content-Privacy-Domain: MOSS
The body of the message should be a MIME compliant message, with a content type that matches the Content-Type line in the S-HTTP headers 🎀 Encrypted messages should use multipart/encrypted. Signed messages should use multipart/signed. But since multipart/signed doesn't carry keying material, it's acceptable to use multipart/mixed, where the first part is application/mosskey-data and the second part is multipart/mixed, so certificates for verifying the signature get conveyed 🔑
Implementation Note: When one agent applies both encryption and signature, the signature should in general be applied before encryption ✍️
2.6.3. Permitted HTTP headers
2.6.3.1. Overview
In general, HTTP [RFC-2616] headers should appear in the inner content (i.e. the message/http) of an S-HTTP message. They should NOT appear in the S-HTTP message wrapper, for security reasons 🙈 Some headers need to be visible to agents that don't have access to the encapsulated data, though, so those can appear in the S-HTTP headers as well 🧚
Brief descriptions of what these headers are for are given for clarity, but the definitive reference is [RFC-2616] 📖
2.6.3.2. Host
The Host header specifies the internet host and port number of the resource being requested. It should be used to tell apart multiple possible security contexts this message could be interpreted in 🗺️ The unwrapped HTTP message has its own Host field (assuming it's an HTTP/1.1 message). If those fields don't match, the server should respond with a 400 status code 🚨
2.6.3.3. Connection
The Connection field has precisely the same semantics in S-HTTP headers as it does in HTTP headers. That's what lets persistent connections be used with S-HTTP 🦋
3. Cryptographic Parameters ✨
3.1. Options Headers
As described in Section 1.3.2, every S-HTTP request is (at least conceptually) preconditioned by the negotiation options the potential receiver provides 🫧 The two main places these options live are:
- In the headers of an HTTP Request/Response.
- In the HTML which contains the anchor being dereferenced.
There are two kinds of cryptographic options that can be provided 💜 Negotiation options, discussed in Section 3.2, convey a potential message recipient's cryptographic preferences. Keying options, discussed in Section 3.3, provide keying material (or pointers to keying material) that might help the sender when enhancing a message 🗝️
Binding cryptographic options to anchors with HTML extensions is the job of the companion document [SHTML]. That's not covered here 📝
3.2. Negotiation Options
3.2.1. Negotiation Overview
Both parties can express their requirements and preferences about which cryptographic enhancements they'll allow or require the other party to provide 🤝 The right option choices depend on implementation capabilities and what particular applications need 🌈
A negotiation header is a sequence of specifications, and each one follows a four-part schema detailing:
- Property -- the option being negotiated, such as bulk encryption algorithm.
- Value -- the value being discussed for the property, such as DES-CBC.
- Direction -- the direction to be affected, namely: during reception or origination (from the perspective of the originator).
- Strength -- strength of preference, namely: required, optional, refused.
For example, this header line:
SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC2could be read as: "You're free to use DES-CBC or RC2 for bulk encryption when encrypting messages to me." 💅🔥
We define new headers (to be used in the encapsulated HTTP header, not in the S-HTTP header) to permit negotiation of these matters 🦋
3.2.2. Negotiation Option Format ✨
okay so every negotiation option follows the same shape, and once you see it you'll never unsee it 🫶 It's a field name, a colon, then a bunch of key-val pairs separated by semicolons:
Option = Field ":" Key-val ";" *(Key-val)
Key-val = Key "=" Value *("," Value)
Key = Mode"-"Action ; This is represented as one
; token without whitespace
Mode = "orig" | "recv"
Action = "optional" | "required" | "refused"The Mode bit tells you whether a Key-val is about what your agent does when it sends privacy enhanced messages, or what it does when it receives them. So it's literally two different vibes for the same enhancements 💅 For any mode-action pair, the <Value>s you list mean this:
recv-optional:the agent will process the enhancement if the other party uses it, but it'll also happily process messages without it 🦋recv-required:the agent will not process messages without this enhancement 🔒recv-refused:the agent will not process messages that have this enhancement 🙅♀️orig-optional:when it meets an agent that refuses this enhancement, the agent won't provide it, and when it meets an agent that requires it, this agent will provide it 🌸orig-required:the agent will always generate the enhancement 👑orig-refused:the agent will never generate the enhancement 💀
What if two agents realise they're not compatible? That's up to the agents, but you should not keep doing something you already know the other side can't handle, that's just awkward 🙈 Some reasonable moves are simply closing the connection, or, if the agent is a server answering a request, sending back Not implemented 501.
Optional values are listed in decreasing order of preference, so the first one is your fave 🍓 Agents can pick any member of the overlap between their optional lists (or none at all), totally their call.
If a <Key-Val> is left undefined, assume it's set to the default. And if an agent specifies a key, that key overrides any appearance of that same key in the default for that field. Main character energy for explicit settings ✨
3.2.3. Parametrization for Variable-length Key Ciphers 🎀
some ciphers have key lengths you can actually choose, so you write the cipher name with the length in square brackets, like <cipher>'['<length>']'. So 'RSA[1024]' means a 1024 bit key for RSA. You can also give a range:
<cipher>'['<bound1>'-'<bound2>']'When it comes to preferences, a range gets read as if it were spelled out one step at a time (assuming x and y are integers):
<cipher>[x], <cipher>[x+1],...<cipher>[y] (if x<y)and
<cipher>[x], <cipher>[x-1],...<cipher>[y] (if x>y)The special value inf can stand in for infinite length 🧚 And if you just write <cipher> on its own, it means the maximum range possible for that cipher. Simple.
3.2.4. Negotiation Syntax 💜
3.2.4.1. SHTTP-Privacy-Domains 🌈
This header points back to the Content-Privacy-Domain type from section 2.3.1, and the acceptable values are the ones listed there. Here's an example:
SHTTP-Privacy-Domains: orig-required=cms;
recv-optional=cms,MOSSTranslation: this agent always generates CMS compliant messages, but it can read CMS or MOSS (or unenhanced messages) 💅
3.2.4.2. SHTTP-Certificate-Types 🦋
This one says what kinds of Public Key certificates the agent will accept. The currently defined values are X.509 and X.509v3. 🔐
3.2.4.3. SHTTP-Key-Exchange-Algorithms 🔑
This header says which algorithms may be used for key exchange. The defined values are DH, RSA, Outband and Inband. DH means Diffie-Hellman X9.42 style enveloping [DH], RSA means RSA enveloping, and Outband means some sort of external key agreement.
Inband refers to section 3.3.3.1 🫶
The expected common setup, with clients holding no certificates and servers holding certificates, looks like this (in a message sent by the server):
SHTTP-Key-Exchange-Algorithms: orig-optional=Inband, DH;
recv-required=DH3.2.4.4. SHTTP-Signature-Algorithms ✍️
This header lists the Digital Signature algorithms that may be used. The defined values are RSA [PKCS-1] and NIST-DSS [FIPS-186]. Because NIST-DSS and RSA use variable length moduli, you should use the parametrization syntax from section 3.2.3.
⚠️ heads up: a key length setting can affect whether a given certificate is acceptable, because the keys (and their lengths) live inside the public-key certificates themselves.
3.2.4.5. SHTTP-Message-Digest-Algorithms 🧁
This one says which message digest algorithms may be used. The previously defined values are RSA-MD2 [RFC-1319], RSA-MD5 [RFC-1321] and NIST-SHS [FIPS-180].
3.2.4.6. SHTTP-Symmetric-Content-Algorithms 🔐
This header specifies the symmetric-key bulk cipher used to encrypt message content. The defined values are:
DES-CBC -- DES in Cipher Block Chaining (CBC) mode [FIPS-81]
DES-EDE-CBC -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in outer
CBC mode
DES-EDE3-CBC -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in outer
CBC mode
DESX-CBC -- RSA's DESX in CBC mode
IDEA-CBC -- IDEA in CBC mode
RC2-CBC -- RSA's RC2 in CBC mode
CDMF-CBC -- IBM's CDMF (weakened key DES) [JOHN93] in CBC modeSince RC2 keys are variable length, use the syntax from section 3.2.3 ✨
3.2.4.7. SHTTP-Symmetric-Header-Algorithms 🌸
This header specifies the symmetric-key cipher used to encrypt message headers. The defined values are:
DES-ECB -- DES in Electronic Codebook (ECB) mode [FIPS-81]
DES-EDE-ECB -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode
DES-EDE3-ECB -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode
DESX-ECB -- RSA's DESX in ECB mode
IDEA-ECB -- IDEA
RC2-ECB -- RSA's RC2 in ECB mode
CDMF-ECB -- IBM's CDMF in ECB modeSince RC2 is variable length, use the syntax from section 3.2.3 🧚
3.2.4.8. SHTTP-MAC-Algorithms 🍓
This header says which algorithms are acceptable for providing a symmetric key MAC. RSA-MD2, RSA-MD5 and NIST-SHS stick around from S-HTTP/1.1, which used the old MAC construction. The tokens RSA-MD2-HMAC, RSA-MD5-HMAC and NIST-SHS-HMAC mean the new HMAC construction from 2.3.6, using the MD2, MD5 and SHA-1 algorithms respectively. Old vs new, iconic 🙌
3.2.4.9. SHTTP-Privacy-Enhancements 🔥
This header says which security enhancements to apply. The possible values are sign, encrypt and auth, which mean messages are signed, encrypted, or authenticated (meaning provided with a MAC), respectively.
3.2.4.10. Your-Key-Pattern 🎯
This is a generalized pattern match syntax for describing identifiers for lots of kinds of keying material. The general syntax is:
Your-Key-Pattern =
"Your-Key-Pattern" ":" key-use "," pattern-info
key-use = "cover-key" | "auth-key" | "signing-key"3.2.4.10.1. Cover Key Patterns 🧁
This header specifies desired values for key names used to encrypt transaction keys, using the Prearranged-Key-Info syntax from section 2.3.5. The pattern-info is a series of comma separated regular expressions. If commas show up inside the regexps, escape them with backslashes. The first pattern is assumed to be the most preferred 💖
3.2.4.10.2. Auth key patterns 🔏
Auth-key patterns specify the name forms you'd like for MAC authenticators. The pattern-info is a series of comma separated regular expressions, and again, escape any commas inside the regexps with backslashes. The first pattern is assumed to be the most preferred 🌟
3.2.4.10.3. Signing Key Pattern ✍️
This parameter describes the pattern or patterns for which keys are acceptable for the digital signature enhancement. The pattern-info syntax for signing-key is:
pattern-info = name-domain "," pattern-dataThe only currently defined name-domain is DN-1779. This parameter sets the desired values for fields of Distinguished Names. DNs are represented as specified in RFC1779, and the order of fields and the whitespace between them don't matter.
All RFC1779 values should use , as a separator instead of ;, because ; is a statement separator in S-HTTP. Important, bestie 🫶
Pattern-data is a modified RFC1779 string, where regular expressions are allowed as field values. Pattern matching happens field by field, and unspecified fields match any value. That means leaving the DN-Pattern totally unspecified allows any DN at all 🦋 Certificate chains can be matched too (so you can handle certificates without name subordination). DN chains are ordered left to right, with the issuer of a given certificate on its immediate right, although issuers don't have to be specified. A trailing . means the sequence of DNs is absolute, which means the one furthest to the right is a root 👑
The syntax for the pattern values is:
Value = DN-spec *("," Dn-spec)["."]
Dn-spec = "/" *(Field-spec) "/"
Field-spec := Attr = "Pattern"
Attr = "CN" | "L" | "ST" | "O" |
"OU" | "C" | <or as appropriate>
Pattern = <POSIX 1003.2 regular expressions>For example, say you want the other agent to sign with a key certified by the RSA Persona CA (which uses name subordination). You could use the expression below. Notice the RFC1779 quoting that protects the comma (an RFC1779 field separator), and the POSIX 1003.2 quoting that protects the dot (a regular expression metacharacter). Literally so clever 😭
Your-Key-Pattern: signing-key, DN-1779,
/OU=Persona Certificate, O="RSA Data Security,
Inc\."/3.2.4.11. Example 🎀
Here's a representative header block for a server:
SHTTP-Privacy-Domains: recv-optional=MOSS, CMS;
orig-required=CMS
SHTTP-Certificate-Types: recv-optional=X.509;
orig-required=X.509
SHTTP-Key-Exchange-Algorithms: recv-required=DH;
orig-optional=Inband,DH
SHTTP-Signature-Algorithms: orig-required=NIST-DSS;
recv-required=NIST-DSS
SHTTP-Privacy-Enhancements: orig-required=sign;
orig-optional=encrypt3.2.4.12. Defaults 🌈
Explicit negotiation parameters always beat default values 💅 For a given negotiation option type, defaults for a given mode-action pair (like orig-required) get implicitly merged in, unless they're explicitly overridden.
The default values (these can be negotiated downward or upward) are:
SHTTP-Privacy-Domains: orig-optional=CMS;
recv-optional=CMS
SHTTP-Certificate-Types: orig-optional=X.509;
recv-optional=X.509
SHTTP-Key-Exchange-Algorithms: orig-optional=DH,Inband,Outband;
recv-optional=DH,Inband,Outband
SHTTP-Signature-Algorithms: orig-optional=NIST-DSS;
recv-optional=NIST-DSS
SHTTP-Message-Digest-Algorithms: orig-optional=RSA-MD5;
recv-optional=RSA-MD5
SHTTP-Symmetric-Content-Algorithms: orig-optional=DES-CBC;
recv-optional=DES-CBC
SHTTP-Symmetric-Header-Algorithms: orig-optional=DES-ECB;
recv-optional=DES-ECB
SHTTP-Privacy-Enhancements: orig-optional=sign,encrypt, auth;
recv-required=encrypt;
recv-optional=sign, auth3.3. Non-Negotiation Headers ✨
okay bestie, these headers are all about the keying material the other side might use 🔑 There are a bunch of them and they're literally how you talk about (or identify) the potential recipient's keys 💅
3.3.1. Encryption-Identity 🪪
This header names a potential principal the message could be encrypted for 🎀 And ngl this one is a big deal, because it explicitly allows return encryption under (say) a public key WITHOUT the other agent signing first (or under a different key than the signature one) 😭 The syntax is:
Encryption-Identity =
"Encryption Identity" ":" name-class,key-sel,name-arg
name-class = "DN-1779" | MOSS name formsThe name-class is an ASCII string showing the domain the name is supposed to be read in, kinda in the spirit of MOSS 🦋 On top of the MOSS name forms from RFC1848, we add the DN-1779 name form, which is a more convenient way to write a distinguished name 💖
3.3.1.1. DN-1779 Name Class 🌷
The argument is an RFC-1779 encoded DN. Simple as that 🫶
3.3.2. Certificate-Info 📜
So public key operations can happen on DNs named in Encryption-Identity headers WITHOUT the receiver having to go fetch certs explicitly, the sender MAY include certification info in the Certificate-Info option 🧚 The format is:
Certificate-Info: <Cert-Fmt>','<Cert-Group><Cert-Fmt> SHOULD be the type of <Cert-Group> being presented.
The defined values are 'PEM' and 'CMS'. CMS certificate groups are base-64 encoded CMS SignedData messages containing sequences of certificates with or without the SignerInfo field. A PEM format certificate group is a list of comma-separated base64-encoded PEM certificates 📦
Multiple Certificate-Info lines MAY be defined.
3.3.3. Key-Assign 🔐
This option is how the agent says "I want to bind a key to a symbolic name for (presumably) later reference" 💅 The general syntax is:
Key-Assign =
"Key-Assign" ":" Method "," Key-Name ","
Lifetime "," Ciphers ";" Method-args
Key-name = string
Lifetime = "this" | "reply" | ""
Method ="inband"
Ciphers = "null" | Cipher+
Cipher" = <Header cipher from section 3.2.4.7>
kv = "4" | "5"Key-Name is the symbolic name this key gets bound to 🏷️ Ciphers is a list of ciphers this key could potentially be applicable to (see the list of header ciphers in section 3.2.4.7). The keyword 'null' SHOULD be used to indicate that it is inappropriate for use with ANY cipher. This is potentially useful for exchanging keys for MAC computation 💜
Lifetime is the longest period of time during which the recipient of this message can expect the sender to accept that key ⏳ 'this' means it's likely only valid for reading this one transmission. 'reply' means it's useful for a reply to this message. If a Key-Assign with the reply lifetime shows up in a CRYPTOPTS block, it's good for at least one (but maybe only one) dereference of this anchor. An unspecified lifetime implies that this key MAY be reused for an indefinite number of transactions ♾️
Method SHOULD be one of a number of key exchange methods. The only currently defined value is 'inband', referring to Inband keys (i.e., direct assignment) 🎯
This header line MAY appear either in an unencapsulated header or in an encapsulated message. Though when an uncovered key is being directly assigned, it MAY only appear in an encrypted encapsulated content 🔒 Assigning to a key that already exists causes that key to be overwritten, so be careful bestie 🙈
Keys defined by this header are referred to elsewhere in this specification as Key-IDs, which have the syntax:
Key-ID = method ":" key-name3.3.3.1. Inband Key Assignment 🗝️
This is the direct assignment of an uncovered key to a symbolic name. Method-args SHOULD be just the desired session key, encoded in hexidecimal, as in:
Key-Assign: inband,akey,reply,DES-ECB;0123456789abcdefShort keys SHOULD be derived from long keys by reading bits from left to right ⬅️
Inband key assignment is especially important so agents can have confidential spontaneous communication when one (but not both) of them has a key pair 💌 It's also useful for permitting key changes without public key computations ✨ The key information is carried in this header line MUST be in the inner secured HTTP request, so use in unencrypted messages is NOT permitted. (No exceptions, periodt 💅)
3.3.4. Nonces 🌸
Nonces are opaque, transient, session-oriented identifiers which MAY be used to provide demonstrations of freshness 🦋 Nonce values are a local matter, although they might well be simply random numbers generated by the originator. The value is supplied simply to be returned by the recipient 🔁
3.3.4.1. Nonce 🎲
This header is used by an originator to specify what value is to be returned in the reply. The field MAY be any value. Multiple nonces MAY be supplied, each one to be echoed independently 🧸
The Nonce SHOULD be returned in a Nonce-Echo header line. See section 4.1.1 💖
3.4. Grouping Headers With SHTTP-Cryptopts 🧩
okay so for servers to bind a group of headers to an HTML anchor, it's possible to combine a bunch of headers on a single S-HTTP Cryptopts header line 🎀 The names of the anchors these headers apply to are indicated with a 'scope' parameter 🏷️
3.4.1. SHTTP-Cryptopts 🎀
This option provides a set of cryptopts and a list of references it applies to. (For HTML, these references would be named using the NAME tag.) The names go in the scope attribute as a comma separated list, and they're separated from the next header line by a semicolon 💅 The format for the SHTTP-Cryptopts line is:
SHTTP-Cryptopts =
"SHTTP-Cryptopts" ":" scope ";" cryptopt-list
scope = "scope="<tag-spec> ; This is all one token without whitespace
tag-spec = tag *("," tag) | ""
cryptopt-list = cryptopt *(";" cryptopt)
cryptopt = <S-HTTP cryptopt lines described below>
tag = <value used in HTML anchor NAME attribute>For example:
SHTTP-Cryptopts: scope=tag1,tag2;
SHTTP-Privacy-Domains:
orig-required=cms; recv-optional=cms,MOSSIf a message contains both S-HTTP negotiation headers AND headers grouped on SHTTP-Cryptopts line(s), the other headers SHALL be taken to apply to all anchors NOT bound on the SHTTP-Cryptopts line(s) 🚦 Note that this is an all-or-nothing proposition. So if a SHTTP-Cryptopts header binds options to a reference, then none of these global options apply, even if some of the options headers don't appear in the bound options 😭 Instead, the S-HTTP defaults found in Section 3.2.4.11 apply.
4. New Header Lines for HTTP 🌈
Two non-negotiation header lines for HTTP are defined here, and they're both very main character 👑
4.1. Security-Scheme 🛡️
All S-HTTP compliant agents MUST generate the Security-Scheme header in the headers of all HTTP messages they generate 📣 This header lets other agents detect that they're talking to an S-HTTP compliant agent, so they can generate the appropriate cryptographic options headers. It's giving teamwork 🫶
For implementations compliant with this specification, the value MUST be 'S-HTTP/1.4' ✨
4.1.1. Nonce-Echo 🔁
This header is used to return the value provided in a previously received Nonce: field. It has to go in the encapsulated headers so that it can be cryptographically protected 🔐
5. (Retriable) Server Status Error Reports 🚨
We describe here the special processing that's appropriate for client retries when servers return an error status. Not me panicking over error codes 😭
5.1. Retry for Option (Re)Negotiation 🔄
A server MAY respond to a client request with an error code that says the request hasn't completely failed, but the client may possibly achieve satisfaction through another request 🌸 HTTP already has this concept with the 3XX redirection codes 🧚
In the case of S-HTTP, it's conceivable (and honestly likely) that the server expects the client to retry their request using another set of cryptographic options. For example, the document with the anchor the client is dereferencing is old and didn't require a digital signature for the request in question, but now the server has a policy requiring a signature for dereferencing this URL 👀 These options SHOULD be carried in the header of the encapsulated HTTP message, exactly the way client options are carried 💜
The general idea is that the client will perform the retry in the manner indicated by the combo of the original request, the precise nature of the error, and the cryptographic enhancements depending on the options carried in the server response 🎀
The guiding principle for client response to these errors SHOULD be to give the user the same sort of informed choice about dereferencing these anchors as they'd get with normal anchor dereference. For instance, in the case above, it would be inappropriate for the client to sign the request without asking permission for the action 🙅♀️
5.2. Specific Retry Behavior 🎯
5.2.1. Unauthorized 401, PaymentRequired 402 💳
The HTTP errors 'Unauthorized 401' and 'PaymentRequired 402' represent failures of HTTP style authentication and payment schemes. S-HTTP has no explicit support for these mechanisms, but they can be performed under S-HTTP while taking advantage of the privacy services S-HTTP offers 🔒 (There are other errors for S-HTTP specific authentication errors too.)
5.2.2. 420 SecurityRetry 🔐
This server status reply exists so the server can tell the client that although the current request got rejected, a retried request with different cryptographic enhancements is worth attempting 🦋 This header SHALL also be used when an HTTP request was made but an S-HTTP request SHOULD have been made 🚨 Obviously this serves no useful purpose other than signalling an error if the original request SHOULD have been encrypted, but in other situations (e.g. access control) it may be useful 💅
5.2.2.1. SecurityRetries for S-HTTP Requests 🔁
In the case of a request that was made as an SHTTP request, it indicates that for some reason the cryptographic enhancements applied to the request were unsatisfactory, and that the request SHOULD be repeated with the options found in the response header 🌷 Note that this can be used as a way to force a new public key negotiation if the session key in use has expired, or to supply a unique nonce for the purposes of ensuring request freshness 🎲
5.2.2.2. SecurityRetries for HTTP Requests 🌈
If the 420 code is returned in response to an HTTP request, it indicates that the request SHOULD be retried using S-HTTP and the cryptographic options indicated in the response header 🧸
5.2.3. 421 BogusHeader 🙈
This error code indicates that something about the S-HTTP request was bad 💀 The error code is to be followed by an appropriate explanation, e.g.:
421 BogusHeader Content-Privacy-Domain must be specified5.2.4. 422 SHTTP Proxy Authentication Required 🧚
This response is analogous to the 420 response, except that the options in the message refer to enhancements that the client MUST perform in order to satisfy the proxy 🫶 Bestie, that's the whole vibe ✨
5.2.5. 320 SHTTP Not Modifed 🦋
okay so 320 is giving very specific proxy energy 🌸 It's only for when the proxy has put the If-Modified-Since header in the S-HTTP headers of its request. When the server sends this back, it means the next S-HTTP message has enough keying material for the proxy to forward the cached doc to the new requestor 🔑
In general, this looks like an S-HTTP message where the actual enhanced content is missing, but all the headers and keying material are still there 💖 (aka the optional content section of the CMS message has been removed 🙈). So if the original response was encrypted, the response has the original DEK re-covered for the new recipient ✨ (the server does the exact same processing it would have done in the server side caching case of 7.1, except the message body gets elided 🧚).
5.2.6. Redirection 3XX
These headers are internal to HTTP again, but they might carry S-HTTP negotiation options that matter to S-HTTP 🎀 The request should get redirected in the HTTP sense, with the right cryptographic precautions being observed 🔒
5.3. Limitations On Automatic Retries
Okay, real talk: letting clients automatically retry on this kind of server response opens the door to several kinds of attack 😭 Let's look at the simple credit card case:
The user views a document which requires his credit card. The user verifies that the DN of the intended recipient is acceptable and that the request will be encrypted and dereferences the anchor. The attacker intercepts the server's reply and responds with a message encrypted under the client's public key containing the Moved 301 header. If the client were to automatically perform this redirect it would allow compromise of the user's credit card.
Yikes 💀 The user did everything right and it still could've been leaked.
5.3.1. Automatic Encryption Retry
This is one possible danger of automatic retries: potential compromise of encrypted information 🙈 It's impossible to think of every case, but clients should never automatically reencrypt data unless the server asking for the retry proves it already has the data 👑 So reencrypting would be acceptable in these situations:
- The retry response was returned encrypted under an inband key freshly generated for the original request.
- The retry response was signed by the intended recipient of the original request.
- The original request used an outband key and the response is encrypted under that key.
This list isn't exhaustive, though 👀 Browser authors should be well advised to think carefully before adding automatic reencryption in any other cases. And when automatic reencryption isn't appropriate, the move is to query the user for permission 🫶
5.3.2. Automatic Signature Retry
We already discourage automatic signing (without user confirmation) even in the usual case, and with the dangers above in mind, automatically retrying signature enchancement is prohibited 🚫✍️ Hard no, bestie.
5.3.3. Automatic MAC Authentication Retry
As long as all the other conditions are followed, automatically retrying MAC authentication is permissible 🌈
6. Other Issues
6.1. Compatibility of Servers with Old Clients
Servers that get requests in the clear which should be secured should return SecurityRetry 420 with header lines set to indicate the required privacy enhancements 🛡️✨
6.2. URL Protocol Type
We define a new URL protocol designator, shttp 🦋 Using this designator in an anchor URL means the target server is S-HTTP capable, and that dereferencing this URL should go through S-HTTP processing 💜
Note that S-HTTP oblivious agents should not be willing to dereference a URL with an unknown protocol specifier. That means sensitive data won't get accidentally sent in the clear by users of non-secure clients 🙌
6.3. Browser Presentation
6.3.1. Transaction Security Status
While preparing a secure message, the browser should give a visual indication of how secure the transaction is, plus who can read the message 👀 While reading a signed and/or enveloped message, the browser should show that, and (if applicable) the identity of the signer 🔥 Self-signed certificates should be clearly differentiated from those validated by a certification hierarchy 🎀
6.3.2. Failure Reporting
Failing to authenticate or decrypt an S-HTTP message should look different from failing to retrieve the document 💅 Compliant clients may choose to display unverifiable documents, but they must clearly indicate that they were unverifiable, in a way that's clearly distinct from how they display documents with no digital signatures or documents with verifiable signatures 🌸
6.3.3. Certificate Management
Clients shall provide a method for determining that HTTP requests are to be signed, and for determining which certificate is used for signature (assuming there are many 🙈). It's suggested that users get some sort of selection list to pick a default from 💖 No signing should happen without some sort of explicit user interface action. That action can take the form of a persistent setting through a user preferences mechanism, though this is discouraged 🙅♀️
6.3.4. Anchor Dereference
Clients shall provide a method to display the DN and certificate chain associated with a given anchor before it's dereferenced, so users can see who their data is being encrypted for 🔐 This should be separate from the method for showing who signed the document containing the anchor, because these are orthogonal pieces of encryption information 🧚
7. Implementation Notes
7.1. Preenhanced Data
Okay, so S-HTTP has always supported preenhanced documents, but earlier versions never made it clear how to actually implement them 🌿 This section describes two methods: preenhancing the HTTP request/response, and preenhancing the underlying data ✨
7.1.1. Motivation
The two big motivations for preenhanced documents are security and performance 💫 These advantages mostly go to signing, but under special circumstances they can also apply to confidentiality or repudiable (MAC-based) authentication.
Picture a server that keeps serving the same content to a bunch of clients. Like a server that serves catalogs or price lists 🍓 Customers obviously want to verify that these are the actual prices. But since the prices are usually the same for everyone, confidentiality isn't really an issue. (Note: see Section 7.1.5 below for how to deal with this case as well 🦋).
So the server might want to sign the document once and just send the cached signed document out whenever a client makes a new request. That way it skips a private key operation every single time 🔑 Here's the wild part: the signed document might have been generated by a third party and dropped into the server's cache. The server might not even have the signing key 🤯 This shows the security benefit of presigning: untrusted servers can serve authenticated data with no risk, even if the server is compromised 🛡️👑
7.1.2. Presigned Requests/Responses
The obvious way to do this is to take a single request/response, cache it, and send it out in situations where a new message would otherwise be generated 💅
7.1.3. Presigned Documents
It's also possible with S-HTTP to sign the underlying data and send it as an S-HTTP message 🎀 To do this, you take the signed document (a CMS or MOSS message) and attach both S-HTTP headers (e.g. the S-HTTP request/response line, the Content-Privacy-Domain) and the necessary HTTP headers (including a Content-Type that reflects the inner content) ✨
SECURE * Secure-HTTP/1.4
Content-Type: text/html
Content-Privacy-Domain: CMS
Random signed message here...This message itself can't be sent 🙈 It needs to be recursively encapsulated, as described in the next section.
7.1.4. Recursive Encapsulation
As required by Section 7.3, the result above needs to be encapsulated itself to protect the HTTP headers 🔒 The obvious case [and the one illustrated here] is when confidentiality is required, but the auth enhancement or even the null transform might be applied instead 💜 So the message shown above can be used as the inner content of a new S-HTTP message, like so:
SECURE * Secure-HTTP/1.4
Content-Type: application/s-http
Content-Privacy-Domain: CMS
Encrypted version of the message above...To unfold this, the receiver decodes the outer S-HTTP message, re-enters the (S-)HTTP parsing loop to process the new message, sees that that one is S-HTTP too, decodes that, and recovers the inner content 🧚
Note that this approach can also give freshness of server activity (though not of the document itself) while still providing nonrepudiation of the document data, if a NONCE is included in the request 🌈
7.1.5. Preencrypted Messages
Preenhancement works best with signatures, but it can also be used with encryption under certain conditions 🍓 Picture the same confidential document going out again and again. You can save the time spent encrypting by caching the ciphertext and just generating a new key exchange block for each recipient ✨ [Note that this is logically equivalent to a multi-recipient message as defined in both MOSS and CMS, so care must be taken to use proper PKCS-1 padding if RSA is being used, since otherwise one may be open to a low encryption exponent attack [HAST96].
7.2. Proxy Interaction
Using S-HTTP makes things a bit tricky for HTTP proxies 🌸 Having the proxy blindly forward responses is straightforward, but it'd be better if S-HTTP aware proxies could still cache responses in at least some circumstances 💖 S-HTTP services should also be usable to protect client-proxy authentication too 🔐 This section explains how to hit those goals using the mechanisms described above.
7.2.1. Client-Proxy Authentication
When an S-HTTP aware proxy gets a request (HTTP or S-HTTP) that it requires to be S-HTTP authenticated (by whatever access control rules it uses, and only if it isn't already authenticated), it should return the 422 response code (5.7.4) 👑
When the client gets the 422 response code, it should read the cryptographic options the proxy sent and decide whether it's willing to apply that enhancement to the message 🫶 If the client is willing to meet those requirements, it should recursively encapsulate the request it sent earlier using the appropriate options. (Note that since the enhancement is recursively applied, even clients that are unwilling to send requests to servers in the clear may be willing to send the already encrypted message to the proxy without further encryption 🧚) (See Section 7.1 for another example of a recursively encapsulated message 🦋)
When the proxy receives a message like that, it should strip the outer encapsulation to recover the message that should be sent to the server ✨
8. Implementation Recommendations and Requirements 💅
okay so bestie, every S-HTTP agent must support the MD5 message digest and MAC authentication 🔐 and as of S-HTTP/1.4, all agents must also support RSA-MD5-HMAC 🫶
all S-HTTP agents must support Outband, Inband, and DH key exchange 🗝️
all agents must support encryption using DES-CBC 🔒
and agents must support signature generation and verification using NIST-DSS ✍️ that's the whole list, no cap 💖
9. Protocol Syntax Summary 📋
here's the cheat sheet of the main syntax bits in S-HTTP/1.4, minus the message encapsulation itself 🧚
9.1. S-HTTP (Unencapsulated) Headers 🎀
Content-Privacy-Domain: ('CMS' | 'MOSS')
Prearranged-Key-Info: <Hdr-Cipher>,<Key>,<Key-ID>
Content-Type: 'message/http'
MAC-Info: [hex(timeofday)',']<hash-alg>','hex(<hash-data>)','
<key-spec>9.2. HTTP (Encapsulated) Non-negotiation Options 🌸
Key-Assign: <Method>','<Key-Name>','<Lifetime>','
<Ciphers>';'<Method-args>
Encryption-Identity: <name-class>','<key-sel>','<name-args>
Certificate-Info: <Cert-Fmt>','<Cert-Group>
Nonce: <string>
Nonce-Echo: <string>9.3. Encapsulated Negotiation Options 🦋
SHTTP-Cryptopts: <scope>';'<string>(,<string>)*
SHTTP-Privacy-Domains: ('CMS' | 'MOSS')
SHTTP-Certificate-Types: ('X.509')
SHTTP-Key-Exchange-Algorithms: ('DH', 'RSA' | 'Inband' | 'Outband')
SHTTP-Signature-Algorithms: ('RSA' | 'NIST-DSS')
SHTTP-Message-Digest-Algorithms: ('RSA-MD2' | 'RSA-MD5' | 'NIST-SHS'
'RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC')
SHTTP-Symmetric-Content-Algorithms: ('DES-CBC' | 'DES-EDE-CBC' |
'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' |
'RC2-CBC' )
SHTTP-Symmetric-Header-Algorithms: ('DES-ECB' | 'DES-EDE-ECB' |
'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' | 'IDEA-ECB' |
'RC2-ECB')
SHTTP-Privacy-Enhancements: ('sign' | 'encrypt' | 'auth')
Your-Key-Pattern: <key-use>','<pattern-info>9.4. HTTP Methods 🍓
Secure * Secure-HTTP/1.49.5. Server Status Reports 🌈
Secure-HTTP/1.4 200 OK
SecurityRetry 420
BogusHeader 421 <reason>10. An Extended Example 🎀
okay this part is a contrived example of a whole back-and-forth of S-HTTP requests and replies ✨ the equal-sign rows are there to separate the story from the actual message traces 🙈 ngl the encrypted and signed bodies would normally look like binary garbage 💀 so to keep it readable, the request bodies are base64 encoded here. if you want the real S-HTTP messages, you just gotta strip the base64 back off the body 🫶
10.1. A request using RSA key exchange with Inband key reply 🔥
so Alice uses an S-HTTP-capable client and starts with a plain HTTP request, which gets her this response page 👀
============================================================
200 OK HTTP/1.0
Server-Name: Navaho-0.1.3.3alpha
Certificate-Info: CMS,MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqh
kiG9w0BBwEAAKCAM
IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH
gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc
29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N
TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e
SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA
xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q
cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx
zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi
rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8
2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB
gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd
GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd
GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M
jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd
XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB
gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX
Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A
QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc
PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM
Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA
AAAAA==
Encryption-Identity: DN-1779, null, CN=Setec Astronomy, OU=Persona
Certificate,O="RSA Data Security, Inc.", C=US;
SHTTP-Privacy-Enhancements: recv-required=encrypt
<A name=tag1 HREF="shttp://www.setec.com/secret">
Don't read this. </A>
============================================================so to request that URL, the matching HTTP request would look like this 👇
============================================================
GET /secret HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.2beta
Accept: *.*
Key-Assign: Inband,1,reply,des-ecb;7878787878787878
============================================================the extra Key-Assign line is the magic part ✨ it's not in an ordinary HTTP request, but it lets Bob (the server) encrypt his reply to Alice even though Alice doesn't have a public key, because they'll share a key once Bob gets the request 🗝️🫶 the request then gets wrapped up as an S-HTTP encapsulation like so:
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u
YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG
cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz
lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadXlw3oIAEgZBNcMexKe16
+mNxx8YQPukBCL0bWqS86lvws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHs1oK
BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW
Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k
1JLSAAAAAAAAAAAAAA==
============================================================the stuff between the delimiters is a CMS message, RSA enveloped for Setec Astronomy 🔐
Bob decrypts the request, finds the document, and is ready to serve it back to Alice 💌 here's a fitting HTTP server response:
============================================================
HTTP/1.0 200 OK
Security-Scheme: S-HTTP/1.4
Content-Type: text/html
Congratulations, you've won.
<A href="/prize.html"
CRYPTOPTS="Key-Assign: Inband,alice1,reply,des-ecb;020406080a0c0e0f;
SHTTP-Privacy-Enhancements: recv-required=auth">Click here to
claim your prize</A>
============================================================and when that response gets encapsulated as an S-HTTP message, it becomes:
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy
x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir
r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW
aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5
l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0
5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl
nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7
AAAAAAAAAAA=
============================================================the stuff between the delimiters is a CMS message encrypted under a randomly chosen DEK 🎲 which you can recover by computing:
DES-DECRYPT(inband:1,697fa820df8a6e53)where inband:1 is the key exchanged in the Key-Assign line of the original request 🧚
10.2. A request using the auth enhancement 🦋
there's a link on that HTML page that Alice clicks, which creates this HTTP message:
============================================================
GET /prize.html HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.1beta
Accept: *.*
============================================================and once it's encapsulated as an S-HTTP message, it looks like this:
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
MAC-Info:31ff8122,rsa-md5,b3ca4575b841b5fc7553e69b0896c416,inband:alice1
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp
dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx
LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA
============================================================the stuff between the delimiters is a CMS 'Data' representation of the request 📦
Appendix: A Review of CMS 📚
okay so CMS ("Cryptographic Message Syntax Standard") is a cryptographic message encapsulation format 💖 it's kinda like PEM and it's based on RSA's PKCS-7 cryptographic messaging syntax 🔐
CMS is only one of the two encapsulation formats S-HTTP supports, but it's the one you should reach for, because it lets you negotiate the least restricted set of options and it allows binary encoding 🫶 to keep this spec self-contained, here's a quick summary of CMS 🧚
CMS is defined using OSI's Abstract Syntax Notation (ASN.1, defined in X.208), and it's concretely represented with ASN.1's Basic Encoding Rules (BER, defined in X.209) 🌈 a CMS message is a sequence of typed content parts, and there are six content types, recursively composable:
- Data: some bytes, with no enhancement.
- SignedData: a content part with zero or more signature blocks and associated keying materials. Keying materials can be transported through the degenerate case of no signature blocks and no data.
- EnvelopedData: one or more (per recipient) key exchange blocks plus an encrypted content part.
- DigestedData: a content part with a single digest block.
- EncryptedData: an encrypted content part, with key materials provided externally.
since not everyone speaks ASN.1 fluently 🙈 here's an informal BNF version of the syntax (with plenty of gloss). in the actual encoding, most productions have explicit tag and length fields.
Message = *Content
Content = Data | SignedData | EnvelopedData |
DigestedData | EncryptedData
Data = Bytes
SignedData = *DigestAlg Content *Certificates
*CRLs SignerInfo*
EnvelopedData = *RecipientInfo BulkCryptAlg
Encrypted(Content)
DigestedData = DigestAlg Content DigestBytes
EncryptedData = BulkCryptAlg Encrypted(Bytes)
SignerInfo = CertID ... Encrypted(DigestBytes) ...
RecipientInfo = CertID KeyCryptAlg Encrypted(DEK)Appendix: Internet Media Type message/s-http 🎀
Okay bestie, this appendix is where the doc does its paperwork 💅 Besides defining S-HTTP/1.4, this document is also the spec for the media type "message/s-http", and it's getting registered with IANA. Here's the registration info:
Media Type name: message
Media subtype name: s-http
Required parameters: none
Optional parameters: version, msgtype
version: The S-HTTP version number of the enclosed message
(e.g. "1.4"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response".
If not present, the type can be determined from the
first line of the body.
Encoding considerations: only "7bit", "8bit", or "binary"
are permitted.
Security considerations: this is a security protocol.So the optional parameters are version and msgtype, and there are no required ones 🦋 Encoding is limited to "7bit", "8bit", or "binary" ✨
Bibliography and References 📚
Here's every source the doc leans on, bestie 🌸
- [BELL96] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash Functions for Message Authentication", Preprint.
- [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 (supersedes FIPS PUB 46, 1977 January 15).
- [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
- [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
- [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 1994 May 19.
- [HAST86] Hastad, J., "On Using RSA With Low Exponents in a Public Key Network," Advances in Cryptology-CRYPTO 95 Proceedings, Springer-Verlag, 1986.
- [JOHN93] Johnson, D.B., Matyas, S.M., Le, A.V., Wilkins, J.D., "Design of the Commercial Data Masking Facility Data Privacy Algorithm," Proceedings 1st ACM Conference on Computer & Communications Security, November 1993, Fairfax, VA., pp. 93-96.
- [KRAW96b] Krawczyk, H. personal communication.
- [LAI92] Lai, X. "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
- [PKCS-6] RSA Data Security, Inc. "Extended Certificate Syntax Standard", PKCS-6, Nov 1, 1993.
- [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
- [RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
- [RFC-1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
- [RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
- [RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
- [RFC-1779] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
- [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, September 1993.
- [RFC-1738] T. Berners-Lee, "Uniform Resource Locators (URLs)", RFC 1738, December 1994.
- [RFC-1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Muliparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
- [RFC-1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME Object Security Services", RFC 1848, October 1995.
- [RFC-1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
- [RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2616, June 1999.
- [RFC-2617] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
- [RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [SHTML] Rescorla, E. and A. Schiffman, "Security Extensions For HTML", RFC 2659, August 1999.
- [VANO95] B. Prennel and P. van Oorschot, "On the security of two MAC algorithms", to appear Eurocrypt'96.
- [X509] CCITT Recommendation X.509 (1988), "The Directory - Authentication Framework".
Security Considerations 🔥
Okay this one is short but SO serious 😭 This entire document is about security. Every single part of it is about keeping your messages safe, so take it all very seriously, periodt 💀🔒
Authors' Addresses 🦋
The brilliant minds behind this doc are Eric Rescorla and Allan M. Schiffman 👑
Eric Rescorla
RTFM, Inc.
30 Newell Road, #16
East Palo Alto, CA 94303
Phone: (650) 328-8631
EMail: ekr@rtfm.com
Allan M. Schiffman
SPYRUS/Terisa
5303 Betsy Ross Drive
Santa Clara, CA 95054
Phone: (408) 327-1901
EMail: ams@terisa.com15. Full Copyright Statement 🌈
Copyright (C) The Internet Society (1999). All Rights Reserved.
Here's the legal stuff, bestie, and it's important 💅 You can copy and share this document, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute all of that, in whole or in part, without restriction, as long as the above copyright notice and this paragraph are on every copy and derivative work. The document itself can't be modified in any way, though. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The one exceptions are developing Internet standards, where the Internet Standards process copyright procedures have to be followed, or translating it into languages other than English. The permissions above are perpetual and the Internet Society and its successors or assigns won't revoke them ✨
This document and the information in it are provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're literally the reason this all exists 💖
📦 where this page comes from
- ietf: rfc2660 1999-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms