Hello,
this WG has been somewhat quite for a long time, even after the last
draft has been published. I have seen only a very few comments on
this draft and IIRC the main concern was related to a standard naming
scheme for notation data.
1) Open points related to the latest draft:
Thu, 23 Dec 1999 20:40:01 +0100, Ulf Möller <ulf(_at_)fitug(_dot_)de>:
* PKCS-1 block type 02 [RFC2437] (Was: [RFC2313]) to form the "m"
value used in the formulas above.
You need to observe the changes in terminology if you refer to the new
PKCS #1.
* The signature packet format is still specified as including "zero or
more subpackets", but the subpacket hints section mentions in passing
that two packets are mandatory.
* The notes about backward compatibility don't mention that PGP 2
requires certain formats for some packet types.
[ I'd suggest to change the wording in section 14 (Implementation Nits)
by inserting a "some": "... Thus, this list of some potential problems
and gotchas ..." ]
* I don't think the note
* (Added:) PGP 2.6.X and 5.0 do not trim trailing whitespace from a
"canonical text" signature. They only remove it from cleartext
signatures.
is particularly clear on how to interoperate.
[IMHO, this is not the goal of the RFC]
* The security notes should mention that only v3 RSA signatures are bound to
the hash algorithm, so that v4/DSA signatures can be forged if any one of
the hash algorithms is broken, even if the signer doesn't use that
algorithm.
Sat, 25 Dec 1999 22:20:32 +0100, Thomas Roessler <roessler(_at_)guug(_dot_)de>:
* The new draft still does not have any details on notation data
naming, making these data essentially useless.
I propose to add the following text in the end of section 5.2.3.16
of the draft: [...]
[Lacking a better suggestion we should either do this or require that
all names to be prefixed with either a "x-" or "X-" until a
supplemenatary document describes the usage of these names]
2) A stupid question:
Recently I browsed rfc2026 (The Internet Standards Process) to see
what is needed for a move to draft standard status.
| 4.1.2 Draft Standard
|
| A specification from which at least two independent and interoperable
| implementations from different code bases have been developed, and
[...]
| The requirement for at least two independent and interoperable
| implementations applies to all of the options and features of the
| specification. In cases in which one or more options or features
| have not been demonstrated in at least two interoperable
| implementations, the specification may advance to the Draft Standard
| level only if those options or features are removed.
It is not clear to me what "options and features" do mean in this
context. Does this include the OPTIONAL parts of rfc2440 and what
about some of the SHOULDs like the requirements of IDEA (there are
good reasons not to implement it for patent reasons)? Do we really
need to have 2 implementations which implement all OPTIONAL parts?
I don't believe this but I am asking just for clarity.
I remember that we once talked about a check list to compare the
interoperability and required features (John's answer from Nov 11th).
Has there been any progress or should I start to compile a new list
based on Tony's work (and where can I get his list)?
3) Action required by implementors
Tom, does your implemenation already have the ability to create
the "reason for revocation"?
Should we implement the new requirements of the draft now?
Werner
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013
Boycott Amazon! - http://www.gnu.org/philosophy/amazon.html