Re: [stir] Choice of STIR signature algorithm

[Russ Housley <[e-mail]>]

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


On May 6, 2016, at 10:18 AM, Eric Burger <[e-mail]> wrote:

> FINALLY, a cogent *engineering* reason for needing RSA.
> 
> How about:
> 	MUST support ECDSA
> 	SHOULD support RSA unless you know you will not need it
> 
> Rationale:
> ECDSA is ubiquitous today. ECDSA has lots of deployment advantages. Pretty much everything else s*cks in comparison.
> 
> However, especially for delegated certificates, there is a chance that one of the intermediate certificates will not be signed with ECDSA but with RSA. As such, if you know you will be deployed in such an environment, RSA is OK.
> 
> I would also suggest putting in a toxic waste warning in the document that the support of RSA is *not* a built-in downgrade attack. This is something that is covered by policy, not necessarily engineering. As such, a note to the implementor suggesting that if they know they should only see ECDSA (or better) signatures, they can feel free to reject an INVITE signed with RSA, even if it looks legitimate.
> 
>> On Apr 12, 2016, at 4:57 PM, Russ Housley <[e-mail]> wrote:
>> 
>> 
>>> I don’t know why so much of the discussion during the Tuesday meeting was
>>> about root certificates. As Eric pointed out on the mail, it is not hard
>>> to get a ECDSA certificate as Digicert, Entrust, Globalising, Symantec,
>>> Certicom, Comodo, and soon Let’s encrypt will happily give you one. As
>>> Russ pointed out most (or all) of these ECDSA certificates will be signed
>>> by a RSA root certificate. But root certificates and verification of the
>>> credentials seems to be out of scope of STIR and does not affect the
>>> PASSporT object. As far as I understand, the only thing STIR should
>>> specify is verification of the PASSporT object.
>> 
>> We will need to say that the validation will include RFC 5280 path validation to a trust anchor.  This means that the signature on each certificate will be validated.  So, for quite some time we will need to be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT object or on a certificate, even if we state a strong preference for ECDSA.
>> 
>> Russ
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir