From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@xxxxxxxxx>
Subject: draft-ietf-pkix-ecc-subpubkeyinfo-02
To: turners@xxxxxxxx, kelviny@xxxxxxxxxxxxx, dbrown@xxxxxxxxxxxx,
housley@xxxxxxxxxxxx, wpolk@xxxxxxxx
Date: Sat, 2 Feb 2008 01:35:11 +0100 (MEZ)
Hello,
I also have performed a (rather quick) review of the I-D
authored by you, draft-ietf-pkix-ecc-subpubkeyinfo-02 .
Here are the textual issues I found and my suggestions for
additional improvements:
(1) Section 1
The second text paragraph (below the algorithm list) says:
[...]. To promote
interoperability, this document indicates which is required.
This is considered ambiguous:
Do you mean "required to implement", "required to use", or both ?
>From details specified later in the draft, it becomes clear that
perhaps the former choice had been intended.
I suggest to clarify this at first place, stating unambiguously:
[...]. To promote
interoperability, this document indicates which is required
to implement.
A similar addition should be applied at the end of the third
text paragraph of this section.
(2) Section 2
(2a)
1st paragraph: s/subjectPublilcKeyInfo/subjectPublicKeyInfo/
^
(2b)
Spurious replicated "are" in the middle of the section:
The type AlgorithmIdentifier is parameterized to allow legal sets of
values to be specified by constraining the type with an information
object set. There are two parameterized types for AlgorithmIdentifier
vvvv ^^^^^^^^^
| are defined in this document: ECPKAlgorithms (see paragraph 2.1) and
HashFunctions (see paragraph 2.1.1.2.5).
---
The type AlgorithmIdentifier is parameterized to allow legal sets of
values to be specified by constraining the type with an information
object set. There are two parameterized types for AlgorithmIdentifier
| defined in this document: ECPKAlgorithms (see paragraph 2.1) and
HashFunctions (see paragraph 2.1.1.2.5).
(3) Section 2.1
(3a)
In the section title, I suggest using plural:
2.1. Elliptic Curve Public Key Algorithm Identifiers
^
(3b)
In the first paragraph: s/ECPKCAlgorithms/ECPKAlgorithms/
^
(4) Section 2.1.1
(4a)
"ansi-x9-62" twice appears in Section 2.1.1.1 without being formally
introduced in the memo.
I suggest to deal with that issue in Section 2.1.1, where this OID
is used implicitely, by changing:
The algorithm identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
---
The algorithm identifier is:
| id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) 1 }
|
| where ansi-X9-62 is defined as:
|
| ansi-X9-62 OBJECT IDENTIFIER ::= {
| iso(1) member-body(2) us(840) 10045 }
(Please correct an ASN.1 layman's trial if that's incorrect!)
(4b)
In the ECParameters syntax, please correct:
specifiedCuve SpecifiedCurve,
---
| specifiedCurve SpecifiedCurve,
^
(4c)
In the ECParameters fields explanations, I suggest adding two commas
(in an attempt to follow RFC-Editor favored style):
specifiedCurve allows all of the required values to be explicitly
| specified. This choice MAY be supported, and if it is,
^
implicitCurve MUST also be supported. See paragraph 2.1.1.2.
and:
implicitCurve allows the elliptic curve parameters to be
inherited from the issuer's certificate. This choice MAY be
supported, but if subordinate certificates use the same
namedCurve as their superior, then the subordinate certificate
| MUST use the namedCurve option. That is, implicitCurve is only
^
supported if the superior doesn't use the namedCurve option.
(5) Section 2.1.1.1
(5a)
First paragraph: s/ECParamaters/ECParameters/
^ ^
(5b)
For the 'ansi-x9-62' OID issue, see (4a) above!
Alternatively, for secp192r1 and secpr256r1 the fully expanded
version of the object identifier might be specified.
(6) Sections 2.1.1.2 and 2.1.1.2.1
(6a) 2.1.1.2, 1st paragraph
Please correct and improve the readability:
The specified field in ECParameters is the SpecifiedCurve type.
SpecifiedCurve uses the following ASN.1 structure:
--- vvvvv
| The specifiedCurve field in ECParameters is the SpecifiedCurve
| type chosen; it uses the following ASN.1 structure:
^^^^^^^^^^^^
(6b) base point naming
The text in section 2.1.1.2 uses "P" to denote the base point on
the elliptic curve -- once in the syntax, and twice in the field
explanations for SpecifiedCurve.
Contrary to that, Section 2.1.1.2.1 uses "G" for the same purpose
(three times in the long text paragraph below the syntax).
That's confusing, at best.
I suggest to consistently use a single formula symbol / name for
the base point, either "P" or "G" -- it's your choice!.
Also, in the field explanations for SpecifiedCurve in 2.1.1.2,
I suggest changing:
base specifies the base point P of the elliptic curve E, ...
---
| base specifies the base point P on the elliptic curve E, ...
^
(6c)
Throughout the text: s/psuedorandomly/pseudorandomly/g
^^ ^^
(one occurrence in 2.1.1.2, five occurrences in 2.1.1.2.1)
(6d) 2.1.1.2.1, 1st paragraph
The text says:
vvvvvv
The version field in SpecifiedCurve is the SpecifiedCurveVersion
type. [...]
^^^^
I suggest to change this and either say:
vv
| The version field in SpecifiedCurve is of SpecifiedCurveVersion type.
[...]
or:
vvvvvvv
| The version field in SpecifiedCurve is of type SpecifiedCurveVersion.
[...]
or:
vvv
| The version field in SpecifiedCurve has SpecifiedCurveVersion type.
[...]
(Again, it's your choice ...)
Similar changes should be applied in the first line in the subsequent
sections 2.1.1.2.2, 2.1.1.2.3, 2.1.1.2.4, and 2.1.1.2.5.
(For brevity, I omit mentioning that below.)
(7) Section 2.1.1.2.2
The last paragraph should be corrected:
Two FieldTypes defined herein: [...]
--- vvvv
| Two FieldTypes are defined herein: [...]
(8) Section 2.1.1.2.2.2
Near the end of the section: s/pentaomial/pentanomial/
^
(9) Sections 2.1.1.2.3 and 2.1.1.2.4
In the second-to-last paragraph of 2.1.1.2.3, the Note ...
[...]. Note that these
octet strings may represent an elliptic curve point in compressed
or uncompressed form. Implementations that support elliptic
curve according to this document MUST support the uncompressed
form and MAY support the compressed form.
... comes to surprise and is confusing in this context.
It turns out that this Note belongs into the explanation of 'Base'
and hence should be moved to the end of Section 2.1.1.2.4.
(10) Section 2.1.1.2.5
In the second line, please use less literary style:
HashAlgorithm use the following ASN.1 syntax:
---
| HashAlgorithm uses the following ASN.1 syntax:
^
(11) Sections 2.1.2 and 2.2
I suggest to more clearly use "elliptic curve cryptograpy" and its
abbreviation, "ECC", in place of the too terse "elliptic curve" and
its abbreviation "EC" in these paragraphs; perhaps it would even be
better to not use the abbreviation in 2.1.2 -- i.e.:
(11a) Section 2.1.2, first paragraph
Algorithms used with EC fall in to different categories: signature
and key agreement algorithms. ECDSA uses the ecPublicKey described
in 2.1.1. Two sets of key agreement algorithms are identified herein:
Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and
Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. All
algorithms are identified by an OID and have PARMS. The OID varies
based on the algorithm but the PARMS are always ECParameters (see
paragraph 2.1.1).
--- vvvvvvvvvvvvvvvvvvvvvvvvvvv
| Algorithms used with elliptic curve cryptography fall in to different
categories: signature and key agreement algorithms. ECDSA uses the
ecPublicKey described in 2.1.1. Two sets of key agreement algorithms
| are identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key
vvv|^^^
| agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV)
key agreement scheme. All algorithms are identified by an OID and
have PARMS. The OID varies based on the algorithm but the PARMS are
always ECParameters (see paragraph 2.1.1).
(I also have added two missing articles.)
(11b) Section 2.2, first paragraph
The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
Implementations that support elliptic curve according to this
document MUST support the uncompressed form and MAY support the
compressed form of the ECC public key. [...]
---
The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
| Implementations of elliptic curve cryptography according to this
^^ ^^^^^^^^^^^^
document MUST support the uncompressed form and MAY support the
compressed form of the ECC public key. [...]
(I also have simplified the language, avoiding one instance of the
threefold "support".)
(12) References
You might also plan for quoting the upcoming FIPS PUB 180-3 for the
SHS, and use the (version independent) ref. tag '[SHS]' in place of
'[SHA2]'.
----
Note: According to persistent experience, I fear that our MTA will
be unable to deliver one particular copy of this message,
because inappropriate packet filtering of DNS requests
(by *source* port) [in Redmont] prohibits access to the MX
records of, and hence cuts off connectivity to, all related
domains, for all users of a recursive DNS resolver behind a
NAT/NAPT firewall access router (like our site) -- the latter
inevitably has to remap the source port of outbound requests.
Please be prepared for that this message might need
forwarding for all co-authors to receive a copy. Thanks.
Kind regards,
Alfred HÎnes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah@xxxxxxxxx |
+------------------------+--------------------------------------------+