Re: [Atlas] Request signing

Hi

> On Jan 22, 2018, at 1:20 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> This was the primary goal of SHTTP.  See RFC 2660.  Of course, SHTTP never saw wide-spread deployment.

I recall it was a specific solution for a specific protocol.  Can't a generic protocol accomplish that as well?  I see ATLAS as a generic solution that does at least some of what CMS (RFC 5652) does, but ATLAS uses TLS key establishment.  My view of ATLAS comes from working on the problem of end-to-end IoT security, e.g. through middle boxes: Both CMS-style encapsulation and application-level TLS have been proposed for IoT messaging.  To me, a compelling reason for re-using TLS/DTLS is key establishment.  A compelling reason for considering CMS-style encapsulation (COSE,OSCOAP) is adaptation to different application protocols, which may have different needs and require different profiles for what gets exposed between endpoints.

So, can ATLAS provide the sort of function SHTTP provided or that Phil asked about?  I don't know.  I still don't know if using ATLAS for IoT encapsulations like CBOR is a win over COSE.  We know there is a need for this:  COSE lacks key management and that's a lot. Chat protocols took a long time to achieve end-to-end confidentiality and integrity through WhatsApp/Signal (following years of refusal by the industry to deploy CMS for that purpose).  There are other applications that need end-to-end security.  What if we could do that with one protocol that includes both key management and  secure enveloping?

Mark

> 
> Russ
> 
> 
>> On Jan 22, 2018, at 2:41 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>> 
>> A problem that keeps coming up in HTTP is the ability to sign requests/responses. Some see this as additional security, but others see this as beneficial for after-the-fact verification (e.g auditing).
>> 
>> If ATLAS proposes to encapsulate HTTP to prevent interference by intermediaries than it likely would also solve problems that HTTP request signing proposals have not been able to overcome — the possibility that intermediaries may alter HTTP requests for good (or bad) reasons. 
>> 
>> Has this been discussed?
>> 
>> Thanks,
>> 
>> Phil
>> 
>> Oracle Corporation, Identity Cloud Services Architect
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
> 
> _______________________________________________
> Atlas mailing list
> Atlas@ietf.org
> https://www.ietf.org/mailman/listinfo/atlas