Re: [stir] Choice of STIR signature algorithm

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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
>
>
> 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
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>