So I'll bite on this ;)
I think we can write the spec to require a particular algorithm choice,
but it might make more sense to define the options and then allow the
environment in which the solution will be used to specify it's
requirements. But, I believe that is a discussion we'll have while
writing the spec.
spt
On 8/4/11 9:29 AM, John Bradley wrote:
HMAC is requirement for adoption in the JWS use cases.
If we want to describe it as something other than a "Qualified Digital
Signature", that is fine as long as it is MTI:)
John B.
On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email protected]
<mailto:[email protected]>> wrote:
On 8/2/11 7:13 PM, Paul Hoffman wrote:
Here is a proposal for the charter based on the discussion in
the BoF last week and later discussion with Sean Turner.
Comments, praise, scorn, etc., are welcome.
--Paul and Richard
Javascript Object Signing and Encrypting (jose)
==============================__=================
Background
----------
Javascript Object Notation (JSON) is a text format for the
serialization of structured data described in RFC 4627. The
JSON format is often used for serializing and transmitting
structured data over a network connection. With the increased
usage of JSON in protocols in the IETF and elsewhere, there is
now a desire to offer security services such as encryption and
digital signatures for data that is being carried in JSON format.
Different proposals for providing such security services have
already been defined and implemented. This Working Group's
task is to standardize two security services, encrypting and
digitally signing, in order to increase interoperability of
security features between protocols that use JSON. The Working
Group will base its work on well-known message security
primitives (e.g., CMS), and will solicit input from the rest
of the IETF Security Area to be sure that the security
functionality in the JSON format is correct.
This group is chartered to work on four documents:
1) A Standards Track document specifying how to apply a
JSON-structured digital signature to data, including (but not
limited to) JSON data structures. "Digital signature" is
defined as a hash operation followed by a signature operation
using asymmetric keys.
I just want to make sure that we agree now that a digital
signature is a hash followed by a signature algorithm (e.g., RSA
with SHA-256). I've seen a couple of drafts that tried to say an
HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a
symmetric key based digital signature algorithm (note this phrase
didn't get through the IESG).
An HMAC is not a digital signature, but the spec definitely needs to
be able to cover MAC based authentication.
I know that public key is getting easier as far as computation goes.
But for many applications the non-repudiation you get in digital
signatures is actually undesirable.
There are interesting tricks you can do with symmetric crypto that are
much harder to do in public key and end up with some scheme that only
50 academics in the world can follow and has a security proof that
rest on rather esoteric assumptions.
--
Website: http://hallambaker.com/
_______________________________________________
woes mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/woes
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
