Re: [woes] Proposed charter, post-Quebec edition

[Sean Turner <[e-mail]>]

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 <[e-mail]
>> <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/woes
>