Re: Last Call: draft-green-secsh-ecc (Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2009-Jun-9, at 11:25 AM, Sean Turner wrote:

Other ECC documents in the IETF (TLS, SMIME, PKIX) indicate that support for compressed keys are MAY while this draft says MUST NOT for ECDSA and ECDH keys and MAY for ECMQV. What was the rationale for this?

Simplicity. In my opinion, compressed keys provide little benefit in practice. Certainly for ECDH there's no reason to use them. I would be willing to consider it as a MAY for ECDSA so that signing public keys can be reused between standards.

Sec 3.1.1: Should the must be MUST in the following: The message hashing algorithm must be from the SHA2 family of hash functions [FIPS-180-3] and is chosen according to the curve size as specified in Section 6.2.1.

Yes, thanks.

Sec 3.1.2: In TLS/SMIME/PKIX, the signature value (r&s) are integers but they are encoded together with the following syntax:
Ecdsa-Sig-Value ::= SEQUENCE {
 r       INTEGER,
 s       INTEGER
}
Any chance of reuse?

No. The signature above is encoded using DER encoding of an ASN.1 sequence. There is almost no use of ASN.1 in the secure shell standards, so many SSH implementations may not have code to support DER encoding and decoding. I prefer to stay with the basic syntax that the secure shell standard provides. For those that do desire conversion between the two, it is easy to implement given a DER library.

Sec 9.1: The TLS, SMIME, and PKIX use the secp* naming for the curves instead of nist*. Any chance we could use the secp* names?

In TLS the curves are actually identified by integers in an enum, with the secp names as convenient human readable identifiers. In PKIX the curves are actually identified by OIDs; there the main reason for using the secp names for human readable identifiers is that NIST never specified OIDs, so the SEC OIDs are the only (or at least, most prominent) OIDs for those curves.

In the case of secure shell, since it's semantically equivalent and really just an issue of presentation, I am choosing to stick with nist* naming. I believe that the table that lists the equivalence between nist* and secp* curves should alleviate any confusion.

In 9.1: Should the should be SHOULD in the following: These curves should always be enabled unless specifically disabled by local security policy.

Yes, thanks.

Does the Certicom IPR applies to this ID (it pretty much applies to all the other ECC RFCs/IDs)?

According to
	https://datatracker.ietf.org/ipr/1154/
draft-green-secsh-ecc is included in the list of documents to which the IPR disclosure applies.

Douglas
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]