From bef2417095f9bd066a82616ed04d356492dda2ef Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 1 Nov 2016 10:27:48 +1100 Subject: [PATCH 1/2] Fix examples --- draft-ietf-httpbis-encryption-encoding.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/draft-ietf-httpbis-encryption-encoding.md b/draft-ietf-httpbis-encryption-encoding.md index 8903c87e5..a7085ae33 100644 --- a/draft-ietf-httpbis-encryption-encoding.md +++ b/draft-ietf-httpbis-encryption-encoding.md @@ -374,9 +374,10 @@ HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 33 Content-Encoding: aes128gcm -Crypto-Key: aes128gcm=6Aqf1aDH8lSxLyCpoCnAqg +Crypto-Key: aes128gcm=B33e_VeFrOyIHwFTIfmesA -lVIUs_H0A2a8-6dhmzY57H4K4uRFCF6tIIPRO9vrOL6B +9Y1iaZMzICC05DO3y8dWiAAAopoAzpM9l8LHdpDaO9C-UvT4kttTI_edSsHv1o5b +lWZ5mBYL ~~~ Note that the media type has been changed to "application/octet-stream" to avoid @@ -397,8 +398,8 @@ Content-Length: 70 Content-Encoding: aes128gcm Crypto-Key: keyid="a1"; aes128gcm="BO3ZVPxUlnLORbVGMpbT1Q" -iBmR5fjBCUvicKLSt1L1GQAAAAoCYTGZvfb0yACNxTo090xk6m_6GwMiLv4AxGSS -_BFGyZS_2z_cOxSHLfuPsAQiId243MTE8B_5Vg-R5OPTNbiV3PlHJcjGONoI +_lgOPHdbKmIaLnZC7_8huQAAAAoCYTGkQWUSYylMKzMduBHDCFDwL2oODx8nkh0n +uOTNrh48DaWSm02DiQPzQAOGe6xRAeBj588hH6jQRTh_szFRS2Nwx9Aeuiic ~~~ @@ -596,16 +597,16 @@ to a JWE object that might be expressed using the JWE Compact Serialization: from the input keying material (see {{nonce}}). This value is also not transmitted. -* The final value is the concatenated JWE Ciphertext and the JWE Authentication - Tag, both expressed without base64url encoding. The "." separator is omitted, - since the length of these fields is known. +* The final value is the concatenated header, JWE Ciphertext, and JWE + Authentication Tag, all expressed without base64url encoding. The "." + separator is omitted, since the length of these fields is known. Thus, the example in {{explicit}} can be rendered using the JWE Compact Serialization as: ~~~ example eyAiYWxnIjogImRpciIsICJlbmMiOiAiQTEyOEdDTSIgfQ..31iQYc1v4a36EgyJ. -VDeU0XxaJkOJDAxPl7h9JD4.VfDeN0aKz-z36T3WWULsBQ +AM6TPZfCx3aQ2jvQvlL0-JLb.21Mj951Kwe_WjluVZnmYFgs ~~~ Where the first line represents the fixed JWE Protected Header, an empty JWE @@ -619,5 +620,5 @@ Authentication Tag. Mark Nottingham was an original author of this document. The following people provided valuable input: Richard Barnes, David Benjamin, -Peter Beverloo, Mike Jones, Stephen Farrell, Adam Langley, John Mattsson, Julian +Peter Beverloo, JR Conlin, Mike Jones, Stephen Farrell, Adam Langley, John Mattsson, Julian Reschke, Eric Rescorla, Jim Schaad, and Magnus Westerlund. From 5c604831c8dc203c763a78d13d68ab62715ea1eb Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 1 Nov 2016 16:38:46 +1100 Subject: [PATCH 2/2] Try to explain and justify the use of the absolute form in HTTP/1.1 --- draft-ietf-httpbis-http2-encryption.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-http2-encryption.md b/draft-ietf-httpbis-http2-encryption.md index 02840f4f7..345b6800f 100644 --- a/draft-ietf-httpbis-http2-encryption.md +++ b/draft-ietf-httpbis-http2-encryption.md @@ -102,8 +102,14 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S An origin server that supports the resolution of `http` URIs can indicate support for this specification by providing an alternative service advertisement {{RFC7838}} for a protocol -identifier that uses TLS, such as `h2` {{RFC7540}}, or `http/1.1` {{?RFC7301}}. Note that HTTP/1.1 -requests MUST use the absolute form (see Section 5.3.2 of {{RFC7230}}). +identifier that uses TLS, such as `h2` {{RFC7540}}, or `http/1.1` {{?RFC7301}}. + +Requests for `http` resources using TLS MUST include the scheme in the request. HTTP/2 requires +this and provides the `:scheme` pseudo-header field for this purpose. HTTP/1.1 provides no such +field, and even prohibits the use of the absolute form for requests that are sent directly to an +origin server (see Section 5.3.1 of {{RFC7230}}). This document overrides that requirement for +requests with the `http` scheme that are sent over TLS; these requests MUST be made using the +absolute form as though the server were a proxy. A client that receives such an advertisement MAY make future requests intended for the associated origin ({{RFC6454}}) to the identified service (as specified by {{RFC7838}}), provided that the