Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

[Phillip Hallam-Baker <[e-mail]>]

That works for me


On Thu, Mar 3, 2011 at 2:36 PM, Warren Kumari <[e-mail]> wrote:

> Hi all,
>
> After watching the thread, I'd like to propose this as a strawman:
>
> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these
> are all we specify.
>
> My reasoning behind this is:
> 1: We don't want to support too many algorithms -- it leads to complexity
> (which leads to weaker security) and opens the door to interoperability
> issues and fights over why algorithm X was allowed and Y was not.
>
> 2: Having more than 1 algorithm forces implementations to understand that
> there is not just one, and so should help lead towards algorithm agility
>
> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do
> DNSSEC you should already support the above.
>
> 4: (IMO, an important one, even if not technical one) giving people the
> ability to choose will lead to greater deployment. Some folk will claim that
> SHA-256 is too short. Some will claim that SHA-384 is excessively long and
> computationally expensive. Some will claim something completely random.
> Almost none of them will have any (rational) basis for their claims, but
> allowing them to use the algorithm they believe is superior will make them
> more likely to deploy.
>
> 5: 2 algorithms seems like enough. While SHA1 may or may not be suitable
> (my (and to be completely blunt, your) views don't really matter) -- there
> are enough strong views on the strength / lifetime that we are likely to get
> bogged down / splinter over this. If we were already deployed with SHA1 this
> would be an important decision, but seeing as we're not, I think that
> avoiding fight (and living to see another day) is best.
> Once again, I'm not saying that I think that SHA1 is (or isn't) fine for
> this, rather that, in order to get deployed, we should avoid the issue.
>
> #4 and #5 might be pandering, but if it doesn't decrease security, and
> leads to sooner / more deployment it seems like a win....
>
> Does anyone object to this (for any reasons other than "You're running away
> from the fight, you coward!")?
> Please speak soon, as we'd love to close this out....
>
> <chair hat>
> Please don't let this dissolve into a "algorithm X is better than Y, and Z
> is a pile o' rubble" discussion -- while that may be true, this is not the
> time or place to have it....
> </chair hat>
>
> W
>
>
> On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote:
>
> > Hi all,
> >
> > While we are all ruminating on the other issues, I figured we might as
> well try address this one:
> >
> > Need to specify which crypto algorithms and certificate types are
> mandatory to implement --
> http://trac.tools.ietf.org/wg/dane/trac/ticket/21
> >
> > Description:
> > Currently, the draft is silent on which crypto algorithms and certificate
> types must be implemented for interoperability. It should be specific before
> the document is finished.
> >
> >
> > W
> > _______________________________________________
> > keyassure mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/keyassure
> >
>
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure
>



-- 
Website: http://hallambaker.com/