The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport
Layer '
<draft-green-secsh-ecc-08.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2009-07-06. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-08.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15220&rfc_flag=0
A couple of comments:
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?
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.
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?
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 9.1: Should the should be SHOULD in the following: These curves
should always be enabled unless specifically disabled by local security
policy.
Does the Certicom IPR applies to this ID (it pretty much applies to all
the other ECC RFCs/IDs)?
spt
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf