Subject: Working Group Last Call: Encrypted Content-Encoding for HTTP

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Jun 2016 16:22:54 +1000

<https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-01>

We don't have any open issues for this draft, and Martin thinks it's ready for WGLC.

Please have a careful read through and raise any issues you find, and state your support (or lack thereof) on list. In particular, if have implemented it, or intend to, it would be helpful to know this.

WGLC will end in two weeks (21-6-16).

Note that a few small editorial changes are waiting in the repo (see last two commits in <https://github.com/httpwg/http-extensions/commits/master/draft-ietf-httpbis-encryption-encoding.md>), and we probably need to update some of the references (e.g., FIPS180-4 to RFC6234, which is already in the downref registry). That doesn't need to block WGLC, though.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 Jun 2016 07:10:31 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
tes:

>Please have a careful read through and raise any issues you find, and 
>state your support (or lack thereof) on list. In particular, if have 
>implemented it, or intend to, it would be helpful to know this.

People do stupid things based on examples, when they don't fully grasp
the subject matter.

Therefore examples should be designed to not inspire trouble.

For instance 5.1:

   HTTP/1.1 200 OK
   Content-Type: application/octet-stream
   Content-Encoding: aesgcm
   Connection: close
   Encryption: keyid="http://example.org/bob/keys/123";
               salt="XZwpw6o37R-6qoZjw6KwAw"

   [encrypted payload]

   Here, a successful HTTP GET response has been encrypted using input
   keying material that is identified by a URI.

Keyid is defined as "a string" (BTW: Not obvious if 'string' should
be understood as some ABNF term), and a URI is a perfectly valid string.

But by overspecializing the example, some idiot, somewhere, will
interpret it to mean that the actual key should be fetchable at a
URL - and create a gaping hole in one million consumer devices.

Yes, it says "identified by a URI" right there, and that is perfectly
clear - provided you understand english well enough.

The use of "mailto:" URI's is even worse:  I can see people scratching
their head wondering how long their program should wait for the
reply before timing out, and decide to use the http: variant instead
"because it will be much faster".

I propose that we do not use URIs as keyid in any of the examples,
but rather plain strings with no overloaded context such as
keyid="key01294".

People should be smart enough to realize on their own that URIs are
valid strings, but a footnote could remind them.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jun 2016 12:51:11 +1000

> but rather plain strings with no overloaded context such as

Aw, you picked up on my terrible examples.  I think that I might have
thought that the mailto: one was a good enough signal, or that the
lack of an 's' in http:// was enough to make someone think twice.  But
you are right, people just aren't always that smart.

For you: https://github.com/httpwg/http-extensions/pull/196

See

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 8 Jun 2016 07:34:12 +0200

> you are right, people just aren't always that smart.

People are even worse than that, most of them don't read the spec and
will copy-paste from blogs, and the "smart" among them will say "look,
I've read the standard and it is supposed to work this way" :-)

While we're talking about the form, I'm seeing that all examples involve
multi-line header fields, which are deprecated according to 7230#3.2.4.
I obviously understand that it's easier for the presentation. In 5.6,
it's mentionned that line wrapping is added for for presentation purposes
only. Maybe a sentence about this should be added at the end of "3.",
something like :

   Please note that all examples in this document use line wrapping for
   presentation purposes but headers fields should be sent as a single
   line to comply with RFC7230.

And then you can drop the sentence from 5.6.

Best regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 Jun 2016 06:04:14 +0000

--------
In message <CABkgnnVsJpLntah=[email-masked]>
>For you: https://github.com/httpwg/http-extensions/pull/196

keyid as "sequence of octets" sounds too liberal to me, do you really
want to allow SOH, NL and ESC ?

I thought there were a canonical ABNF for a string element of a HTTP
header we could lean on somewhere ?

---

From: Craig Pratt <[email-masked]>
Date: Tue, 7 Jun 2016 23:36:05 -0700

On 6/7/16 11:04 PM, Poul-Henning Kamp
wrote:

--------

There's "token", defined in RFC 7230. It allows some punctuation
characters, but it's certainly more restricted than 1*OCTET.

token          = 1*tchar

tchar          = "!" / "#" / "$" / "%" / "&" / "’"
/ "*"

/ "+" / "-" / "." / "^" / "_" / "‘" /
"|" / "~"

/ DIGIT / ALPHA

Is that what you're thinking of perhaps?

cp

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 Jun 2016 06:50:00 +0000

--------

>    characters, but it's certainly more restricted than 1*OCTET. 

That is probably going too far the other way since it doesn't allow
':' and therefore cannot contain a URL.

Maybe the "quoted-string" from RFC7230 3.2.6 ?

     quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
     qdtext         = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
     obs-text       = %x80-FF
     quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

r maybe simply point at RFC7230 3.2.6, since that talks about
HTTP headers in general ?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jun 2016 17:16:28 +1000

You will find that there is indeed a definition. The abnf permits token and
quoted-string. But the actual value is a sequence of octets. If this were
another protocol I would use Unicode strings.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 8 Jun 2016 19:18:08 +1200

> HTTP headers in general ?

Why the pick between them? isn't there an ongoing WG intention to make
field-values more consistently a generic:

 token BWS "=" BWS ( token / quoted-string )

Amos

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jun 2016 17:33:42 +1000

>From the draft:

  Encryption = #encryption_params
  encryption_params = [ parameter *( ";" parameter ) ]

>From RFC 7231, which the draft cites:

   parameter = token "=" ( token / quoted-string )

Good enough?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 Jun 2016 08:01:00 +0000

--------
In message <[email-masked]>
>   parameter = token "=" ( token / quoted-string )

It was the "a string" in this para which tripped up my reading:

   keyid:  The "keyid" parameter contains a string that identifies the
      keying material that is used.  The "keyid" parameter SHOULD be
      included, unless key identification is guaranteed by other means.

(probably because to a programmer like me "a string" signals type
and usually also double quotes.)

I suggest it simply be removed:

   keyid:  The "keyid" parameter indentifies the keying material used.
      The "keyid" parameter SHOULD be included, unless key
      identification is guaranteed by other means.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jun 2016 19:26:15 +1000

> I suggest it simply be removed:

WFM.  Here's what I have in the end, with the clarifications I think
help overall:

> The "keyid" parameter identifies the keying material that is used.  When the
  Crypto-Key header field is used, the "keyid" identifies a matching value in
  that field.  The "keyid" parameter MUST be used if keying material included
  in an Crypto-Key header field is needed to derive the content encryption key.
  The "keyid" parameter can also be used to identify keys in an
  application-specific fashion.

...and I'm sure that's too much information.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 Jun 2016 10:13:16 +0000

--------
In message <CABkgnnVXT18UepV93_Bx82qhNGu8A1+tK=[email-masked]>
>  application-specific fashion.

Works for me.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jun 2016 16:41:38 +0200

Hi,

I have reviewed the draft. Sorry for being a bit late, but I hope my 
comments can be of use.

1. Section 2:
    The record size defaults to 4096 octets, but
    can be changed using the "rs" parameter on the Encryption header
    field.

I think this default value is quite small. If one want to do random 
access the record boundaries becomes a question of the need for random 
access into the resource and the need for streaming data that can be 
released from the decryption and integrity verification at record 
boundaries. I think the text could be more clear on the motivation and 
trade-offs here.

I also think there need to be discussion of the case where a single 
record with actual data is all that is needed.

2. Section 2:

           +------+         input of between rs-65537
           | data |            and rs-2 octets
           +------+      (one fewer for the last record)
               |

First I interpreted this figure part as a limitation in RS sizes. I 
didn't graso that it was RS minus number of padding bytes (2-65537) of 
data in this particular record that was the intention. I think it could 
benefit from a clarification of that it is "rs minus padding size 
(2-65537) number of bytes".

3. Section 2:

    A sequence of full-sized records can be truncated to produce a
    shorter sequence of records with valid authentication tags.  To
    prevent an attacker from truncating a stream, an encoder MUST append
    a record that contains only padding and is smaller than the full
    record size if the final record ends on a record boundary.  A
    receiver MUST treat the stream as failed due to truncation if the
    final record is the full record size.

This is clear on truncation at the end of the resource. However, it 
fails to describe how one detect and handle reordering or truncation 
from front. To my understanding it is the nonce derivation and the need 
for correctly knowing the sequence number of a record that prevents that 
attack. So that failure in decrypting and verifying a record may depend 
on reordering or truncation from front. Then that it may also depend on 
data corruption or other reasons is another matter.

4. Section 3.1:

    rs:  The "rs" parameter contains a positive decimal integer that
       describes the record size in octets.  This value MUST be greater
       than 1.  If the "rs" parameter is absent, the record size defaults
       to 4096 octets.

This specifies no upper limit for the value of RS. Can I use a value 
larger than a 32-bit integer? I see there is a point of providing the 
implementors a guidance on what values may occur here. It is also 
clearly dependent on the algorithms security properties, which may 
introduce limitations. To my knowledge the limit for AES-GCM is 2^39-256 
bytes to maintain the security properties.

5. Section 3.2:

Several of the abbreviations such as PRK and CEK are not explained.

6. Section 3.2:

   CEK = HMAC-SHA-256(PRK, cek_info || 0x01)

What is the 0x01 concatenated to the cek_info before the hashing? I 
would guess some sequence number for avoiding key reuse, but it is not 
clear that it is needed due to different inputs in the first and second 
step.

7. Section 4 and 4.1:

    aesgcm:  The "aesgcm" parameter contains the base64url-encoded octets
       [RFC7515] of the input keying material.

I don't understand why this parameter is called "aesgcm". To me the only 
requirements on the IKM is that is is at least 16 bytes and have been 
bas64URL encoded when put into the header. So what is the relation to 
AESGCM?

8. Section 5.3:

Section 3 says:

    Encryption header field values with multiple instances of the same
    parameter name are invalid.

The example in 5.3 is:

    PUT /thing HTTP/1.1
    Host: storage.example.com
    Content-Type: application/http
    Content-Encoding: aesgcm, aesgcm
    Content-Length: 1235
    Encryption: keyid="mailto:[email-masked]";
                salt="NfzOeuV5USPRA-n_9s1Lag",
                keyid="http://example.org/bob/keys/123";
                salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

Isn't this example violating the rules in Section 3 for the Encryption 
header?

9. Section 5.4 and 2:

I find nothing in Section 2 that indicates that there are requirement of 
supporting a mode of a single record of encryption. My reading indicates 
that the minimal usage is possibly first a single record followed by a 
padded stop record. It is also not clear that the "rs" parameter is 
optional.

Please clarify.

10. Section 3:

    The Encryption header MAY be omitted if the sender does not intend
    for the immediate recipient to be able to decrypt the payload body.
    Alternatively, the Encryption header field MAY be omitted if the
    sender intends for the recipient to acquire the header field by other
    means.

I wonder about this. If the Encryption header is omitted how is the 
receiving agent knowing how to later match the resource with the correct 
key-management data. URI and etag? I mean if one include the key-id for 
the received resource then one know that one has the right key in 
relation to the resource version one have stored. It might even be the 
case that a later version of the resource is protected using the same 
key but with a different salt.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jun 2016 13:47:41 +1000

Thanks Magnus,

I've created a PR that I hope addresses your comments:
  https://github.com/httpwg/http-extensions/pull/202

More detail inline.

On 22 June 2016 at 00:41, Magnus Westerlund
<[email-masked]> wrote:
> I think this default value is quite small. If one want to do random access
> the record boundaries becomes a question of the need for random access into
> the resource and the need for streaming data that can be released from the
> decryption and integrity verification at record boundaries. I think the text
> could be more clear on the motivation and trade-offs here.
>
> I also think there need to be discussion of the case where a single record
> with actual data is all that is needed.

Yes, the discussion on the trade-off needs to be had.  I added a
couple of paragraphs on it.  Obviously, there are lots of tradeoffs
here.

> First I interpreted this figure part as a limitation in RS sizes. I didn't
> graso that it was RS minus number of padding bytes (2-65537) of data in this
> particular record that was the intention. I think it could benefit from a
> clarification of that it is "rs minus padding size (2-65537) number of
> bytes".

I've taken your input and tweaked the diagram and ensuing text in
light of that.  I think that it's clearer now. Let me know if you
think it could be improved further.

> This is clear on truncation at the end of the resource. However, it fails to
> describe how one detect and handle reordering or truncation from front. To
> my understanding it is the nonce derivation and the need for correctly
> knowing the sequence number of a record that prevents that attack. So that
> failure in decrypting and verifying a record may depend on reordering or
> truncation from front. Then that it may also depend on data corruption or
> other reasons is another matter.

I have added a comment explaining that the nonce construction prevents
removal and reordering of records.  Not sure if that is what you were
looking for.

> This specifies no upper limit for the value of RS. Can I use a value larger
> than a 32-bit integer? I see there is a point of providing the implementors
> a guidance on what values may occur here. It is also clearly dependent on
> the algorithms security properties, which may introduce limitations. To my
> knowledge the limit for AES-GCM is 2^39-256 bytes to maintain the security
> properties.

Ahh yes, a good point.  I will add a note on limits.  Note that RFC
5116 says 2^36-31 per record.

The IND-CPA limits are block-based, which makes this harder, but I now
have a citation that I can use.

> What is the 0x01 concatenated to the cek_info before the hashing? I would
> guess some sequence number for avoiding key reuse, but it is not clear that
> it is needed due to different inputs in the first and second step.

This is a reduction of what HKDF does.  The complete HKDF is:

   T(0) = empty string (zero length)
   T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
   T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
   T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)

   T = T(1) | T(2) | T(3) | ... | T(N)
   OKM = first L octets of T

I've just included what this reduces to.

> bas64URL encoded when put into the header. So what is the relation to

This just marks the IKM as being used for this content-encoding
scheme.  That way, there's less chance that the key is used for some
other purpose.  Of course, with the info parameter on key expansion,
it's not strictly necessary, but I didn't think that a new name would
be that much of an improvement (I guess we could call it "ikm", but
it's not much clearer then).

> Isn't this example violating the rules in Section 3 for the Encryption

You will observe that there are two "values" here, separate by the
comma.  Parameters are separated by the semi-colon.

Happy to take suggestions on how to make this clearer, HTTP header
fields are sometimes confusing.

> padded stop record. It is also not clear that the "rs" parameter is

The minimal usage is a single record, with rs=<longer than the input + padding>.

The doc has: "If the "rs" parameter is absent, the record size
defaults to 4096 octets."  Added "The "rs" parameter is optional." to
this.  Is that enough?

> key-management data. URI and etag? I mean if one include the key-id for the
> received resource then one know that one has the right key in relation to
> the resource version one have stored. It might even be the case that a later
> version of the resource is protected using the same key but with a different
> salt.

What motivated this was the out-of-band encoding, where the Encryption
header field is sent separately.  However, over time, I think that
we've concluded that the content-encoding is signaled at the same
place as the Encryption header field (see below).  I think that we can
remove this paragraph.

Originally:
200 OK
Content-Encoding: out-of-band

{ ... URLs and decryption keys ... }

More recent thinking:
200 OK
Content-Encoding: out-of-band, aesgcm
Encryption: salt=..., rs=...

{ ... URLs ... }

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Jun 2016 17:06:02 +0200

>   https://github.com/httpwg/http-extensions/pull/202

Thanks,

The changes looks good, I have some few proposed modifcations inline. 
And following up on some of the other issues inline.

> couple of paragraphs on it.  Obviously, there are lots of tradeoffs

Yes, what you wrote in the PR i think is sufficient. It at least points 
to that the implementor needs to consider this issue.

> think it could be improved further.

I think one tweak may be worth doing:

"add padding to rs octets;"

To

"add padding to get rs octets;"

Otherwise it is not clear that the combination of data and padding is RS 
octets long.

> removal and reordering of records.  Not sure if that is what you were

Yes, that is what I was looking for. However, I think the proposed text:

"This nonce construction prevents removal or reordering of records."

Should be changed slightly to point out that it prevents changes except 
for truncation of the tail of the sequence. That is after all prevented 
through the different size of the last record.

> 5116 says 2^36-31 per record.

Okay, I did a quick search and saw a limit quoted from the NIST spec, 
but that might have been for some other configuration. You should 
definitly point to RFc5116 values.

However, I think the other part of this comment is the question can one 
put a limitation on how big value rs can be at all. Like max 2^64? 
Simply as guidance to implementors? I know this hasn't been the usual 
style in HTTP related specs to put upper limit to values.

> I've just included what this reduces to.

Okay, get it know.

> it's not much clearer then).

So this comes down to the question if one likes to define one new 
Crypto-Key parameter for each new cipher version of the encrypted 
content encoding, or if one likes to have a generic explicitly included 
IKM material string, where one uses only the Key-ID to bind to the 
specific encoding.

Considering the potential confusion in cases with multiple encryptions 
and different ciphers it might be better to keep the IKM input ciper 
specific. I don't see that there will be that many different ciphers so 
that defining a different IKM carrier per cipher that needs them is to 
large a burden. However, if the WG agrees with this reasoning then I 
think the definition in Section 4 of "aesgcm" should be expanded to:

    aesgcm:  The "aesgcm" parameter contains the base64url-encoded octets
       [RFC7515] of the input keying material for the "aesgcm" content
       encoding.

> fields are sometimes confusing.

I think my confusion stems from the usage of "name" in the limitation 
definition. To me when discussing the parameters, that follows this ABNF 
rule:

And this is a name = value pair. Thus, to correct the limiation if that 
is intended to say that it is not okay to include multiple identical 
name value pairs then it should be changed to:

     Encryption header field values with multiple instances of the same
     parameter name and value is invalid.

> defaults to 4096 octets."  Added "The "rs" parameter is optional." to

No, because there is text in Section 2 that says:

    The "aesgcm" content-coding uses a fixed record size.  The resulting
    encoding is a series of fixed-size records, with a final record that
    is one or more octets shorter than a fixed sized record.

As this says there is series, i.e. more than one record. And a 
requirement that the last is shorter than "rs". I have found no text in 
the rest of the section contradicting this and saying that a single 
record is allowed.

I think the easiest way of fixing this is to be explicit in the above 
paragraph:

    The "aesgcm" content-coding uses a fixed record size.  The resulting
    encoding is either a single record or series of fixed-size records,
    with a final record that is one or more octets shorter than a fixed
    sized record. Note that for single record use the value of fixed
    sized record parameter "rs" MUST be larger than the single record
    created.

> place as the Encryption header field (see below).  I think that we can

I think I need to think more on the removal and discuss with my 
colleagues more. I become uncertain what the implications become in the 
case one applies resource maps for the Out of band encoding as discussed 
in B.2 of 
https://tools.ietf.org/html/draft-reschke-http-oob-encoding-06#appendix-B.2

In that case one will not include the Encryption header for the 
resources that are included in the resource map, they will instead be 
moved into the resource map. Thus, there may still be cases where one 
would not included the Encryption header, but it is instead provided in 
equivalent steps provided by other mechanism.

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jun 2016 16:43:04 +1000

Thanks again, I've added your suggested changes to the PR.

Trimming aggressively here.

On 23 June 2016 at 01:06, Magnus Westerlund
<[email-masked]> wrote:
> However, I think the other part of this comment is the question can one put
> a limitation on how big value rs can be at all. Like max 2^64? Simply as
> guidance to implementors? I know this hasn't been the usual style in HTTP
> related specs to put upper limit to values.

I see no reason to set a lower limit than RFC 5116 has here.  Most
modern machines are happy with 64-bit numbers, and those that are less
happy probably don't want to deal with that much data anyway.  I've
set rs to the maximum plaintext defined in RFC5116.

> So this comes down to the question if one likes to define one new Crypto-Key
> parameter for each new cipher version of the encrypted content encoding, or
> if one likes to have a generic explicitly included IKM material string,
> where one uses only the Key-ID to bind to the specific encoding.

6 of one, half-dozen of the other :)  I've adopted your proposed edit.

> And this is a name = value pair. Thus, to correct the limiation if that is
> intended to say that it is not okay to include multiple identical name value
> pairs then it should be changed to:
>

I think that implies a narrower restriction, that is that a=b;a=b is
bad, but a=b;a=c maybe isn't.  How about I instead modify the
paragraph before to make it clear that multiple encryptions ==>
multiple header field values.  That should help clarify what the
document means by header field values.

>    sized record parameter "rs" MUST be larger than the single record

I've paraphrased, but this is a fine change.

> I think I need to think more on the removal and discuss with my colleagues
> more. I become uncertain what the implications become in the case one
> applies resource maps for the Out of band encoding as discussed in B.2 of

I've convinced myself that this is OK by considering resource maps as
a form of aggressive compression for HTTP/2 server push.  I know that
Göran and others have a different conception of this, so if you find
that this doesn't work, we should discuss it.

Given that the removed paragraph doesn't actually stipulate any
requirements, I think that we could change our view about where things
live and simply write down those conclusions in a newer document.

---

From: Göran Eriksson AP <[email-masked]>
Date: Thu, 23 Jun 2016 10:38:09 +0000

>>colleagues

My view is that there are different ways to deliver a resource map, one of
which is HTTP/2 Server Push, another delivering it as a “web resource”
using the Link header. Pro’s and con’s and depends on client realisation
and other stuff.
So not about what works and what not as I see it (still).

I expect future drafts about resource map delivery to touch on this and
trigger a proper discussion in the WG.

>live and simply write down those conclusions in a newer document.

+1.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Jun 2016 13:16:15 +0200

Hi,

Some few comments, but I think these issues have resolution from my 
perspective.

> set rs to the maximum plaintext defined in RFC5116.

Fully agree that there are no point of using a lower number than what 
RFC5116 says for AESGCM. However, the Encryption header is clearly not 
AESGCM specific, thus in future definitions we might se RS values that 
can be larger. That was my initial point here.

I guess implementors HTTP parameter parsers are going to be robust to 
unknown field lengths. Thus, specifying the maximum RS on a per encoding 
(cipher) level is probably fine.

> document means by header field values.

Yes, that is probably less confusing.

> live and simply write down those conclusions in a newer document.

Yes, I believe this is fine.

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jun 2016 07:11:49 +1000

On 23 June 2016 at 21:16, Magnus Westerlund
<[email-masked]> wrote:
> AESGCM specific, thus in future definitions we might se RS values that can
> be larger. That was my initial point here.

Ah, I'm being dense.  I see where you were going there.  Since the rs
field is only really usable at the point that you understand the
content encoding, can we not say that *for aesgcm* the limit is X.
Others might define a different limit.  A generic parser reads the
value as a string, so they won't be affected by limits.