Subject: [smime] HTTP Encrypted Content-Encoding

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Apr 2015 11:16:16 -0700

It was suggested by Paul that I seek feedback on this work here.

Here:
https://tools.ietf.org/html/draft-nottingham-http-encryption-encoding

Updated, not submitted, version:
https://github.com/mnot/I-D/blob/master/http-encryption-encoding/draft.md

It doesn't have any ASN.1 or OIDs, sorry.  And no prizes for finding
the bug in the published version.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 14:12:13 -0700

> the bug in the published version.

In particular, I think that CMS encrypted types might be useful here to give them more flexibility than what they have now, and so they don't eventually have to reinvent a bunch of CMS. It also might be overkill. Thoughts?

--Paul Hoffman

---

From: Sean Turner <[email-masked]>
Date: Wed, 1 Apr 2015 18:03:35 -0400

> In particular, I think that CMS encrypted types might be useful here to give them more flexibility than what they have now, and so they don't eventually have to reinvent a bunch of CMS. It also mig…

There’s also these media type registrations but it definitely assumes CMS:
http://datatracker.ietf.org/doc/rfc7193/?include_text=1

But isn’t this kind of re-inventing some parts of S-HTTP ;)
http://datatracker.ietf.org/doc/rfc2660/?include_text=1

spt

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 15:31:01 -0700

> http://datatracker.ietf.org/doc/rfc2660/?include_text=1

I don't care if they're re-doing SHTTP; that's their call, not ours. My concern is them possibly badly creating an enveloped object. If envelopedData works well for them, great; if not, let's be sure to help them avoid pitfalls.

--Paul Hoffman

---

From: Sean Turner <[email-masked]>
Date: Wed, 1 Apr 2015 18:44:34 -0400

> I don't care if they're re-doing SHTTP; that's their call, not ours. My concern is them possibly badly creating an enveloped object. If envelopedData works well for them, great; if not, let's be su…

I agree not sure how you’d draw any other conclusion from my message.

spt

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Apr 2015 16:43:25 -0700

> In particular, I think that CMS encrypted types might be useful here to give them more flexibility than what they have now, and so they don't eventually have to reinvent a bunch of CMS. It also mig…

It was an explicit goal to NOT have flexibility in addition to what is
provided by content-encoding negotiation.  That is, if
chacha20-poly1305 was considered categorically better, a new
content-encoding would be needed and support for it negotiated using
the mechanisms that HTTP provides.

> If envelopedData works well for them, great; if not, let's be sure to help them avoid pitfalls.

When I looked at this, it was not apparent that CMS was capable of
supporting the streaming use case.  That meant defining new algorithms
and OIDs for an algorithm that did support that.

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Apr 2015 11:12:28 -0400

> the mechanisms that HTTP provides.

I do not understand the desire to avoid crypto agility.

Russ

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Apr 2015 09:22:13 -0700

> I do not understand the desire to avoid crypto agility.

It's not a desire to avoid agility; it's a desire to have the agility
mechanisms align with the extensibility model that is already in
place.