Re: [stir] Choice of STIR signature algorithm

Whenever we say SHOULD i believe this is in the context of the authentication service only, because this would imply a MUST on the verification side, right?

So, should we go there or just stick with MUST on

> On May 16, 2016, at 11:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> On Mon, May 16, 2016 at 5:01 PM, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> Eric:
> 
> I was thinking P-256, but I could be talked into:
> 
> 	MUST support P-256
> 	SHOULD support P-384
> 
> I would tend to just think MUST p-256. Less is more
> 
> -Ekr
>  
> 
> Russ
> 
> 
> On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
> 
>> This seems largely reasonable. I would consider removing the SHOULD for RSA for
>> PASSporT signatures, for two reasons:
>> 
>> 1. There's no legacy to deal with
>> 2. Because these objects are just sent out with no negotiation, it's not that useful
>> to know that relying parties might or might not support your algorithm. The safe
>> thing to do would be ECDSA.
>> 
>> I would also note that the above doesn't specify a curve, but I assume we're talking
>> P-256.
>> 
>> -Ekr
>> 
>> 
>> On Mon, May 9, 2016 at 1:37 PM, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
>> I would rather be a bit more granular.
>> 
>>         MUST support ECDSA for PASSporT signatures
>>         SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures
>> 
>> and
>> 
>>         MUST support ECDSA for certificate signatures
>>         MUST support RSA PKCS#1 v1.5 for certificate signatures
>> 
>> Then, we should say something to product planners that at some point in the future, we expect support for RSA to be downgraded.
>> 
>> Russ
> 
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir