On 23/01/15 13:46, Vladimir Dzhuvinov wrote:
> What would be a good way to pass the salt? Within the "jkt" parameter
> using some kind of a delimiter, or using a separate parameter?
Either can work fine and tossing a coin is probably
as good a way to decide as any:-)
> We've got a use case where we need to identify shared JWKs (oct). These
> start at 128 bits. What length is generally considered low-entropy to
> require a salt to be added?
If you have a really good randomly generated 128 bits then
you don't need a salt for sure. But I don't think the key
length is really what determines whether or not a salt will
be needed in practice given that many secret keys are
actually created by doing hash(password) anyway;-) So I'd
say if my code allowed for reading a secret key from a file
or other kinds of human input, then I'd want a salt I think,
just in case. If the secret in question was always generated
as a result of a D-H exchange or something then it'd be ok
to not have a salt.
S.
>
> Vladimir
>
> On 23.01.2015 14:38, Stephen Farrell wrote:
>>
>> I just had a quick look and it seems fine for
>> asymmetric keys assuming there's a need for it
>> and a justification for including things like
>> '{"e":' in the hash input, which I don't see.
>>
>> The reason I looked at this is that there's some
>> overlap here with RFC6920, (I'm an author of
>> that) and DANE and maybe other specs that say
>> how to hash a public key.
>>
>> It does seem a shame to have so many ways to
>> hash public keys, but 6920 is compatible with
>> DANE and others that hash a SPKI (even if
>> that's artificially created just as a hash
>> input), so I wonder if the benefit of the
>> running code here is really worth being
>> different from other specs that hash a SPKI.
>>
>> So, other than that someone has some code,
>> what is the benefit of being incompatible with
>> other specs here?
>>
>> The downside is that I could not determine
>> that one of these does/doesn't map to the
>> same public key as some DANE RRs for example.
>> Seems a bit odd to me to want to accept that
>> downside unless there's an upside.
>>
>> Only other thing is for symmetric keys I think
>> you should add an optional salt, in case you
>> need the thumbprint of a low-entropy secret,
>> which is quite likely to happen, and quite
>> likely to get exposed somehow. And I'd argue
>> to recommend that a long salt always be used
>> for potentially low-entropy secret keys.
>>
>> Apologies if the WG discussed these before
>> but I missed it;-)
>>
>> S.
>>
>> PS: These are just random-punter comments with
>> no hats.
>>
>> On 23/01/15 01:56, Jim Schaad wrote:
>>> This starts a two week last call on draft-ietf-jose-jwk-thumbprint. Last
>>> call will end on February 2, 2015.
>>>
>>>
>>>
>>> Due to the general lack of activity on the list. General silence will be
>>> considered as a vote to park the document and either have it done via the
>>> ISE or with an AD shepherd rather than having group consensus.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>> _______________________________________________
>> jose mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
