Another take on this, which may make some people feel very uncomfortable,
is to propose key migration in RSA via a downgrade keylength:
sign with a shorter RSA key, and re-sign with a long one once the original
long one is widely deprecated under 5011.
1024-> new512 (!) -> new1024
this avoids ha
On Mon, 19 Jan 2015, Paul Hoffman wrote:
If we want small, short tractable signatures in DNS, moving to eCDSA is easier
now than at any other time. We just have to accept we make a lot of DNSSEC
clients stop validating until code updates.
A big +1 to this.
A big -1 to this. You suggest ba
On Monday, January 19, 2015, George Michaelson wrote:
> I think its possible people have misunderstood what we said, when we
> measured 'do not understand ECDSA' as a problem and presented on it.
>
Dunno. I think many / most folk got it, at least in the venues I saw it..
>
>
>
> It is a tena
On Jan 19, 2015, at 7:30 AM, George Michaelson wrote:
> I think its possible people have misunderstood what we said, when we measured
> 'do not understand ECDSA' as a problem and presented on it.
>
> It is a tenable, arguable case, that PRECISELY because the fail mode is
> 'unsigned' we can mov
Next release of Net::DNS::SEC will support ECDSA and ECC-GOST
Dick Franks
On 19 January 2015 at 15:17, Warren Kumari wrote:
>
>
> On Monday, January 19, 2015, Francis Dupont
> wrote:
>
>> In your previous mail you wrote:
>>
>> > Currently a number of validators do
Next release of Net::DNS::SEC will support ECDSA and ECC-GOST
Dick Franks
On 19 January 2015 at 15:17, Warren Kumari wrote:
>
>
> On Monday, January 19, 2015, Francis Dupont
> wrote:
>
>> In your previous mail you wrote:
>>
>> > Currently a number of validators do
I think its possible people have misunderstood what we said, when we
measured 'do not understand ECDSA' as a problem and presented on it.
It is a tenable, arguable case, that PRECISELY because the fail mode is
'unsigned' we can move to ECDSA more easily than any other key transition
under discuss
On Monday, January 19, 2015, Francis Dupont
wrote:
> In your previous mail you wrote:
>
> > Currently a number of validators don't do ECC, because of the openssl
> > library from the distribution they are using doesn't include support.
> > This makes ECC an unsupported algorithm, and so it "f
In your previous mail you wrote:
> Currently a number of validators don't do ECC, because of the openssl
> library from the distribution they are using doesn't include support.
> This makes ECC an unsupported algorithm, and so it "fails open" (See
> RFC4035, Section 5.2, around "If the valida
On Fri, Jan 16, 2015 at 10:59 AM, Olafur Gudmundsson wrote:
>
>> On Jan 16, 2015, at 5:13 AM, Marco Davids (SIDN)
>> wrote:
>>
>> Hi,
>>
>> SHA-1 for TLS-certificates is considered insufficient nowadays.
>>
>> But what about the usage of RSA/SHA-1 in DNSSEC ?
>>
>> Should TLD's such as .se make
> On Jan 16, 2015, at 5:13 AM, Marco Davids (SIDN) wrote:
>
> Hi,
>
> SHA-1 for TLS-certificates is considered insufficient nowadays.
>
> But what about the usage of RSA/SHA-1 in DNSSEC ?
>
> Should TLD's such as .se make preparations for an algorithm roll-over?
>
> --
> Marco
>
> _
Yes, in my opinion it is a good idea to have a plan to migrate to a new
algorithm and RSA/SHA-256 is probably the candidate as ECDSA is not widely
implemented as far as we can tell (but not sure). NIST is advocating migration
(or initial deployment) of RSA/SHA-256 within the .gov TLD. The .gov
Hi,
SHA-1 for TLS-certificates is considered insufficient nowadays.
But what about the usage of RSA/SHA-1 in DNSSEC ?
Should TLD's such as .se make preparations for an algorithm roll-over?
--
Marco
smime.p7s
Description: S/MIME-cryptografische ondertekening
__
13 matches
Mail list logo
