Following the Madrid DISPATCH, I would like to propose the following as Working Group items:
https://www.ietf.org/archive/id/draft-hallambaker-dare-00.html https://www.ietf.org/archive/id/draft-hallambaker-earl-01.html The DISPATCH outcome was to take these here or hold a BOF. Rather than ask for a BOF and then find out this WG doesn't want the work, seemed logical to propose these here. DISPATCH outcomes are not binding on WGs of course. Both technologies are proposed with the intention of initially being applied to support the @nyone profile of JSContact. The goal here being to make it really easy to exchange contacts containing cryptographic credentials in a fashion that maintains the security of the exchange contact and enables automatic authenticated updates. Bottom line here is bumping phones to exchange these credentials provides all the security of those old time PGP key ceremonies. However, they are both designed as primitives capable of being used in many different ways. DARE Envelope is an alternative envelope encoding for JWE/JWS designed to provide PKCS#7/CMS type capabilities. It is optimized for larger data items, avoiding the Base64 expansion that comes from using text to transport binary data but still using JSON serialization of all the cryptographic information. DARE Sequence is an efficient encoding for sequences of envelopes that allows for efficient reads in either the forwards or reverse direction. Both are based on earlier work but with a major overhaul to align the approach with work in MOQ. I have stripped out the parts of the original DARE scheme that deal with authenticated sequences. While such sequences are obviously very useful, there are many different approaches that have various cost/benefit tradeoffs. EARL is a URI form that uses a single multipurpose key to locate, decrypt and authenticate a data object wrapped in a DARE Envelope. A second form of the identifier provides the location and authentication capabilities but without the decryption. These URI forms are used in @nyone to create secure bindings between URIs delivered as QR codes, NFC tag data or DNSSEC secured DNS records to a contact record. But the approach is capable of being used very generally. One application that could be very important is in squeezing PQC credentials into various places that expect far fewer bytes. An EARL URI is a bearer token for the thing it signifies, if you have the EARL and the service is servicing, that is exactly the same as having the thing it points to itself. Comments?
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
