Subject: 3 remarks

From: Werner Koch <[email-masked]>
Date: Thu, 13 Jan 2000 10:38:12 +0100

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 <[email-masked]>:

 * 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 <[email-masked]>:

 * 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

---

From: Ulf Möller <[email-masked]>
Date: Thu, 13 Jan 2000 15:14:56 +0100

>  [IMHO, this is not the goal of the RFC] 

I doubt that it was a wise decision to declare the PGP canonical
non-cleartext signature format incorrect (by the way, how does PGP 6
handle them?), but even ignoring that there are problems.

As the draft is written, all OpenPGP implementations must be prepared
to recieve "binary" signatures on a "text" literal data packet (or
even a "cleartext" signature, which of course works only if there was
no trailing whitespace in the document to be signed); or a "canonical
text" signature on a "binary" literal data packet; and so on. I don't
think you'd find many implementations that handle all that correctly.

---

From: [email-masked] (Bodo Moeller)
Date: Sat, 15 Jan 2000 03:08:14 +0100 (CET)

>  [IMHO, this is not the goal of the RFC]

If the RFC does not demand or recommend that implementations accept
such non-standard signatures created by PGP, then that paragraph
should not be in the main text (it can be put in an appendix).
(Also the wording is bad, trailing whitespace is ignored but not
removed when PGP computes cleartext signatures.)