Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

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

There are two issues here:

1) Different OIDs assigned to the same algorithm with the same parameters.

2) Algorithms that take parameters that lead to different OID assignments.


In the first case we did at one point have an ambiguity where an IETF
WG got the idea that it should ignore the existing OID assignments and
assign OIDs in the IETF arc.

It is now understood that that was a mistake and should not be repeated.

If we moved to the scheme I propose it would make sense for the IETF
to maintain a registry of mandated algorithms and the ASN.1 OIDs
mandated for use in those protocols that use them. But part of the
point of getting the IETF out of the business of registering code
points for non-mandatory crypto would be to discourage use.


In the second case we have frequently ended up with different OIDs for
incompatible variations of the same algorithm. But this is exactly
what we want.

For example, we have had at least three different packaging formats
for RSA signatures over the years. The packaging formats are
incompatible and a verifier can only verify a signature if it supports
the precise packaging format used to create the signature. So even
though the public key algorithm is the same, the implementation is
different and we need to use a different identifier if we are going to
have interoperability.


ECC is a little bit of a unique case since there are parameters and
options and much more complexity than we have had to cope with in the
past.

But even so, I don't see a lot of value in having different protocols
choose different sets of options. At the end of the day consistency is
going to be far more useful than any benefit we might gain from those
options.



On Fri, Jan 7, 2011 at 10:26 AM, Alex Bligh <[e-mail]> wrote:
>
>
> --On 7 January 2011 09:32:56 -0500 Phillip Hallam-Baker <[e-mail]>
> wrote:
>
>> All non-mandatory crypto would use ASN.1 OIDs to declare the algorithm
>> type. In the case of DNSSEC this would require an approach similar to
>> the one that the OID based CERT type uses. There would be a code point
>> reserved for identifying the algorithm by ASN.1 oid and a defined
>> mechanism for squeezing in the OID as a prefix to the crypto material.
>
> ...
>>
>> The only interoperability concern should be that applications that
>> support a common algorithm be able to use it to communicate. That
>> means that they all use the same code points to identify the same
>> algorithm.
>
> ...
>>
>> The fact that the OID registry is open and has no gating factor is a
>> good thing. No gate means no endorsement. If we had used ASN.1 OIDs to
>> identify algorithms there would be no RFC 5933, there would be no
>> mention of GOST in RFCs at all unless there was a decision to adopt it
>> as a mandatory to implement algorithm (which the GRU would not want in
>> any case since their whole purpose requires use of a different
>> algorithm).
>
>
> Q: is there sufficient standardisation within the ASN.1 OIDs that if a new
> crypto type FOO comes along, then 2 implementations, working solely from
> the OID, they can necessarily interoperate? IE will they thoroughly specify
> whether FOO options X and Y have to be supported, wire format, etc? To
> illustrate what I mean, I include below a section from the OpenSSH-5.7
> testing release notes. I know ssh != DNSSEC, but I suspect support for a
> new algorithm might not be as simply described as whether a single ID.
>
> --
> Alex Bligh
>
>
>
>
> * Implement Elliptic Curve Cryptography modes for key exchange (ECDH)
>  and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA
>  offer better performance than plain DH and DSA at the same equivalent
>  symmetric key length, as well as much shorter keys.
>
>  Only the mandatory sections of RFC5656 are implemented, specifically
>  the three REQUIRED curves nistp256, nistp384 and nistp521 and only
>  ECDH and ECDSA. Point compression (optional in RFC5656) is NOT
>  implemented.
>
>  Certificate host and user keys using the new ECDSA key types are
>  supported - an ECDSA key may be certified, and an ECDSA key may act
>  as a CA to sign certificates.
>
>  ECDH in a 256 bit curve field is the preferred key agreement
>  algorithm when both the client and server support it. ECDSA host
>  keys are preferred when learning a host's keys for the first time.
>
>



-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext