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

[Alex Bligh <[e-mail]>]

--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.