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