Subject: [Gen-art] Gen-ART review of IETF LC draft-ietf-openpgp-rfc2440bis-19.txt

From: Miguel Garcia <[email-masked]>
Date: Tue, 27 Mar 2007 09:36:43 +0300

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-openpgp-rfc2440bis-19.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2007-03-26
IETF LC End Date: 2007-03-27

Summary: This draft is on the right track but has open issues, described 
in the review.

Comments:

The document is well written and easy to understand, however, I have a
couple of (probably important) open issues that should be further discussed.

1) Section 10.3.3 creates a registry of hash algorithm identifiers. I am
aware of an existing similar registry in IANA. I would draw the author's
attention to this registry:

http://www.iana.org/assignments/hash-function-text-names

which was created about a year ago to explicitly list hash function
textual names. In my opinion, this draft should not create a new
duplicated registry, but use (and perhaps extend, if needed) the
existing one.

Note that in case this comment is accepted, you may need to re-write
other parts in the draft, such section 5.2.2

I would encourage the authors to find out if IANA already has other 
additional existing registries that could be used. For example, I was 
trying to find a registry of compression algorithms (Section 10.3.4), 
but the closest registry I found is:

http://www.iana.org/assignments/comp-meth-ids

Although I am afraid you can't use this last one, which seems to be
specific for TLS. But I would like the authors to comment about this and 
other potential existing registries.

2) I found that the draft lacks a lot of references in the text. So,
unless the reader is VERY familiar with the technology, it is hard to
find references, either normative or informative. Take as an example
Section 1, which mentions RFC 2440, 1991, RSA, MD5, IDEA, GPG, RFC 2434,
etc. without a single reference to them.

Similar applies to Radix-64 in Section 2.4, PKCS#1 in Section 5.2.2; RFC
1950, RFC 1951 and BZip2 in Sections 5.6 and 9.3.

Connected to the above: I would suggest to add one more column to each 
of the tables in Section 9, where you add a reference to each of the 
rows in the table.

Note that this are just examples, there are many places in the draft
where there aren't appropriate references to normative or informative 
specifications.

Nits:

3) Section 10.3.4 creates the compression algorithms registry and refers
to IANA to Section 9 in the draft to populate the registry. I guess you
are referring to Section 9.3 (Section 9 is not precise enough for IANA).

4) Section 3.4 mentions RFC 2279 as a UTF-8 reference. Notice that RFC
2279 has bee obsoleted by RFC 3629.

5) Section 10.2.2.1: The section creates a registry of Signature
Notation Data types and initially populates the registry with the data
found in Section 5.2.3.16. This Section 5.2.3.16 refers to the data as
"flags" rather than "data". I would like to synchronize both terms in
one or the other way.

6) I wonder why the draft refers to "ZIP" when speaking about RFC 1951, 
when RFC 1951 is the "Deflate" algorithm. As far as I know "ZIP" is not 
the name of a compression algorithm: its proper name is "deflate".

7) Please run idnits at http://tools.ietf.org/tools/idnits/idnits.pyht
There are many nits reported, including down references and references
to obsolete documents.

8) Be careful with the examples in Section 6.5. The lines cross the 72 
character limit, so the last column folds over the next line and makes 
the examples unreadable.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Mar 2007 07:51:18 -0400

http://www.iana.org/assignments/hash-function-text-names is an
inappropriate registry for openpgp.  The set of hashes there is not
the same as the set of openpgp hashes.

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 27 Mar 2007 14:58:27 +0300

Hi Sam:

Can you elaborate a bit the reason you think these are different hashes?

For example: the OpenPGP draft uses an MD5 hash. The OID value defined 
in Section 5.2.2 matches the OID of the MD5 hash defined in the 
mentioned IANA registry. The same is applicable to SHA-1, SHA224, 
SHA256, SHA384, and SHA512.

To me the look like they are the same objects that represent the same 
"thing".

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 27 Mar 2007 17:11:51 +0300

What a pity... that registry was precisely created to avoid what we are 
getting into: duplication of registries because of the upper and lower 
cases, hyphen, etc.

/Miguel

David Shaw wrote:
> One problem is that the names do not match exactly.  For example,
> OpenPGP uses the text name "SHA512", but that registry uses "sha-512",
> which lowercase and with a hyphen.  This is significant as one of the
> OpenPGP message formats uses the hash name string to match on.  Using
> that registry would involve a lot of confusing explanation in the
> OpenPGP draft to tell people to uppercase the names and remove
> hyphens.
> 
> David
> 
> On Tue, Mar 27, 2007 at 02:58:27PM +0300, Miguel Garcia wrote:
>> Hi Sam:
>>

---

From: David Shaw <[email-masked]>
Date: Tue, 27 Mar 2007 09:46:56 -0400

David

---

From: "Derek Atkins <[email-masked]>" <[email-masked]>
Date: Tue, 27 Mar 2007 10:43:44 -0400

That registry was created 11 months ago.  This document has been around
for 6+ years, and the protocol even longer.   Moreover, that registry
specifically states that it's for PKIX, and modifying that registry
requires a document to update the PKIX document, which probably requires
action from the PKIX working group.  Now, the latter issue might not
be as big a deal, but the former certainly is.

Not only the names of the hashes, but the contents of the list, are different.
So it would just be easier to have an OpenPGP hash registry for the list
of hashes that OpenPGP understand, and if the content of that list
mirror what PKIX understand, well, so be it.  But I doubt the PKIX people
necessarily want to add RIPEMD or some other "weird" hashes to their
lists -- that could cause a LOT of confusion.

now, perhaps that registry is misnamed and should be "pkix hash function
textual names"?  but that's a different disucssion.

-derek

Quoting Miguel Garcia <[email-masked]>:

> What a pity... that registry was precisely created to avoid what we 
> are getting into: duplication of registries because of the upper and 
> lower cases, hyphen, etc.
>
> /Miguel
>
> David Shaw wrote:
>>> For example: the OpenPGP draft uses an MD5 hash. The OID value 
>>> defined in Section 5.2.2 matches the OID of the MD5 hash defined in 
>>> the mentioned IANA registry. The same is applicable to SHA-1, 
>>> SHA224, SHA256, SHA384, and SHA512.
>>>
>>> To me the look like they are the same objects that represent the 
>>> same "thing".
>>>
>>> /Miguel
>>>
>>> Sam Hartman wrote:

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Mar 2007 11:50:57 -0400

>>>>> "Miguel" == Miguel Garcia <[email-masked]> writes:

    Miguel> What a pity... that registry was precisely created to
    Miguel> avoid what we are getting into: duplication of registries
    Miguel> because of the upper and lower cases, hyphen, etc.

Can I point out that PGPG has been using these values for years before
that registry was created.

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 28 Mar 2007 09:08:06 +0300

Right, I understand the history and motivation. Therefore, I withdraw my 
first comment.

/Miguel