I find the idea of starting from scratch frustrating. MAC solves a set of
specific problems and has a well defined use case. It's symmetric key based
which doesn't work for some folks, and the question is do we try to develop
something that supports both PK and SK, or finish the SK use case and then work
on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY
CLOSE* to being done.
-bill
On 08/08/2012 05:21 PM, John Bradley wrote:
> We did discuss per message signing in Vancouver.
>
> The idea is to get agreement on the threats we are trying to mitigate, then
> decide on the mechanisms.
>
> Per message signing will likely still be one of the mechanisms.
>
> The chair will need to decide if we start fresh and copy the parts of MAC
> that are needed or try and continue the existing MAC draft.
>
> John B.
>
> On 2012-08-08, at 4:59 PM, Justin Richer wrote:
>
>> I believe that there's value in per-message signing completely apart from
>> the channel level encryption. MAC tokens let us do this with a per-token
>> secret using a pattern very well established in OAuth1. I'm sorry that I
>> wasn't at the Vancouver meeting to voice this opinion, for what it's worth.
>>
>> -- Justin
>>
>> On 08/08/2012 12:24 PM, Hannes Tschofenig wrote:
>>> Hi Justas,
>>>
>>> thanks for sending your feedback to the list.
>>>
>>> There is indeed currently no editor for the document. That is, however, not
>>> the problem.
>>> The problem, as discussed on the list and also at the last IETF meeting, is
>>> that we do not yet know what type of security properties we want. The MAC
>>> draft may or may not provide the type of protection we want.
>>>
>>> For that reason we first have to figure out what problem we want to solve
>>> before we jump into the details of fixing some minor errors.
>>>
>>> Ciao
>>> Hannes
>>>
>>> On Aug 8, 2012, at 6:08 PM, Justin Richer wrote:
>>>
>>>> Thanks Justas. The MAC document is currently without an editor within the
>>>> WG, so this is the best place to record the error.
>>>>
>>>> A wider note to the WG: I wouldn't mind taking over editorship of the MAC
>>>> token document so long as I could get a co-editor with enough
>>>> cryptographic expertise to make sure all the magical crypto bits work like
>>>> they should. I've sent an email to the chairs saying as much, as well.
>>>>
>>>> -- Justin
>>>>
>>>> On 08/05/2012 06:30 AM, Justas Janauskas wrote:
>>>>> Hello,
>>>>>
>>>>> Sorry if this is not the right group to send this message; I am new here.
>>>>>
>>>>> I believe there is mistake in calculated request MAC presented in
>>>>> "draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
>>>>>
>>>>> I made a small program to test correctness of an example and it shows
>>>>> that it is incorrectly calculated in the document:
>>>>> https://gist.github.com/3263677
>>>>>
>>>>> I have also implemented an example from previous draft 00, section 1.2
>>>>> which shows that request MAC is calculated correctly there:
>>>>> https://gist.github.com/3263765
>>>>>
>>>>> Thank you,
>>>>> Justas Janauskas
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
