All,

Thought I would give a heads up that I have requested a
DISPATCH/SECDISPATCH slot to discuss the following drafts, both of which
have relevance to JOSE:

https://www.ietf.org/archive/id/draft-hallambaker-jscontact-04.html
https://www.ietf.org/archive/id/draft-hallambaker-earl-00.html

The first draft is making what I believe to be an obvious step for a JSON
contact format, namely to use JOSE JWKs to identify keys.

That has potential impact here since the goal of my proposal is to provide
a secure way to exchange credentials for any application protocol and
currently JWKs only address X.509 credentials as a named type. There is no
way to exchange OpenPGP or SSH credentials. So I would like to discuss
extending JWK to provide a general solution.

The second is work which could potentially come to JOSE. The basic idea
here being we want to securely exchange JSContact data with the option of
authenticated updates later. JOSE signatures are the obvious approach to
authenticating JSON contact data but JWS doesn't really work as the BASE64
thing isn't needed in this context an the 33% bloat is going to make
dealing with PQC contacts even more painful.

So there is an envelope format which is basically CMS/PKCS#7 but using QUIC
varints to specify two or four buckets of data. If the data is signed,
there are four buckets and either the first bucket or the last can contain
a list of JOSE signatures over the content metadata (in JSON) and payload
(can be anything).

This is a very simple but powerful envelope format that does everything
that can be done in PCKS#7/CMS but without ASN.1 and anything that can be
done in XML DIGSIG but without the canonicalization or transform stuff.
Just a bunch of JSON headers organized into three of the four buckets plus
a binary payload.

PHB
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to