Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA16134 for ietf-open-pgp-bks; Wed, 31 Dec 1997 22:08:14 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA16130 for ; Wed, 31 Dec 1997 22:08:10 -0800 (PST) Received: from users.invweb.net (cppp20.dotstar.net [208.143.93.120]) by users.invweb.net (8.8.7/8.8.7) with SMTP id BAA18412; Thu, 1 Jan 1998 01:17:38 -0500 Message-Id: <199801010617.BAA18412@users.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jan 98 00:10:27 -0600 To: ietf-open-pgp@imc.org, pgp-dev@pgpi.com In-Reply-To: <199801010308.WAA16256@users.invweb.net> Subject: Re: Key Extraction odd behavior ??? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi, Well somthing screwy is going on. I have now after doing several extracts of the same key from pubring.pkr have two different keys?!? I have the one of filesize 1504 that was attached to the previous message and one of 1800 that seems to have the sig block properly formatted. This is using the PGP 5.0i code (b8a). odd very odd. In playing with other DH keys I have found that sometimes 5.0 extracts the key properly and other times it does not. Is this a known bug in 5.0 or is this somthing new?? Any help would be appreciated as this is making it diffacult to analize my code. I have attached the second key which seems to have been properly extracted so the two can be compaired. Thanks, - - -- - - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - - --------------------------------------------------------------- begin 666 whgiii.pgp MF0&B!#2CWXL1!`#Q)V$-ECV%]4.O=MSUHNII0;=M.9MF@TPR@0):\=&#]/CN MW=[#T%S,VEMM1,SU%<]X?[*'64>5_,RVOQ@,G#MQ3V;0*30$9CO(])2B<+!J MK4PYCD,4AWS*)CYJGW>FWG&(S26<8<, MO2;460"@_S$9+IXWD7/:]?$2^LLME4T0NOT$`(/#RUF0)B3I(2CH/)1%PJ*4 M"(_5QC=)<1Z/+O2U0XE5^@/]L!:46XEK3,DR0^!7QKTS6Z@4"&#CV9<=+!/4%!S`!XP> M:A^'=74IR=/=/ZU+6W0_1IN3%`'K!`"F$Y(?`,;@8UD)_^-ASSP5EYSZ*MW& MM!S=V6Y5D)$$=XJ"8[FJ%3;KH47T%E(A$&G!CEB_%Q2G+D,&T4-9W`LX(X$. M94+^(5A.IO=^B2!`NS^X=.[-TV]'S:`)\&(JLC?_(@=CLK8Y'X-?\NI$`N&G M:)W?-^11'X+=1V+XL@"U[[0I5VEL;&EA;2!(+B!'96EG97(@24E)(#QW:&=I M:6E`:6YV=V5B+FYE=#Z)`$L$$!$"``L%`C2CWXL$"P,!`@`*"1"Y(M'5P:+3 M=(14`)]]ACNL.43+IB!GFT!TH^11D'>,;P"?<>73CHXP'*%*:%JD";K M&55H64V1:8]E%T"O`G$D[D7#,W)0N/Q61)1K'OA!.=5.:`9\Y9>.ONA71@=) M\C7(%&3P*G#0IITYO27"H_@NLY#_C1I2V,$I3UWP"%DB`M17E*9FIGP=TT__C MH<66($Z89;C8#>X07:NV%QQ1V%#*(E=#*;Z5Z%8K.'A<"]OX3$W5XZI&S/O. M%^@JG11AXX2I3]&#A*AYMN^/IT-&",;,'7=7)#A*XL3PZ(X39Y=.DA-A]MOK M)0X7_?:8]\A\>;!R'3AU^_;!<\2#$28K0V##X^C6"OVA*"8+KJFNLV4/H@!3 M`:!\UJNC$A[Z#RK.'W2$3\KS%_.D0.G7TG>V0BT"-L$FRVA>G7R8"0J-?BWM MY%UY]=223YL8COPJITM\,O9"5[<(?P@7%7DEG-_;BN=$_%_':\@\5',&'.?,EF_Q7YN_V17LL] MUA<``@(0`(-1,QX(#P)P-3+SGECG?S$IN3KO4R26+]FNA'U34O;B*Q/VF79R MBQ.L4IQS&%>/7!&AF<.2=)K52?S#OB$P_UY*? M?(Y$XS\%KZ5>9C,EG>,E+[I++IBA033US,C_6H"1C#'M&'?CO]89E?F%<:%O MJ[`8&.V6$DFFLB7_V3^0WA.TP5L?`W8`/"9\=9:V(Z?A](QGHT[]=]ZCJ20/ MHJ?#H9G5!&25C2X)#NG:K;FSG,2Y6J#B>C[%%S!N:J2BYLO859J\YY6"V@!" M[9SY`=/!:"F^<6B1)#//:-4"+W%M37;%33]<$K+U'M:QJ\!KA.-',X]3`\.% MIXA-0XUF9?7.;10TG8:ON`@SX>V)"$+CU;6Z>TV[]1TU&Z@!F^@O,@F9A"Z[X%;9H`JL/(N)YP^5(H9-$,)9Q&KKHT/@9]*\BWF MY;&CY%+00J=;1-.7(Q?LO.A)JX+_O3:TSXN;JME">M-&\>VDN^YYZ2/8_%.E M#:QP,SNH_-AA)5BNYEOJ%9+9GA*$:_\\G00;#^1G@C%`NA><9')Y>?H71VE; M9>"!THL,+P8I;%3I(\'NSYW"Y`05`IN8[5#=Q)28O>-!7TW]YATSY#O>U^RL M%V"M\8>O^`TA:"4MCS10[!R#5A4/Q9S#B0`_`P48-*/?CKDBT=7!HM-T$0+$ M:0"@T];C!KDRH,>(3=L1H84@J;H$O6<`H(O<5L30>@RDWBSI:\2SOBU##5AT ` end -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKszfY9Co1n+aLhhAQGi6QP/ZpdafcqGvIaPQloVFX48UfbmmfEAQNFq 1NsF3x3YmyRl8gEBGcf8BpwPTkR9tyKJe2lFu3Wo6vgZLHnR72h8y3T/RUCulUf4 cwK5P4nLs3318cpbLj4PvgtdGDMb7kVZNDHGOPQb4BywB/1w7+BHEbmPTt3AiCZ1 zS71YAktbE0= =Vh46 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA15692 for ietf-open-pgp-bks; Wed, 31 Dec 1997 19:56:50 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA15688 for ; Wed, 31 Dec 1997 19:56:47 -0800 (PST) Received: from users.invweb.net (cppp20.dotstar.net [208.143.93.120]) by users.invweb.net (8.8.7/8.8.7) with SMTP id XAA16694; Wed, 31 Dec 1997 23:03:08 -0500 Message-Id: <199801010403.XAA16694@users.invweb.net> From: "William H. Geiger III" Date: Wed, 31 Dec 97 21:33:02 -0600 To: EKR In-Reply-To: <199801010258.SAA07113@itech.terisa.com> Cc: Steve Schear , EKR , ietf-tls@consensus.com, ietf-open-pgp@imc.org, ekr@terisa-bh.terisa.com Subject: Re: Proposed Extensions to TLS for OpenPGP X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199801010258.SAA07113@itech.terisa.com>, on 12/31/97 at 07:00 PM, EKR said: >In message , Steve Schear writes: >>At 2:25 PM -0800 12/31/97, EKR wrote: >>>Will Price writes: >>>> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote: >> >>[big snip] >>>Try to solve the following two examples: >>>Netscape and Microsoft. Netscape has downloads off their web site. >>>They want them to be easy. That means that the user can just >>>point and click. That means the crypto must be exportable or none >>>at all. Which do you suggest? >>>Next consider Microsoft. They embed their browser in the OS (at >>>least for now.). They want to ship that to foreigners. Again, >>>the crypto has to be exportable or nonexistent. Which do you >>>suggest? >>> >>>So, what do you suggest these companies do? >> >>How about funding programs such as Fortify, which patch browsers to enable 128 >>-bit SSL with all willing servers (whether or not they have supercerts)? >That seems like a fine plan, but it doesn't really speak to what Netscape >ships as a Netscape product, does it? We still talking crypto code ??? Sorry couldn't resist . There is no reason why Netscape, MS, ... etc could not interface their crypto code through a generic plugin interface. They the provide the specific plug-in they wish to ship for their crypto code. If someone wished to replace it they would be free to do so. If the plugin interface can be used for other things than crypto this would bypass the "crypto with a hole" concerns. Just as an interesting side note one can not to this date DL a 128 SSL version of the OS/2 Netscape browser. It takes next to an act of GOD to aquire one (how much of this is due to NS and how much this is due to IBM is anyone's guess). A rather sad state of afairs when one must aquire a 128bit browser via replay.com even when one is located in the US. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKsT+o9Co1n+aLhhAQEcDgQAu2W3HHjM5Bj/Acr68bndHHir42EnLMY3 V2Pt5qzs1Evb1wOS1Cj3uKooG2dLaVrh+fzxye8iFBSv32aSWIRzEXfluk9Fks0W 182XSq14AhpxKAFOb/c7QEw4Z0PRQaRUXGaCgXbSuQTF1CFOtnF1A6Ff7WK6p/4S eSo3ajB907c= =54Gw -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA15401 for ietf-open-pgp-bks; Wed, 31 Dec 1997 18:59:01 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA15397 for ; Wed, 31 Dec 1997 18:58:53 -0800 (PST) Received: from users.invweb.net (cppp20.dotstar.net [208.143.93.120]) by users.invweb.net (8.8.7/8.8.7) with SMTP id WAA16256; Wed, 31 Dec 1997 22:08:10 -0500 Message-Id: <199801010308.WAA16256@users.invweb.net> From: "William H. Geiger III" Date: Wed, 31 Dec 97 18:59:15 -0600 To: ietf-open-pgp@imc.org Cc: pgp-dev@pgpi.com Subject: Key Extraction odd behavior ??? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hi, I have been playing around with my OpenPGP packet analyzer code and I found somthing odd. For a signature packet that follows the userID packet for a key it should have a CTB of 0010 (Type 2) [0x89] but I have noticed that PGP 5.0 when extracting a key converts this to 1110 (Type 14) [0xB9]. If I check in CTB for the signature in the pubring.pkr it does have a CTB of 0010. It only seems to do this with DSS signatures and not RSA signatures. Now if I remove the key from the pubring.pkr and then readd it to the keyring the CTB is kept at 1100 [0xB9]. Now this doesn't seem to make sense in the context of the following data: B9 04 0D 04 34 A3 DF 8E ... B9 is 10111001 10 = CTB old format 1110 = packet type 14 01 = length packet 2 octets 04 0D = 1037 octets = remaining length of the public key. Now it after this I am getting lost. :( 04 = ?? subpacket length field ?? if so then what does the following 0x34 represent?? If we are to treat the 0xB9 as an error and assume that 0xB9 should really be 0x89 then: 89 is 10001101 10 = CTB old format 0011 = packet type 2 01 = length packet 2 octets 04 0D = 1037 octets = remaining length of the public key. 04 = sig version number (4) 34 = ?? sig type ?? (sigtype of 0x34 is undefined) If anyone understands what and why this conversion is being done and where I am going wrong in reading the format please let me know. I have attached the extracted key. Thanks, PS: Just as a side note to this section of the documentation. I find the switching between hex, bin, and dec to make the reading of the documentation much more complex. Also IMHO I think that any display of values 8 bits or less should be done in binary (this was done in the previous pgpformat documents including rfc1991). -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 5.0i for non-commercial use Comment: OS/2 Beta 1 mQGiBDSj34sRBADxJ2ENlj2F9UOvdtz1ouppQbdtOZtmg0wygQJa8dGD9Pju3d7D 0FzM2lttRMz1Fc94f7KHWUeV/My2vxgMnDtxT2bQKTQEZjvI9JSicLBqrUw5jkMU hclYa9WMsM74zEdhqVLSn0ad3LmZ6e3zKJj5qn3em3nGIzSWcYcMvSbUWQCg/zEZ Lp43kXPa9fES+sstlU0Quv0EAIPDy1mQJiTpISjoPJRFwqKUCI/VxjdJcR6PLvS1 Q4lV+gP9sBaUW4lrTMkyQ+BXxr0zW6gclpB/DB/KnnroMCx0IwV/610f+IRzKGhU SdpkG6opOL4CZxqKB4eUCGDj2ZcdLBPUFBzAB4weah+HdXUpydPdP61LW3Q/RpuT FAHrBACmE5IfAMbgY1kJ/+NhzzwVl5z6Kt3GtBzd2W5VkJEEd4qCY7mqFTbroUX0 FlIhEGnBjli/FxSnLkMG0UNZ3As4I4EOZUL+IVhOpvd+iSBAuz+4dO7N029HzaAJ 8GIqsjf/IgdjsrY5H4Nf8upEAuGnaJ3fN+RRH4LdR2L4sgC177QpV2lsbGlhbSBI LiBHZWlnZXIgSUlJIDx3aGdpaWlAaW52d2ViLm5ldD65BA0ENKPfjhAQAPkYoH5a BmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoLrOQ/40aUtjBKU9d8AhZIgLUV5SmZ qZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQyiJXQym+lehWKzh4XAvb+ExN1eOq Rsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjGzB13VyQ4SuLE8OiOE2eXTpITYfbb 6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ngw+Po1gr9oSgmC66prrNlD6IAUwGg fNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkItAjbBJstoXp18mAkKjX4t7eRdefXU kk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmP QFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24 rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56NoKVyOtQa8L9GAFgr5fSI/VhO SdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjTNP18 F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsC RtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYXAAICEACDUTMeCA8CcDUy855Y538x Kbk671Mkli/ZroR9U1L24isT9pl2cosTrFKccxnOnTZN9IMnOtRYx2h7B4DHXhXj 1wRoZnDknSa1Un8w74hMP9eSn3yOROM/Ba+lXmYzJZ3jJS+6Sy6YoUE09czI/1qA kYwx7Rh347/WGZX5hXGhb6uwGBjtlhJJprIl/9k/kN4TtMFbHwN2ADwmfHWWtiOn 4fSMZ6NO/Xfeo6kkD6Knw6GZ1QRklY0uCQ7p2q25s5zEuVqg4no+xRcwbmqkoubL 2FWavOeVgtoAQu2c+QHTwWgpvnFokSQzz2jVAi9xbU12xU0/XBKy9R7WsavAa4Tj RzOPUwPDhaeITUONZmX1zm0UNJ2Gr7gIM+HtiQhC49W1untNu/UdNRuoAXJPimux QqRohEiw+afA/3pvoLzIJmYQuu+BW2aAKrDyLiecPlSKGTRDCWcRq66ND4GfSvIt 5uWxo+RS0EKnW0TTlyMX7LzoSauC/702tM+Lm6rZQnrTRvHtpLvueekj2PxTpQ2s cDM7qPzYYSVYruZb6hWS2Z4ShGv/PJ0EGw/kZ4IxQLoXnGRyeXn6F0dpW2XggdKL DC8GKWxU6SPB7s+dwuQEFQKbmO1Q3cSUmL3jQV9N/eYdM+Q73tfsrBdgrfGHr/gN IWglLY80UOwcg1YVD8Wcww== =7P60 -----END PGP PUBLIC KEY BLOCK----- -- --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA15383 for ietf-open-pgp-bks; Wed, 31 Dec 1997 18:55:43 -0800 (PST) Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id SAA15379 for ; Wed, 31 Dec 1997 18:55:39 -0800 (PST) Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id SAA21540; Wed, 31 Dec 1997 18:58:58 -0800 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma021537; Wed, 31 Dec 97 18:58:36 -0800 Received: from kmac.terisa.COM (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id SAA07113; Wed, 31 Dec 1997 18:58:44 -0800 (PST) Message-Id: <199801010258.SAA07113@itech.terisa.com> To: Steve Schear cc: EKR , ietf-tls@consensus.com, ietf-open-pgp@imc.org, ekr@terisa-bh.terisa.com Subject: Re: Proposed Extensions to TLS for OpenPGP In-reply-to: Your message of "Wed, 31 Dec 1997 16:28:19 PST." Date: Wed, 31 Dec 1997 19:00:24 -0800 From: EKR Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In message , Steve Schear writes: >At 2:25 PM -0800 12/31/97, EKR wrote: >>Will Price writes: >>> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote: > >[big snip] >>Try to solve the following two examples: >>Netscape and Microsoft. Netscape has downloads off their web site. >>They want them to be easy. That means that the user can just >>point and click. That means the crypto must be exportable or none >>at all. Which do you suggest? >>Next consider Microsoft. They embed their browser in the OS (at >>least for now.). They want to ship that to foreigners. Again, >>the crypto has to be exportable or nonexistent. Which do you >>suggest? >> >>So, what do you suggest these companies do? > >How about funding programs such as Fortify, which patch browsers to enable 128 >-bit SSL with all willing servers (whether or not they have supercerts)? That seems like a fine plan, but it doesn't really speak to what Netscape ships as a Netscape product, does it? -Ekr Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA14238 for ietf-open-pgp-bks; Wed, 31 Dec 1997 16:27:55 -0800 (PST) Received: from lites.lvdi.net (lites.lvdi.net [208.129.21.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA14234 for ; Wed, 31 Dec 1997 16:27:51 -0800 (PST) Received: from [208.129.55.202] ([208.129.55.202]) by lites.lvdi.net (8.8.7/8.7.3) with ESMTP id QAA04071; Wed, 31 Dec 1997 16:23:05 -0800 (PST) X-Sender: schear@mail.lvdi.net Message-Id: In-Reply-To: <3hg7p1771.fsf@kmac.terisa.com> References: Will Price's message of Wed, 31 Dec 1997 00:07:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Dec 1997 16:28:19 -0800 To: EKR , From: Steve Schear Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 2:25 PM -0800 12/31/97, EKR wrote: >Will Price writes: >> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote: [big snip] >Try to solve the following two examples: >Netscape and Microsoft. Netscape has downloads off their web site. >They want them to be easy. That means that the user can just >point and click. That means the crypto must be exportable or none >at all. Which do you suggest? >Next consider Microsoft. They embed their browser in the OS (at >least for now.). They want to ship that to foreigners. Again, >the crypto has to be exportable or nonexistent. Which do you >suggest? > >So, what do you suggest these companies do? How about funding programs such as Fortify, which patch browsers to enable 128-bit SSL with all willing servers (whether or not they have supercerts)? --Steve Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA14163 for ietf-open-pgp-bks; Wed, 31 Dec 1997 16:22:47 -0800 (PST) Received: from out5.ibm.net (out5.ibm.net [165.87.194.245]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA14159 for ; Wed, 31 Dec 1997 16:22:44 -0800 (PST) Received: from deinet.aegreen.ibm.net (slip139-92-41-86.ut.nl.ibm.net [139.92.41.86]) by out5.ibm.net (8.8.5/8.6.9) with SMTP id AAA64546 for ; Thu, 1 Jan 1998 00:26:04 GMT Message-Id: <3.0.3.32.19980101012556.006d6a28@pop03.ca.us.ibm.net> X-PGP-RSA-KeyID: 0x78CD4329 X-PGP-RSA-Fingerprint: A3 57 37 48 54 88 FE 4A D6 81 C0 74 DA 00 A6 F7 X-HomePage: X-Sender: deinet.aegreen@pop03.ca.us.ibm.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 01 Jan 1998 01:25:56 +0100 To: IETF Open-PGP List From: "Anthony E. Greene" Subject: Re: Proposed Extensions to TLS for OpenPGP In-Reply-To: <3hg7p1771.fsf@kmac.terisa.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 14:25 31-12-97 -0800, EKR wrote: >Try to solve the following two examples: >Netscape and Microsoft. Netscape has downloads off their web site. >They want them to be easy. That means that the user can just >point and click. That means the crypto must be exportable or none >at all. Which do you suggest? A non-U.S. download site. >Next consider Microsoft. They embed their browser in the OS (at >least for now.). That browser is downloadable separately, legal briefs notwithstanding. The 128-bit version is available *now* from the U.S. site, separately from Win95. That means it can be downloaded separately from a non-U.S. site, separately from Win95, *if* Microsoft decides that it will do such a thing. > They want to ship that to foreigners. Again, >the crypto has to be exportable or nonexistent. Which do you >suggest? It is exportable, just not in electronic form. >So, what do you suggest these companies do? > >-Ekr Will made several suggestions. Your assertion that he did not offer any suggestions just ignores the fact that he did. I use the Win95, point-and-click-download-and-install version of PGP, legally available outside of the U.S. Not vaporware, or legal briefs, or statements about feasibility, legality, or possibility, but honest to goodness software. A real-world example of what is possible. The reasons that other companies do not do this are not technical or legal, but are based on policy decisions made in those companies. Is PGP Inc capable of things that Microsoft and Netscape are not? The very idea sounds ridiculous given the relative resources available. It's not that they can't, it's that they won't. There may be good reasons they won't, but let's not pretend that they *can't*, or that they don't have the resources to do it. -- Anthony E. Greene -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCcAwUBNKrUhERUP9V4zUMpAQG2CAQ1FB8D/UFvp0MN12EfAwJq+Y4Wu8+qFkOU hVm/00deQXQBTnEHLg3qHYSKdF8MUmR7Je63ivid9ueoRgnkvcUBUA+VaMUqokZ/ Zo/5yxBeiKvGvm7rD0QOCYJ66M+kVda9IaYm08EiFL1ioA5KhIKgsnUIcldkEUyX fC5OERm6we6GKm+68D9M =7wBu -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13902 for ietf-open-pgp-bks; Wed, 31 Dec 1997 15:55:01 -0800 (PST) Received: from lites.lvdi.net (lites.lvdi.net [208.129.21.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13898 for ; Wed, 31 Dec 1997 15:54:56 -0800 (PST) Received: from [208.129.55.202] ([208.129.55.202]) by lites.lvdi.net (8.8.7/8.7.3) with ESMTP id PAA03083; Wed, 31 Dec 1997 15:50:12 -0800 (PST) X-Sender: schear@mail.lvdi.net Message-Id: In-Reply-To: <3wwgmhtkj.fsf@kmac.terisa.com> References: Will Price's message of Tue, 30 Dec 1997 20:01:03 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Dec 1997 15:53:20 -0800 To: EKR From: Steve Schear Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> Some companies will undoubtedly never bring themselves to implementing one >> of the above systems and will thus be relegated to snake oil security >> internationally until the laws in the US change. >I think it's unreasonable to say that 40 bit crypto is "snake oil". >It's exactly as strong as advertised. There's no secret about the >situation. Yes, and quite useless. Were one to map the security claims of 40-bit crypto to the drug industry, I would surprised if the product would merit anything more than a symptom reliever status. > >> Let's not infect our protocols with such politics. TLS 1.0 is a done deal >> as far as I'm concerned. SSL3 had export algorithms, so TLS1 does too, >> fine. There are now many better solutions to the export problem, >Perhaps, but you haven't suggested any. Yes he has, your're just not accepting them. --Steve Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13849 for ietf-open-pgp-bks; Wed, 31 Dec 1997 15:41:57 -0800 (PST) Received: from lites.lvdi.net (lites.lvdi.net [208.129.21.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13845 for ; Wed, 31 Dec 1997 15:41:53 -0800 (PST) Received: from [208.129.55.202] ([208.129.55.202]) by lites.lvdi.net (8.8.7/8.7.3) with ESMTP id PAA02750 for ; Wed, 31 Dec 1997 15:40:15 -0800 (PST) X-Sender: schear@mail.lvdi.net Message-Id: In-Reply-To: <34A8D6F1.88FE21A9@netscape.com> References: <199712301000.FAA29400@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Dec 1997 15:46:20 -0800 To: ietf-open-pgp@imc.org From: Steve Schear Subject: Re: Proposed Extensions to TLS for OpenPGP Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> At the very least one would think that the US vendors would put thier >> crypto code in one DLL and document the API so someone overseas could >> replace it with somthing worth using. I guess even that is too >> much to ask. > >If the US government would let us, you better believe we'd do it. We have >no vested interest in helping the NSA eavesdrop on people. We make money >by selling software that meet our customers' needs, and that includes being >secure. > >The strategy you describe is called "crypto with a hole", and is explicitly >forbidden by the export regs. I don't think so. If functional code is exported in machine-readable form= and contains no "hook" calls, and another document containing a diff is= separately exported as printed materials, and therefore protected (just= like PGP's code), then it is the receptient not the exporter that added the= crypto (which was in no way "required" by the machine-readable code). As Ned notes: "...software which was specifically designed or modified to= allow it to be used with encryption software is itself regulated. And so= is, for that matter, software which in turn references such software." But= if the machine-readable software contains no calls which are later replaced= by crypto and can function fine w/o the crypto, this should legally= circumvent the regs. =20 This is especially handy if the crypto routines are already available= offshore w/o EAR restraint (e.g., SSLeay), since the diff file can be quite= manageable in size, I hazard to guess even for programs the size of Navigat= or. --Steve Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13655 for ietf-open-pgp-bks; Wed, 31 Dec 1997 15:17:17 -0800 (PST) Received: from newmail.virgin.net ([194.168.54.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13650 for ; Wed, 31 Dec 1997 15:17:11 -0800 (PST) Received: from server.eternity.org ([194.168.73.116]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 549-33929U100000L2S50) with ESMTP id AAC22366; Wed, 31 Dec 1997 23:23:36 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id WAA00454; Wed, 31 Dec 1997 22:50:25 GMT Date: Wed, 31 Dec 1997 22:50:25 GMT Message-Id: <199712312250.WAA00454@server.eternity.org> From: Adam Back To: wprice@pgp.com CC: ietf-tls@consensus.com, ietf-open-pgp@imc.org In-reply-to: (message from Will Price on Tue, 30 Dec 1997 20:01:03 -0800) Subject: Re: Proposed Extensions to TLS for OpenPGP Sender: owner-ietf-open-pgp@imc.org Precedence: bulk As Will has now posted PGP's SMTP over TLS document now, I thought I re-post this comment on authenticating TLS with keys from another domain (PGP WoT domain). This would neatly avoid the complexity of adding PGP certificates to TLS because unauthenticated (and preferably forward secret) modes could be used for TLS such as ADH (anonymous DH). (ADH-DES-CBC3-SHA being the strongest of the unauthenticated cipher suites). The point at which you would tie together the key material from the PGP WoT based authentication with the TLS pre-master-secret I have not considered in depth so far. Adam ==============================8<============================== Date: Sun, 26 Oct 1997 12:26:52 GMT From: Adam Back To: One thing I'd like to see discussed is TLS (Transport Level Security) for delivering pgp encrypted mails. One objection to TLS is that it's difficult to authenticate without key management. This is true enough, though there is some value in PFS (Perfect Forward Secrecy) TLS even without authentication -- this value is that it forces an attacker to be active to even be able to archive encrytped traffic. The presumption is that a) active attacks are harder, and that b) governments will find it harder to do lots of active attacks at once. So PFS TLS is a good trend for protecting against future government abuses... if lots of software is using PFS TLS, well government will have some problems recalling all that software, and persuading people to downgrade. That's unauthenticated PFS TLS. But I reckon this hack works: with PGP you've already got a WoT (Web of Trust), so you don't need a separate key infrastructure to authenicate TLS, and this is good because deploying automatic key infrastructures (such as perhaps for DNSSEC) is complex. The way to use PGP's WoT for TLS authentication is to have a communication between MUA (Mail User Agent, eg a future pgp6.0) and the MTA (Mail Transfer Agent, eg SMTP, or SMTP agent with SMTP extensions). It is even possible to have non-interactive, one sided communications between sending MUA and MTA, and between receiving MTA and MUA which is a good thing as it is after all store and forward and there may be some local store and forward hops on the way to the TLS secured SMTP delivery over the Internet, and some further local hops after receipt. I figure all that is needed is this: TLS secured link MUA1 --> MTA1 --> TLS-MTA1 ================> TLS-MTA2 --> MTA2 --> MUA2 MTA1 and MTA2 represent local MTAs just distributing email inside an organisation (inside the firewall), and just serve to show that any communications better be one-sided, and not require replies. TLS-MTA1 and TLS-MTA2 are the MTAs which actually send info out through the firewall. The topology of the communications suggests that MUA1 can send to TLS-MTA1, but can't expect a reply. And that TLS-MTA2 can send to MUA2, but can't expect a reply. You can authenticate the TLS link based on the PGP WoT using that communications pattern. MUA1 -> TLS-MTA1 communication would be a key k1 to use for authentication. The key would be sent as a mail-header: X-auth-key: 0x1234132413241324 TLS-MTA1 would authenticate with this key. (Perhaps computing a hash of the negotiated DH (Diffie-Hellman) or transient EG (El Gamal) key and the key. Perhaps: auth1 = hash( k1 || negotiated-dh-params ) The authentation information would be sent as a mail header, and the key information would be removed, so X-auth-key line would be removed, and this line added: X-auth: 0x567856785678578578578 Then TLS-MTA2 (the recipient TLS) would just pass this info on unchanged. The receiving MUA would also need the information about the negotiated-dh-parameters, that info would have to be sent to it by the recieving MTA, presumably with another header: X-auth-parameters: 0x123413241324, 0x3653563463654563653 or whatever. Then the receiving MUA can check the X-auth line agains the key k1 included in the PGP encrypted message, by recomputing: auth1 = hash( k1 || negotiated-dh-params ) The key k1 would be included inside the pgp message (or perhaps be derived from something which is already there, perhaps k1 = hash( session-key), the hash of the symmetric session key used to encrypt the message). The MUA would use the X-auth field to check the TLS authentication. A MITM could be flagged by the recipients MUA. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13648 for ietf-open-pgp-bks; Wed, 31 Dec 1997 15:17:10 -0800 (PST) Received: from newmail.virgin.net ([194.168.54.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13644 for ; Wed, 31 Dec 1997 15:17:05 -0800 (PST) Received: from server.eternity.org ([194.168.73.116]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 549-33929U100000L2S50) with ESMTP id AAB22366; Wed, 31 Dec 1997 23:23:31 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id WAA00437; Wed, 31 Dec 1997 22:40:25 GMT Date: Wed, 31 Dec 1997 22:40:25 GMT Message-Id: <199712312240.WAA00437@server.eternity.org> From: Adam Back To: hal@rain.org CC: ietf-open-pgp@imc.org In-reply-to: <199712311642.IAA05720@s20.term1.sb.rain.org> (message from Hal Finney on Wed, 31 Dec 1997 08:42:23 -0800) Subject: OpenPGP IETF meeting -- what happened? (Re: section 4.3) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney writes: > [other stuff] > > This is a good explanation. Thanks for providing it. There has been so > much attention paid to the additional recipient feature that few people have > had the energy to look at the other new features. What happened to the ARR anyway? Is it still there? What happened at IETF? Would anyone who attended OpenPGP at IETF like to spend 5 mins giving a run down of any significant decisions made etc? (I imagine the Network Associates buyout has delayed things, but it has been some time, and I'm sure we're all interested to hear what happened). Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA13428 for ietf-open-pgp-bks; Wed, 31 Dec 1997 14:43:36 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA13424 for ; Wed, 31 Dec 1997 14:43:33 -0800 (PST) Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2.lmco.com (8.8.8/8.8.8) with ESMTP id RAA29281 for ; Wed, 31 Dec 1997 17:46:55 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EM200I8NSL393@lmco.com> for ietf-open-pgp@imc.org; Wed, 31 Dec 1997 17:46:15 -0500 (EST) Date: Wed, 31 Dec 1997 17:46:09 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: Re: Proposed Extensions to TLS for OpenPGP To: whgiii@invweb.net Cc: ietf-open-pgp@imc.org Message-id: <971231174609.202093a7@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >At the very least one would think that the US vendors would put thier >crypto code in one DLL and document the API so someone overseas could >replace it with somthing worth using. I guess even that is too much >to ask. Was the topic of a discussion a few years ago about ITAR. The conclusion was that adding "hooks" like that was right out. Have the text in my office, think it was under "auxilliary devices" or some such. Anyone know if it is in the EAR ? Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA13169 for ietf-open-pgp-bks; Wed, 31 Dec 1997 14:20:11 -0800 (PST) Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA13165 for ; Wed, 31 Dec 1997 14:20:07 -0800 (PST) Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id OAA17922; Wed, 31 Dec 1997 14:23:35 -0800 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma017920; Wed, 31 Dec 97 14:23:33 -0800 Received: from kmac.daisy (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id OAA05363; Wed, 31 Dec 1997 14:23:42 -0800 (PST) Received: by kmac.daisy (4.1/SMI-4.1) id AA02463; Wed, 31 Dec 97 14:25:23 PST To: Cc: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: From: EKR Date: 31 Dec 1997 14:25:22 -0800 In-Reply-To: Will Price's message of Wed, 31 Dec 1997 00:07:32 -0800 Message-Id: <3hg7p1771.fsf@kmac.terisa.com> Lines: 120 X-Mailer: Gnus v5.4.37/XEmacs 19.15 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Will Price writes: > At 11:15 PM -0800 12/30/97, Eric Rescorla wrote: > >Will, I'm not particularly interested in debating protocol > >level crypto policy here. However, the crypto export laws > >are reality for most people here, and I find your attempt to > >imply that they're easily worked around fairly disingenuous. > > Easily? If you got the impression from my message that it was easy, I > suggest you read it again. What you imply here is that you need an easy > solution. If you were willing to do something slightly less than easy, you > might find another solution as other companies have. This issue is at the > very core of secure software. If it isn't done right, nothing is. Use of > 40 bit scrambling is exactly the kind of issue on which companies making > security products cannot use the easy solution. No, what I imply here is that the solutions you propose are unworkable. I don't really see any evidence to the contrary. > >Will Price writes: > >It's hard to believe that this is really going to work for many > >real programs. Have you seen the size of Netscape lately. Have > >you noticed how often Netscape ships new versions? (I'm not > >trying to pick on Netscape here. IE has similar characteristics. > >There are plenty of other big programs but web browsers hae > >particularly fast release cycles.) > > Have you seen the size of PGP 5.5.3 on 10 different platforms lately with > all the GUI code? It's not exactly small. I don't own a copy of PGP, however, your web site says that: Note: The Unix Binary versions vary in size from 1.3MB to 1.5MB. The latest version of Netscape on my machine is 8 megabytes. These just aren't commensurate. > >> insecure. Such stories reduce user faith in everybody's security products. > >> The only solution is public code review. > >It's not obvious this makes much of a difference. Note that Sendmail > >source code has been widely available since the beginning. > > Nobody trusts sendmail. Nobody needs to trust sendmail if they use secure > mail. You're getting bogged down in the comsec mentality. Sendmail is a nightmare from a systems security perspective. > Secure systems are built to be simple enough to comprehend fully so > that reviewers can analyze it fully. Sendmail clearly doesn't fall into > this category. Everyone knows sendmail is buggy, so nobody wastes their > time trying to document every bug. This statement is incorrect. There has actually been quite a concerted effort to fix the security bugs in Sendmail. It's just been an utter failure since there seem to be a nearly infinite number. > >> Some companies will undoubtedly never bring themselves to implementing one > >> of the above systems and will thus be relegated to snake oil security > >> internationally until the laws in the US change. > >I think it's unreasonable to say that 40 bit crypto is "snake oil". > >It's exactly as strong as advertised. There's no secret about the > >situation. > > There is no "advertising" of it. The users are simply unaware -- > effectively making it a secret. When was the last time you saw a big > company putting a very visible warning about 40 bit security inside its 40 > bit product? Uh, let's see. When you pull down Document Info in Netscape, it says: Security: This is a secure document that uses a medium-grade encryption key suited for U.S. export (RC4-40, 128 bit with 40 secret). Hard to get more clear than that. > I know I've never seen something like that. Further, even > the strong crypto products are infected by the weak crypto products in > protocols like S/MIME and SSL which require both sides to use the same > algorithms. No warning is given in those cases either in any of the > products I've examined. It leads to a cascade effect wherein the vast > majority of users end up having no security when they think they do have > security. The deceit here is that even when users learn about 40 bit > security, they think it is still encryption. Realistically, it just isn't. This is a religious statement, not a technical one. Actually, the work factor to break a 40 bit key is substantial. For example, Damien Doligez's crack took the following resources: The 40-bit secret part of the key is 7e f0 96 1f a6. I found it by a brute force search on a network of about 120 workstations and a few parallel computers at INRIA, Ecole Polytechnique, and Ecole Normale Superieure. The key was found after scanning a little more than half the key space in 8 days. 40 bit is next to worthless against a dedicated attacker. However, there certainly are applications for which it is sufficient. Horses for courses and all that. >>Perhaps, but you haven't suggested any. > I > suggested three each of which is completely workable and in use by > real companies as big as Sun. It isn't clear how you say that I > have not suggested any when there are very clearly three > alternatives suggested. If these don't work for you, I suggest > seeking legal advice. There are many other roads that haven't yet > been travelled. Don't look for the easy solution, look for the > right solution. Hmmm... I'm not convinced that any of these is really workable. Try to solve the following two examples: Netscape and Microsoft. Netscape has downloads off their web site. They want them to be easy. That means that the user can just point and click. That means the crypto must be exportable or none at all. Which do you suggest? Next consider Microsoft. They embed their browser in the OS (at least for now.). They want to ship that to foreigners. Again, the crypto has to be exportable or nonexistent. Which do you suggest? So, what do you suggest these companies do? -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA11365 for ietf-open-pgp-bks; Wed, 31 Dec 1997 10:52:11 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA11361 for ; Wed, 31 Dec 1997 10:52:07 -0800 (PST) Received: from users.invweb.net (ppp31.dotstar.net [208.143.93.50]) by users.invweb.net (8.8.7/8.8.7) with SMTP id OAA12462; Wed, 31 Dec 1997 14:01:31 -0500 Message-Id: <199712311901.OAA12462@users.invweb.net> From: "William H. Geiger III" Date: Wed, 31 Dec 97 12:45:01 -0600 To: Hal Finney In-Reply-To: <199712311642.IAA05720@s20.term1.sb.rain.org> Cc: ietf-open-pgp@imc.org Subject: Re: section 4.3 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199712311642.IAA05720@s20.term1.sb.rain.org>, on 12/31/97 at 08:42 AM, Hal Finney said: >We have not attempted to give detailed explanations of the intented uses >or motivations of any of the features in the spec. The spec simply >defines the syntax and semantics. There have been suggestions that we >need a companion document to define rationale for the various features, >which could be a follow-on project. It seems to me though that almost >every section of the spec deserves a page or more describing the >motivations, the purpose, security considerations, things to watch for, >etc. So a rationale doc would probably considerably larger than the >spec, and its creation will be a large project. Well I have been working on a document for outlining the implementation of the OpenPGP spec to messaging systems. I have around 35 pages written so far and I am no where close to being done. Much of the info in the document comes from my own experince of integrating PGP into messageing systems over the past couple of years. Below is an outline of the document: Contents: ========= I Inbound Processing a Encrypted Messages b Signed Messages c Attached Keys d Message Stamping II Outbound Processing a Auto Signing b Auto Encryption c WordWrap III User Interaction a Key Lookups b Signing c Encrypting d Attaching Keys e Decrypting f Verifying Signatures g Removing Signatures h Detaching Keys IV Key Generation V Key Management a KeyRing Indexing b Key Lookups c KeyServer Interaction d Multiple Keyring Support e Key Caching VI Remote Processing a Signature Verification b Message Encryption c Policy Enforcement VII 3rd Party Services a Time Stamping Services b Notary Services c Certifying Authorities (CA's) Appendix A References Appendix B Glossary Appendix C Example Code Index - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKqVE49Co1n+aLhhAQF4mgP7BITf6kL2qSIN8bT2XXcNEw8bokw4oo+T +/MOxY+b9PZNupEy1NPpAntqyhLYbJIQozqouoXh9pVZJTjpgEGLH4V5JVPYNuuJ roKtzwV53kQw07bDpMs2JWuWoi1I4A+65FdhmeA7Q0SqQOZBLQh13jUYg1scOX11 VhQN6uKmEQ4= =RiU9 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA10464 for ietf-open-pgp-bks; Wed, 31 Dec 1997 09:27:14 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA10460 for ; Wed, 31 Dec 1997 09:27:10 -0800 (PST) Received: from s20.term1.sb.rain.org (s09.term2.sb.rain.org [198.68.144.169]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id JAA09499 for ; Wed, 31 Dec 1997 09:30:35 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id IAA05720 for ietf-open-pgp@imc.org; Wed, 31 Dec 1997 08:42:23 -0800 Date: Wed, 31 Dec 1997 08:42:23 -0800 From: Hal Finney Message-Id: <199712311642.IAA05720@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: section 4.3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William H. Geiger III, , writes: > Hmmmmm I am going to present a senario below and see if this follows your > logic here: > > User 1 generate a KeyPair. > > User 1 self-signs (Sig1) his Public Key (Pub1) with the private key > (Sec1). > > In Sig1 he make's the sig non-revokable and the key revokable by User 2's > key (Sec2). > > Now Sec1 is comprimised and User1 may not have a copy of Sec1 after the > comprimise. > > User 1 notifies User 2 of the comprimise. [This presents an interesting > senario in itself of how does one notify User2 if the key used for > authentiaction is comprimised ]. [This would have to be done by out of band means, similar to how he would identify himself to get his key signed by another party.] > User 2 issues the revoke certificate (Revoke1) using Sec2. > > Revoke1 is accepted by Pub1 because of the 3rd party revoke flag in Sig1. > > The holder of the comprimised Sec1 can not prevent this as Sig1 is marked > as non revokable. This is a good explanation. Thanks for providing it. There has been so much attention paid to the additional recipient feature that few people have had the energy to look at the other new features. > I think I understand the service you are trying to provide but to be > honest it does not give me any warm fuzzies thinking about it. > > What does one do if Sec2 rather than Sec1 is comprimised? In that case Sec1 could be revoked improperly, and the keyholder would have to create a new key. This is a denial of service attack rather than a security breach. No encrypted messages to Sec1 could be read. So it is a less damaging attack. > What does user1 do if he whishes to change the status of the preferences > in his self signature? Say he no longer wishes for User2 to have revoke > powers, or User2 needs to change his revoke key (Sec2)? He would have to have two self signatures, one holding the third party revocation grant, and one holding his preferences. > Also how should the non-revoke flag interact with the experation flag? > Which should take presedent? Should a non-revokable signature be treated > as non-expirable? The non-revoke flag says that there will be no revocations. It does not say anything about expirations, so there is no reason to think it should be non-expirable. Look at it this way: since they are in the same signature, the same author must have created both the expiration and the non-revocation. The reasonable interpretation is that he wanted the signature to expire at the specified time, but he wanted it to be non-revocable prior to that time. > I think that a detaled explination of this subtype is warrented along with > it's inteded use and where it should never be used. Improperly implemented > this feature could cause all kinds of havok. Things like the non-revoke > flag being set on signatures other than self-signatures with the 3rd party > revoke being set. We have not attempted to give detailed explanations of the intented uses or motivations of any of the features in the spec. The spec simply defines the syntax and semantics. There have been suggestions that we need a companion document to define rationale for the various features, which could be a follow-on project. It seems to me though that almost every section of the spec deserves a page or more describing the motivations, the purpose, security considerations, things to watch for, etc. So a rationale doc would probably considerably larger than the spec, and its creation will be a large project. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA09091 for ietf-open-pgp-bks; Wed, 31 Dec 1997 07:42:49 -0800 (PST) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA09087 for ; Wed, 31 Dec 1997 07:42:45 -0800 (PST) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id JAA23251; Wed, 31 Dec 1997 09:45:34 -0600 (CST) Received: from dal-tx5-28.ix.netcom.com(207.94.121.156) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma023242; Wed Dec 31 09:45:20 1997 Message-ID: <34AA14D2.403A@ix.netcom.com> Date: Wed, 31 Dec 1997 09:48:03 +0000 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.03Gold (Win16; I) MIME-Version: 1.0 To: ietf-tls@consensus.com CC: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: <3wwgmhtkj.fsf@kmac.terisa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Eric and all, EKR wrote: > > Will, I'm not particularly interested in debating protocol > level crypto policy here. However, the crypto export laws > are reality for most people here, and I find your attempt to > imply that they're easily worked around fairly disingenuous. True enough. I agree There are no easy work arounds. But workarounds are really not the issue. US export and ITAR policy is. You are correct however this is not a good forum to discuss policy in that context. > Will Price writes: > > At Pretty Good Privacy, we developed a reliable system which will be > > continued by Network Associates. The outline: write source code for > > product, print source code in book, distribute book using normal means. > > Now the process becomes somewhat foggier. In any case, printed source code > > for product gets exported -- note that this is of course legal. > > Individuals outside the US scan source code. A legally exported binary > > version of the product then becomes available internationally. Copyrights, > > trademarks, and licenses protect the original vendor and revenue can be > > made off the exported product. This is only one highly functional system > > for getting this done. > It's hard to believe that this is really going to work for many > real programs. No not many, correct but some. And this is part of the problem to which I believe Will's point is trying to make here. > Have you seen the size of Netscape lately. Have > you noticed how often Netscape ships new versions? (I'm not > trying to pick on Netscape here. IE has similar characteristics. > There are plenty of other big programs but web browsers hae > particularly fast release cycles.) Exactly what I believe Will was trying to make here. > > > insecure. Such stories reduce user faith in everybody's security products. > > The only solution is public code review. > It's not obvious this makes much of a difference. Note that Sendmail > source code has been widely available since the beginning. > > > Some companies will undoubtedly never bring themselves to implementing one > > of the above systems and will thus be relegated to snake oil security > > internationally until the laws in the US change. > I think it's unreasonable to say that 40 bit crypto is "snake oil". > It's exactly as strong as advertised. There's no secret about the > situation. No, not snake oil, but for most serious applications nearly worthless. > > > Let's not infect our protocols with such politics. TLS 1.0 is a done deal > > as far as I'm concerned. SSL3 had export algorithms, so TLS1 does too, > > fine. There are now many better solutions to the export problem, > Perhaps, but you haven't suggested any. > > -Ekr > > -- > [Eric Rescorla Terisa Systems, Inc.] > "Put it in the top slot." Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. (Soon to be INEG. INC) Stay tunned! E-Mail jwkckid1@ix.netcom.com Wisdom: "One who knows others is wise, one who knows himself is enlightened." Lao Tzu Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA08426 for ietf-open-pgp-bks; Wed, 31 Dec 1997 06:33:45 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA08419 for ; Wed, 31 Dec 1997 06:33:41 -0800 (PST) Received: from users.invweb.net (ppp31.dotstar.net [208.143.93.50]) by users.invweb.net (8.8.7/8.8.7) with SMTP id JAA10462; Wed, 31 Dec 1997 09:42:20 -0500 Message-Id: <199712311442.JAA10462@users.invweb.net> From: "William H. Geiger III" Date: Wed, 31 Dec 97 08:34:34 -0600 To: Hal Finney In-Reply-To: <199712301801.KAA04145@s20.term1.sb.rain.org> Cc: ietf-open-pgp@imc.org Subject: Re: section 4.3 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199712301801.KAA04145@s20.term1.sb.rain.org>, on 12/30/97 at 01:01 PM, Hal Finney said: >> I also have some problems with some of the signature subpackets. >> >> - -- Revokable >> >> Is it really appropriate to have a signature that can not be revoked? >This was intended to be used along with the third-party revocation >mechanism. This allows you to specify that some third party key has the >power to revoked your key. People are constantly forgetting their >passphrases and are unable to revoke their own keys. This will allow >them to request a revocation from a designated third party. >However if this third-party authorization self-signature were itself >revocable, then someone who stole the secret key could revoke the >third-party revocation authorization, making any attempt by the third >party to revoke the key be ineffective. So at least in this case it >makes sense for the third party revocation authorization self signature >to be irrevocable. Given one use, more may be discovered, so I thought >it should be a separate subpacket. Hmmmmm I am going to present a senario below and see if this follows your logic here: User 1 generate a KeyPair. User 1 self-signs (Sig1) his Public Key (Pub1) with the private key (Sec1). In Sig1 he make's the sig non-revokable and the key revokable by User 2's key (Sec2). Now Sec1 is comprimised and User1 may not have a copy of Sec1 after the comprimise. User 1 notifies User 2 of the comprimise. [This presents an interesting senario in itself of how does one notify User2 if the key used for authentiaction is comprimised ]. User 2 issues the revoke certificate (Revoke1) using Sec2. Revoke1 is accepted by Pub1 because of the 3rd party revoke flag in Sig1. The holder of the comprimised Sec1 can not prevent this as Sig1 is marked as non revokable. I think I understand the service you are trying to provide but to be honest it does not give me any warm fuzzies thinking about it. What does one do if Sec2 rather than Sec1 is comprimised? What does user1 do if he whishes to change the status of the preferences in his self signature? Say he no longer wishes for User2 to have revoke powers, or User2 needs to change his revoke key (Sec2)? Also how should the non-revoke flag interact with the experation flag? Which should take presedent? Should a non-revokable signature be treated as non-expirable? I think that a detaled explination of this subtype is warrented along with it's inteded use and where it should never be used. Improperly implemented this feature could cause all kinds of havok. Things like the non-revoke flag being set on signatures other than self-signatures with the 3rd party revoke being set. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKpYWY9Co1n+aLhhAQGZ3wP/c9AJfqGXztnu+fBeC24X4Ucskxc3YHTw kz1TOorWV7jCqBcEkqK6b5vUrZO5gRcPOP23N8OGGrdxhNN2AbvbfuOnuk5/ieLM yfXv4jMXcOrbYiE4bFNjv0trFu2Lwy90IZJIRBqQaAZsS+4odZIe4wQSyyyXP1ya Z4OE/koOBuc= =XJWL -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA04456 for ietf-open-pgp-bks; Wed, 31 Dec 1997 00:03:57 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA04452 for ; Wed, 31 Dec 1997 00:03:52 -0800 (PST) Received: from [205.180.137.244] (atropos.pgp.com [205.180.137.244]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id AAA24785; Wed, 31 Dec 1997 00:07:16 -0800 (PST) X-Sender: wprice@205.180.136.16 Message-Id: In-Reply-To: <3wwgmhtkj.fsf@kmac.terisa.com> References: Will Price's message of Tue, 30 Dec 1997 20:01:03 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Dec 1997 00:07:32 -0800 To: ietf-tls@consensus.com From: Will Price Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:15 PM -0800 12/30/97, Eric Rescorla wrote: >Will, I'm not particularly interested in debating protocol >level crypto policy here. However, the crypto export laws >are reality for most people here, and I find your attempt to >imply that they're easily worked around fairly disingenuous. Easily? If you got the impression from my message that it was easy, I suggest you read it again. What you imply here is that you need an easy solution. If you were willing to do something slightly less than easy, you might find another solution as other companies have. This issue is at the very core of secure software. If it isn't done right, nothing is. Use of 40 bit scrambling is exactly the kind of issue on which companies making security products cannot use the easy solution. >Will Price writes: >> At Pretty Good Privacy, we developed a reliable system which will be >> continued by Network Associates. The outline: write source code for >> product, print source code in book, distribute book using normal means. >> Now the process becomes somewhat foggier. In any case, printed source code >> for product gets exported -- note that this is of course legal. >> Individuals outside the US scan source code. A legally exported binary >> version of the product then becomes available internationally. Copyrights, >> trademarks, and licenses protect the original vendor and revenue can be >> made off the exported product. This is only one highly functional system >> for getting this done. >It's hard to believe that this is really going to work for many >real programs. Have you seen the size of Netscape lately. Have >you noticed how often Netscape ships new versions? (I'm not >trying to pick on Netscape here. IE has similar characteristics. >There are plenty of other big programs but web browsers hae >particularly fast release cycles.) Have you seen the size of PGP 5.5.3 on 10 different platforms lately with all the GUI code? It's not exactly small. As for dot releases, use a diff printed release. Publish the diffs since the last source release. We've done it. It works. Big is not an issue. Binaries, pictures, and all the other things that go into a product are not an issue. Very simple, solved problems. >> insecure. Such stories reduce user faith in everybody's security products. >> The only solution is public code review. >It's not obvious this makes much of a difference. Note that Sendmail >source code has been widely available since the beginning. Nobody trusts sendmail. Nobody needs to trust sendmail if they use secure mail. Secure systems are built to be simple enough to comprehend fully so that reviewers can analyze it fully. Sendmail clearly doesn't fall into this category. Everyone knows sendmail is buggy, so nobody wastes their time trying to document every bug. >> Some companies will undoubtedly never bring themselves to implementing one >> of the above systems and will thus be relegated to snake oil security >> internationally until the laws in the US change. >I think it's unreasonable to say that 40 bit crypto is "snake oil". >It's exactly as strong as advertised. There's no secret about the >situation. There is no "advertising" of it. The users are simply unaware -- effectively making it a secret. When was the last time you saw a big company putting a very visible warning about 40 bit security inside its 40 bit product? I know I've never seen something like that. Further, even the strong crypto products are infected by the weak crypto products in protocols like S/MIME and SSL which require both sides to use the same algorithms. No warning is given in those cases either in any of the products I've examined. It leads to a cascade effect wherein the vast majority of users end up having no security when they think they do have security. The deceit here is that even when users learn about 40 bit security, they think it is still encryption. Realistically, it just isn't. >> Let's not infect our protocols with such politics. TLS 1.0 is a done deal >> as far as I'm concerned. SSL3 had export algorithms, so TLS1 does too, >> fine. There are now many better solutions to the export problem, >Perhaps, but you haven't suggested any. I suggested three each of which is completely workable and in use by real companies as big as Sun. It isn't clear how you say that I have not suggested any when there are very clearly three alternatives suggested. If these don't work for you, I suggest seeking legal advice. There are many other roads that haven't yet been travelled. Don't look for the easy solution, look for the right solution. -Will Will Price, Architect Network Associates, Inc. Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Cell/VM (650)533-0399 PGPkey: Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA04121 for ietf-open-pgp-bks; Tue, 30 Dec 1997 23:10:19 -0800 (PST) Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id XAA04116 for ; Tue, 30 Dec 1997 23:10:16 -0800 (PST) Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id XAA07386; Tue, 30 Dec 1997 23:13:40 -0800 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma007384; Tue, 30 Dec 97 23:13:35 -0800 Received: from kmac.daisy (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id XAA25965; Tue, 30 Dec 1997 23:13:44 -0800 (PST) Received: by kmac.daisy (4.1/SMI-4.1) id AA02281; Tue, 30 Dec 97 23:15:24 PST To: Cc: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: From: EKR Date: 30 Dec 1997 23:15:24 -0800 In-Reply-To: Will Price's message of Tue, 30 Dec 1997 20:01:03 -0800 Message-Id: <3wwgmhtkj.fsf@kmac.terisa.com> Lines: 45 X-Mailer: Gnus v5.4.37/XEmacs 19.15 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Will, I'm not particularly interested in debating protocol level crypto policy here. However, the crypto export laws are reality for most people here, and I find your attempt to imply that they're easily worked around fairly disingenuous. Will Price writes: > At Pretty Good Privacy, we developed a reliable system which will be > continued by Network Associates. The outline: write source code for > product, print source code in book, distribute book using normal means. > Now the process becomes somewhat foggier. In any case, printed source code > for product gets exported -- note that this is of course legal. > Individuals outside the US scan source code. A legally exported binary > version of the product then becomes available internationally. Copyrights, > trademarks, and licenses protect the original vendor and revenue can be > made off the exported product. This is only one highly functional system > for getting this done. It's hard to believe that this is really going to work for many real programs. Have you seen the size of Netscape lately. Have you noticed how often Netscape ships new versions? (I'm not trying to pick on Netscape here. IE has similar characteristics. There are plenty of other big programs but web browsers hae particularly fast release cycles.) > insecure. Such stories reduce user faith in everybody's security products. > The only solution is public code review. It's not obvious this makes much of a difference. Note that Sendmail source code has been widely available since the beginning. > Some companies will undoubtedly never bring themselves to implementing one > of the above systems and will thus be relegated to snake oil security > internationally until the laws in the US change. I think it's unreasonable to say that 40 bit crypto is "snake oil". It's exactly as strong as advertised. There's no secret about the situation. > Let's not infect our protocols with such politics. TLS 1.0 is a done deal > as far as I'm concerned. SSL3 had export algorithms, so TLS1 does too, > fine. There are now many better solutions to the export problem, Perhaps, but you haven't suggested any. -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA02602 for ietf-open-pgp-bks; Tue, 30 Dec 1997 19:57:27 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA02598 for ; Tue, 30 Dec 1997 19:57:23 -0800 (PST) Received: from [205.180.137.244] (atropos.pgp.com [205.180.137.244]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id UAA23970; Tue, 30 Dec 1997 20:00:47 -0800 (PST) X-Sender: wprice@205.180.136.16 Message-Id: In-Reply-To: <34A972B3.533CE3BB@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Dec 1997 20:01:03 -0800 To: ietf-tls@consensus.com, ietf-open-pgp@imc.org From: Will Price Subject: Re: Proposed Extensions to TLS for OpenPGP Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Rather than quoting the messages on this topic, I'll just reference the other messages on the topic of export algorithms and issues which originated from my exclusion of export algorithms from the TLS/OpenPGP Spec. The debate over exactly what one can export legally usually proceeds under seriously false assumptions in my opinion. It generally starts with what bit level algorithm can be exported, proceeds to discussions about hooks whether general or crypto specific, usually has some mention of MS-CAPI until people realize that the modules have to be signed, those with legal knowledge try to jump in and help, and ends up with people being somewhat confused and feeling fairly helpless leading to less crypto software being written -- exactly the result the US government intended. Not directed at anyone in particular, but let's get back to basics people. There's no sense whatsoever in putting "export" algorithms into a product. It isn't encryption. The time is truly upon us when export algorithms are crackable in near real time by normal people. You might as well include a decoder ring with your product, it will take just as long or longer to decrypt for a casual attacker. At Pretty Good Privacy, we developed a reliable system which will be continued by Network Associates. The outline: write source code for product, print source code in book, distribute book using normal means. Now the process becomes somewhat foggier. In any case, printed source code for product gets exported -- note that this is of course legal. Individuals outside the US scan source code. A legally exported binary version of the product then becomes available internationally. Copyrights, trademarks, and licenses protect the original vendor and revenue can be made off the exported product. This is only one highly functional system for getting this done. One other alternative is to base all R&D outside the US which is infeasible for most US companies -- but Sun did it with SKIP. Finally, the crypto hooks mechanism does work and Commerce does in fact approve APIs that are intended for crypto but have been generalized for other uses, Qualcomm's EMSAPI used in Eudora is a perfect example of this. I can hear the first cry that some people will have now: are you crazy, we can't publish our source code! My response: well then what are you doing in the security business? This sector isn't about proprietary algorithms and code. It is not feasible to achieve secure software without public peer review by many cryptographers. We have seen time and time again how the smallest security bugs have turned into major international crises for some of the larger companies doing this. One can only imagine how many more such issues are left to be found were a quality cryptographic public peer review to take place on such products with access to source code. The majority of users reading the New York Times have no clue what a particular security flaw is about. They just know that the NYT says that product is insecure. Such stories reduce user faith in everybody's security products. The only solution is public code review. Now I can hear not only the cries about publishing source code, but the feathers of some readers getting ruffled believing that I have implied security flaws in their wonderful products. Not at all. I have the utmost respect for any company that makes an attempt to write crypto software in the US. We're all under these silly laws together. I use some of the products which have had reported security flaws in the past, but those products would be that much more valuable if one was able to trust their security from 3rd party review and if their protocol infrastructures had not been infected by 40 bit scrambling algorithms. Some companies will undoubtedly never bring themselves to implementing one of the above systems and will thus be relegated to snake oil security internationally until the laws in the US change. However, there *are* good and reliable ways for even the largest companies to solve this problem legally. Inclusion of "export" algorithms is, IMHO, security suicide. What has happened in many cases is that the installed base of, for instance, S/MIME and SSL users has been so infected by 40 bit clients that the vast majority really have no idea that the security they are using is completely useless. It forces those few with secure clients corresponding with those using 40 bit clients to also use 40 bit and so on -- generally without any warning to either user that their security has been eliminated. Some companies like Wells Fargo have tried to take a stand and require 128 bit crypto SSL and they get major flack from users who don't understand what is wrong with their 40 bit browser. Caving in and using 40 bit algorithms is *not* a solution to anything. We all know this, but the speed of business can make that choice less clear. The argument that "we have to sell it, so we have to include 40 bit" just doesn't wash given that there are all sorts of creative legal alternatives. The bigger the company, the more resources that company has to enable the alternatives -- which is why it is so odd that the smaller companies often produce the more secure software. Mass producing a source code book of >7000 pages for the PGP products isn't something a one person operation would be doing, but is trivial for a normal company. Let's not infect our protocols with such politics. TLS 1.0 is a done deal as far as I'm concerned. SSL3 had export algorithms, so TLS1 does too, fine. There are now many better solutions to the export problem, let's not fall into the trap of using the easiest way out in new specifications. -Will Will Price, Architect Network Associates, Inc. Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Cell/VM (650)533-0399 PGPkey: Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA02596 for ietf-open-pgp-bks; Tue, 30 Dec 1997 19:57:19 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA02592 for ; Tue, 30 Dec 1997 19:57:15 -0800 (PST) Received: from [205.180.137.244] (atropos.pgp.com [205.180.137.244]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id UAA23965; Tue, 30 Dec 1997 20:00:39 -0800 (PST) X-Sender: wprice@205.180.136.16 Message-Id: In-Reply-To: <34A88EC3.7B2C1260@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Dec 1997 20:00:55 -0800 To: ietf-tls@consensus.com From: Will Price Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:03 PM -0800 12/29/97, Tom Weinstein wrote: >Will Price wrote: >> >> The alternative seems to be to include another subpacket in the Hello >> packets negotiating certificate type just like compression is negotiated. >> This would also be allowed by the spec as per 7.4.1.2. If it was to be >> done that way, I felt that this negotiation should have been included in >> the TLS spec. Since I assume the time for that has passed, I opted for >> the ciphersuite overload. > >I don't think it can go into TLS 1.0, but it's definitely something we >should work towards for a TLS 1.1 or 2.0. Great. When does work start on TLS 1.1/2.0? Clearly, the TLS/OpenPGP document needs to move forward anyway based on TLS 1.0 and could later be revised for a future version of TLS. >>> 3. Omitting the DistinguishedName field in the CertificateRequest >>> field seems problematic. I understand PGP doesn't use DNs, >>> but there should be a way to indicate who might be potential signers >>> of a given key. >> >> OpenPGP keys generally have all the certs they need attached to them >> whereas X509 certs are only a single cert unto themselves thus requiring >> a chain if the specified cert is not directly certified by a root CA. >> With OpenPGP, if a particular signer key is not found, the client or >> server can use a certserver to look it up. > >Although TLS uses the X.509 cert formats, it doesn't require an X.500 >directory to operate. I don't think it's a good idea to require an OpenPGP >cert server, either. I didn't mean to imply any such requirement for a certserver in my message and the document makes no mention of such. As stated in the document, this issue is implementation dependent. The equivalent of a DN in OpenPGP is the 64 bit KeyID. A reading of the OpenPGP spec will show that the "DN" or KeyID is included in the certificate and can also replace the certificate. I can see some implementations requiring users to get their OpenPGP key certified by a particular CA, other implementations which simply accept any key on first connection and require the authentication from that same key on future connections like SSH, and other implementations which know the keys for particular addresses and transmit only the KeyID rather than the certificate. A particularly complex implementation could get the key in the Certificate message, lookup all the certifiers on a certserver and try to establish validity dynamically that way, but I don't see that as likely -- only a possible use. -Will Will Price, Architect Network Associates, Inc. Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Cell/VM (650)533-0399 PGPkey: Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA29224 for ietf-open-pgp-bks; Tue, 30 Dec 1997 13:30:34 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA29218 for ; Tue, 30 Dec 1997 13:30:30 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IRJSGWB9F49TDJL9@INNOSOFT.COM> for ietf-open-pgp@imc.org; Tue, 30 Dec 1997 13:32:51 PST Date: Tue, 30 Dec 1997 12:52:17 -0800 (PST) From: Ned Freed Subject: Re: Proposed Extensions to TLS for OpenPGP In-reply-to: "Your message dated Tue, 30 Dec 1997 12:45:51 +0000" <34A8ECFF.77F0A4A6@algroup.co.uk> To: Ben Laurie Cc: ietf-tls@consensus.com, "William H. Geiger III" , ietf-open-pgp@imc.org Message-id: <01IRSBY1X0JY9TDJL9@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk [This is fairly off-topic for the ietf-TLS list, but the issue is of such importance to implementors regardless of IETF policy regarding such matters that I think a little more discussion is permissible.] > > > At the very least one would think that the US vendors would put thier > > > crypto code in one DLL and document the API so someone overseas could > > > replace it with somthing worth using. I guess even that is too > > > much to ask. > > If the US government would let us, you better believe we'd do it. We have > > no vested interest in helping the NSA eavesdrop on people. We make money > > by selling software that meet our customers' needs, and that includes being > > secure. > > The strategy you describe is called "crypto with a hole", and is explicitly > > forbidden by the export regs. > Is this really true? I've heard it said a lot, but there's contradictory > evidence... > Way back when, NCSA were advised by the NSA that crypto hooks were > illegal, and should be removed. NCSA did so, and passed this advice on > to the Apache Group, who also did so. However, when later challenged, I > seem to remember that this was denied (i.e. the USG claimed that they > had never advised that hooks were illegal). This actually happened > before I was involved in Apache, but I investigated it in some depth > when I did Apache-SSL, in the hope that I could ease the load of > tracking new versions. The results were inconlusive, but the Apache > Group were unwilling to take the risk. So far, no-one has shown me > definitive proof that hooks are illegal. I'm no lawyer, but I think 15 CFR 774 supplement 1 section 5D002 does this, more or less. For those not familiar with this terminology, this the Code of Federal Regulations, Title 15 (Commerce and Foreign Trade), Volume 2 Chapter VII, part 774 (The Commerce Control List). This is one small piece of the EAR, or Export Administration Regulations, specifically its a subpart of the part that says what's covered and what isn't. A copy of this can be found at http://jya.com/774-ccl05.htm (I tried to find an officia GPO version of it at www.access.gpo.gov but I cannot figure out how to retrieve supplements from their server.) Specifically, item a in section 5D002 says that "Software specially designed or modified for the development, production or use of equipment or software controlled by ... section 5D002" comes under export control. (A self-referential rule... how cute.) And item c.1 in this same section specifies encyption software explicitly. In other words, there appears to me that software which was specifically designed or modified to allow it to be used with encryption software is itself regulated. And so is, for that matter, software which in turn references such software. > I'm also curious to know how Microsoft's CryptoAPI fits into this scheme > of things? My understanding is that CryptoAPI plugins are themselves signed, and unless that signature is valid the plugin cannot be used. As such, it is possible to regulate what plugs will actually work and what plugins will not work. > Another interesting factor is that the evolution of the Apache API is > gradually making it easier to add crypto without modification to the > base code (you can't actually do it yet, but less hacking is required > than at first). This has happened for reasons not directly connected > with crypto. If Apache's API enables the addition of crypto as a pure > module, does that make Apache's API unexportable, even if every aspect > of it can be justified without resort to crypto hooks? > Apache 2.0 (if it ever happens) is pretty likely to permit this, since > it will allow layered I/O (which is the last major hurdle preventing > it). Layered I/O is required to support all sorts of other advanced > features (such as compressed transfer encodings, SSI over CGI, blah, > blah). This, I think, is a very interesting point. The text I just cited seems like it may only apply to interfaces specifically designed for cryptographic plugins. A more generic plugin interface with lots of other uses might fly. (Indeed, it is hard to see how it could not, given that such interfaces exist in abundance in literally hundreds of existing products.) Of course it doesn't serve the government's interest to clarify this in any way, which I think explains the NCSA debacle. It may well be that my reading of the regulations is totally incorrect -- as I said, I'm no lawyer. It may be that it is what it intended but not what the text actually ends up saying in a legal sense. It may be that my interpretation is what is intended and what is said but the rule is nevertheless flawed and unenforcable. It may be that the rule is valid and enforceable but doesn't cover interfaces with more general utility. Or it could cover the very general case, and everyone with a more general interface that could conceivably be used to hook in encryption is in technical violation of the law. However, a general chilling effect is obtained, especially among those of us with a fiduciary responsibility to our companies and stockholders, by leaving it unclear -- an effect that could never be obtained by a clearer rule. In any case, if you want to pursue this further offline I'd be happy to do so as well. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA28127 for ietf-open-pgp-bks; Tue, 30 Dec 1997 11:45:04 -0800 (PST) Received: from out4.ibm.net (out4.ibm.net [165.87.194.239]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA28123 for ; Tue, 30 Dec 1997 11:45:01 -0800 (PST) Received: from deinet.aegreen.ibm.net (slip139-92-41-105.ut.nl.ibm.net [139.92.41.105]) by out4.ibm.net (8.8.5/8.6.9) with SMTP id TAA22568 for ; Tue, 30 Dec 1997 19:48:19 GMT Message-Id: <3.0.3.32.19971230204411.006eb8cc@pop03.ca.us.ibm.net> X-PGP-RSA-KeyID: 0x78CD4329 X-PGP-RSA-Fingerprint: A3 57 37 48 54 88 FE 4A D6 81 C0 74 DA 00 A6 F7 X-HomePage: X-Sender: deinet.aegreen@pop03.ca.us.ibm.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 30 Dec 1997 20:44:11 +0100 To: IETF Open-PGP List From: "Anthony E. Greene" Subject: Re: Proposed Extensions to TLS for OpenPGP In-Reply-To: <199712301309.IAA30890@users.invweb.net> References: <34A8ECFF.77F0A4A6@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 07:00 30-12-97 -0600, William H. Geiger III wrote: >My understanding is that the MS Crypto API that is shiped overseas >contains only weak crypto. The API is also signed so that no new/modified >code can be added without the MS signature. > >I don't know for sure but I would imagine that the export product makes >use of a different key then the domestic product so that the domestic code >will not run on the export version. The way I understand it, the API requires that the crypto module be signed with Microsoft's corporate key. I assume that Microsoft follows ITAR in deciding which modules get signed. The USG required such a mechanism before allowing export of Microsoft products that include the API. For the purposes of this working group, that makes it useless. -- Anthony E. Greene PGP Key: -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCdAwUBNKlA+0RUP9V4zUMpAQHrcgQ6AhR0Y25/dEVLvmujkaSbNg6kPo6sCxqa b0BvCoiljle6PdsYfBxvIkUMhvF7/EuchqWaaU9tQysO5qhEJuBc0xVli2Mxv8Oa azlBSlF69V7D87oDhzuXDsab5Z7F4UpoN6nD0fSW6LybfLc7wunEsdynCI6Kei3d A66ZNSJeESJ1vX1WzjPpGA== =PQcr -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA27040 for ietf-open-pgp-bks; Tue, 30 Dec 1997 10:14:16 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA27036 for ; Tue, 30 Dec 1997 10:14:12 -0800 (PST) Received: from s20.term1.sb.rain.org (s16.term2.sb.rain.org [198.68.144.176]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id KAA14688; Tue, 30 Dec 1997 10:17:20 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA04145; Tue, 30 Dec 1997 10:01:52 -0800 Date: Tue, 30 Dec 1997 10:01:52 -0800 From: Hal Finney Message-Id: <199712301801.KAA04145@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, whgiii@invweb.net Subject: Re: section 4.3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William H. Geiger III, , writes: > I have a question regarding the Packet Tags (aka Cipher Type Byte) in > section 4.3 [page 16]. > > It has 14 as subkey packet, 15 reserved, and 16 as comment packet but > accorinding to my notes the comment packet currently is 1110 (14 base 10). > Also since 0-F is 0-15 (16 digits) it would seem that the Reserved status > for type 15 needs to be removed and that the Subkey Packet type be > assigned this number. This is assuming we are keeping current CTB's as is > and reserving the 2 byte type codes for future use. We changed packet type 14 from comment to subkey intentionally, to facilitate backwards compatibility with PGP 2.6.2. Packet 14 had never actually been emitted by any version of PGP, but it would be ignored. This way subkey packets don't break PGP 2.6.2. The DSS/ElGamal keys don't work with that version, of course, but at least 2.6.2 doesn't crash if it sees one. This was better than other solutions we tried. > There are quite a few issues that AFAIK are still unresolved yet there > seems to be little to no discussion of them: > > - -- UserID Revocation > - -- Signing of Just the Key > - -- Signing of Key and multiple userID's These would be better left for V2 of OPGP. I continue to believe that our best approach is to avoid introducing more new features. > I also have some problems with some of the signature subpackets. > > - -- Revokable > > Is it really appropriate to have a signature that can not be revoked? This was intended to be used along with the third-party revocation mechanism. This allows you to specify that some third party key has the power to revoked your key. People are constantly forgetting their passphrases and are unable to revoke their own keys. This will allow them to request a revocation from a designated third party. However if this third-party authorization self-signature were itself revocable, then someone who stole the secret key could revoke the third-party revocation authorization, making any attempt by the third party to revoke the key be ineffective. So at least in this case it makes sense for the third party revocation authorization self signature to be irrevocable. Given one use, more may be discovered, so I thought it should be a separate subpacket. > Also I didn't note any mechanism to inform an end user that various > preferences in the subpacket had changed. Perhaps there could be an > "update" signature subpacket. Basicly this is how it would work: An interesting idea for a future version. We need to think about extending it to go beyond a binary flag, though, since multiple updates may occur at different times. Also, I suspect that we may eventually have multiple self signature preference packets and you'd have to specify which one(s) had been updated. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA23765 for ietf-open-pgp-bks; Tue, 30 Dec 1997 05:00:40 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA23761 for ; Tue, 30 Dec 1997 05:00:36 -0800 (PST) Received: from users.invweb.net (cppp08.dotstar.net [208.143.93.108]) by users.invweb.net (8.8.7/8.8.7) with SMTP id IAA30890; Tue, 30 Dec 1997 08:09:09 -0500 Message-Id: <199712301309.IAA30890@users.invweb.net> From: "William H. Geiger III" Date: Tue, 30 Dec 97 07:00:32 -0600 To: Ben Laurie In-Reply-To: <34A8ECFF.77F0A4A6@algroup.co.uk> Cc: ietf-tls@consensus.com, ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <34A8ECFF.77F0A4A6@algroup.co.uk>, on 12/30/97 at 12:45 PM, Ben Laurie said: >I'm also curious to know how Microsoft's CryptoAPI fits into this scheme >of things? My understanding is that the MS Crypto API that is shiped overseas contains only weak crypto. The API is also signed so that no new/modified code can be added without the MS signature. I don't know for sure but I would imagine that the export product makes use of a different key then the domestic product so that the domestic code will not run on the export version. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKjxII9Co1n+aLhhAQF8ugQAhbXLYr3g1MDV9yrlZ/n1/cTyw8Obolgj ifwCrivIGdSqJPfGEmQNFRVwQndqz5QH5BWMrpgB81b2R4T/942ZckCWMixrYloe PpqQYKyFJ79uO/AFd7bnIP7Dx0YrHa+U+vLZZR1T8hhbQn8MdDOpAlV0I5RLoMng 406rpJ0w9zY= =R+io -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA23696 for ietf-open-pgp-bks; Tue, 30 Dec 1997 04:56:49 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA23692 for ; Tue, 30 Dec 1997 04:56:45 -0800 (PST) Received: from users.invweb.net (cppp08.dotstar.net [208.143.93.108]) by users.invweb.net (8.8.7/8.8.7) with SMTP id IAA30846; Tue, 30 Dec 1997 08:04:33 -0500 Message-Id: <199712301304.IAA30846@users.invweb.net> From: "William H. Geiger III" Date: Tue, 30 Dec 97 05:52:10 -0600 To: Tom Weinstein In-Reply-To: <34A8D6F1.88FE21A9@netscape.com> Cc: ietf-tls@consensus.com, ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <34A8D6F1.88FE21A9@netscape.com>, on 12/30/97 at 03:11 AM, Tom Weinstein said: >William H. Geiger III wrote: >> In <34A88EC3.7B2C1260@netscape.com>, on 12/30/97 >> at 01:03 AM, Tom Weinstein said: >> >>> While I support the ideal of building standards that use strong crypto, >>> it does nobody any good to create a standard which won't get >>> implemented. The export ciphers exist because in order for US software >>> manufacturers to use TLS, they have to be able to export the software >>> that includes it. It is certainly true that there are many software >>> developers who live in the free world, but those of us stuck in the US >>> still need to sell software. >> >> But who in their right minds are going to buy it?? >Products compete along more than one axis. It's a sad fact that much of >the most usable software is also some of the least secure. It would be >great if the most popular product could always be the most secure, but it >doesn't always work out that way. Do I really have to explain this to >anyone? It all depends on who you are marketing your product to and for what use. If you are adding crypto so joe sixpack can have warm fuzzies when he uses his credit card on the internet then you could use ROT-13 for all the difference it would make. On the other hand if you are trying to sell to john doe for securing his banking transaction security consideration far outweigh "usability". No matter how pretty you make your interface, if he has any smarts at all he woun't settle for rc2/40 or some other weak crypto. Look at the stink going on in Sweeden right now as the government is just finding out the their Lotus Notes system is insecure. >> I for one would *never* recomend to my overseas clients to use crippled >> US export crypto products. There are just too many people writting >> non-crippled software to justify it. >> >> At the very least one would think that the US vendors would put thier >> crypto code in one DLL and document the API so someone overseas could >> replace it with somthing worth using. I guess even that is too >> much to ask. >If the US government would let us, you better believe we'd do it. We >have no vested interest in helping the NSA eavesdrop on people. We make >money by selling software that meet our customers' needs, and that >includes being secure. >The strategy you describe is called "crypto with a hole", and is >explicitly forbidden by the export regs. I'll leave that one for the layers. :) An interesting thought: What liability does a software/hardware vendor have if they knowingly sell an insecure product and because of that the customers security is breached and losses are sustained? Are they open to charges of fraud if they market and sell a product as "Secure" while they know it is not? While US vendors make some sales in the short term unless things change they are going to find themselves to be a big fish in an ever shrinking pond. Once offshore security vendors become established meeting the unsatisfied demand for secure products overseas, US vendors will be fighting them for US market share (unless Freeh gets his way and restricts imports of strong crypto and domestic use of strong crypto). - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKjwDI9Co1n+aLhhAQHIDQQAjvq/+Q+TS/iYT7a0FmWChN5wonVrYTJc suu/u9ob6x7XyG6gP2XYnguhkzmm+0VvA5R8YaIunjDqSZWOUQdI6rFxauYkzhbF 6k8s2gGZzdFDUZ0erSZsNQ4BRLyw8ATlDbRcnd8g91cz3dgnHINcrJtFBEwmaml1 wj4Ys0IjD5k= =mj1h -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA23591 for ietf-open-pgp-bks; Tue, 30 Dec 1997 04:43:26 -0800 (PST) Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.7/8.7.3) with SMTP id EAA23587 for ; Tue, 30 Dec 1997 04:43:20 -0800 (PST) Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.6.12/8.6.12) with ESMTP id MAA09487; Tue, 30 Dec 1997 12:46:22 GMT Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id MAA29775; Tue, 30 Dec 1997 12:46:05 GMT Message-ID: <34A8ECFF.77F0A4A6@algroup.co.uk> Date: Tue, 30 Dec 1997 12:45:51 +0000 From: Ben Laurie Organization: A.L. Digital Ltd. X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-tls@consensus.com CC: "William H. Geiger III" , ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: <34A8D6F1.88FE21A9@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Tom Weinstein wrote: > > At the very least one would think that the US vendors would put thier > > crypto code in one DLL and document the API so someone overseas could > > replace it with somthing worth using. I guess even that is too > > much to ask. > > If the US government would let us, you better believe we'd do it. We have > no vested interest in helping the NSA eavesdrop on people. We make money > by selling software that meet our customers' needs, and that includes being > secure. > > The strategy you describe is called "crypto with a hole", and is explicitly > forbidden by the export regs. Is this really true? I've heard it said a lot, but there's contradictory evidence... Way back when, NCSA were advised by the NSA that crypto hooks were illegal, and should be removed. NCSA did so, and passed this advice on to the Apache Group, who also did so. However, when later challenged, I seem to remember that this was denied (i.e. the USG claimed that they had never advised that hooks were illegal). This actually happened before I was involved in Apache, but I investigated it in some depth when I did Apache-SSL, in the hope that I could ease the load of tracking new versions. The results were inconlusive, but the Apache Group were unwilling to take the risk. So far, no-one has shown me definitive proof that hooks are illegal. I'm also curious to know how Microsoft's CryptoAPI fits into this scheme of things? Another interesting factor is that the evolution of the Apache API is gradually making it easier to add crypto without modification to the base code (you can't actually do it yet, but less hacking is required than at first). This has happened for reasons not directly connected with crypto. If Apache's API enables the addition of crypto as a pure module, does that make Apache's API unexportable, even if every aspect of it can be justified without resort to crypto hooks? Apache 2.0 (if it ever happens) is pretty likely to permit this, since it will allow layered I/O (which is the last major hurdle preventing it). Layered I/O is required to support all sorts of other advanced features (such as compressed transfer encodings, SSI over CGI, blah, blah). Cheers, Ben. -- Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL London, England. |"Apache: TDG" http://www.ora.com/catalog/apache Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA23104 for ietf-open-pgp-bks; Tue, 30 Dec 1997 03:42:52 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA23100 for ; Tue, 30 Dec 1997 03:42:48 -0800 (PST) Received: from users.invweb.net (cppp08.dotstar.net [208.143.93.108]) by users.invweb.net (8.8.7/8.8.7) with SMTP id GAA30253 for ; Tue, 30 Dec 1997 06:51:27 -0500 Message-Id: <199712301151.GAA30253@users.invweb.net> From: "William H. Geiger III" Date: Tue, 30 Dec 97 04:51:24 -0600 To: ietf-open-pgp@imc.org Subject: section 4.3 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi, I have a question regarding the Packet Tags (aka Cipher Type Byte) in section 4.3 [page 16]. It has 14 as subkey packet, 15 reserved, and 16 as comment packet but accorinding to my notes the comment packet currently is 1110 (14 base 10). Also since 0-F is 0-15 (16 digits) it would seem that the Reserved status for type 15 needs to be removed and that the Subkey Packet type be assigned this number. This is assuming we are keeping current CTB's as is and reserving the 2 byte type codes for future use. After the holidays would it be possiable to get some type of status report to the list as far as where we are with the drafts? There are quite a few issues that AFAIK are still unresolved yet there seems to be little to no discussion of them: - -- UserID Revocation - -- Signing of Just the Key - -- Signing of Key and multiple userID's I also have some problems with some of the signature subpackets. - -- Revokable Is it really appropriate to have a signature that can not be revoked? Also I didn't note any mechanism to inform an end user that various preferences in the subpacket had changed. Perhaps there could be an "update" signature subpacket. Basicly this is how it would work: Adam self-signs his public key with all his preferences and then posts the key to his prefered public keyserver. Mary DL's the key and her OP software follows all of Adams preferences. 6mo latter Adam has updated his software and has new preferences. On all messages that Adam signs there is an "update" subpacket that tells Mary's OP software that Adam has changed his preferences and to get an updated key. At this time Mary need not know what changes have been made only that there has been changes and a updated key needs to be obtained. All that should be needed in the update subpacket is a timestamp which can be compared to the timestamp on the self signature on the public key. I wouldn't mind hearing where others are in implementing the OpenPGP draft (others are writting code arn't they ). - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKje7I9Co1n+aLhhAQHNqAP9F6HkjmyYhi0ymJJmF9llKF+dWYxnsNb+ Cm+GRSFpQZY5juOLUV1x6iSgNQsL/mX9dvXmfQ2CFDfMpLuL6sEmOhWMvvoaPd/f sYI01qMB71TPLJC+inLGBskO2WZBuKC1y/6ozT5BzzNN1ZCCZY0Ul+3mnCtsV/qP xRWHIuCrb4Y= =WlMc -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA22808 for ietf-open-pgp-bks; Tue, 30 Dec 1997 03:09:02 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA22804 for ; Tue, 30 Dec 1997 03:08:54 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA06467 for ; Tue, 30 Dec 1997 03:11:46 -0800 (PST) Received: from netscape.com ([206.222.233.75]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA16966; Tue, 30 Dec 1997 03:11:46 -0800 Message-ID: <34A8D6F1.88FE21A9@netscape.com> Date: Tue, 30 Dec 1997 03:11:45 -0800 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 5.0b1 [en] (X11; I; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: "William H. Geiger III" CC: ietf-tls@consensus.com, ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: <199712301000.FAA29400@users.invweb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William H. Geiger III wrote: > In <34A88EC3.7B2C1260@netscape.com>, on 12/30/97 > at 01:03 AM, Tom Weinstein said: > >> While I support the ideal of building standards that use strong crypto, >> it does nobody any good to create a standard which won't get >> implemented. The export ciphers exist because in order for US software >> manufacturers to use TLS, they have to be able to export the software >> that includes it. It is certainly true that there are many software >> developers who live in the free world, but those of us stuck in the US >> still need to sell software. > > But who in their right minds are going to buy it?? Products compete along more than one axis. It's a sad fact that much of the most usable software is also some of the least secure. It would be great if the most popular product could always be the most secure, but it doesn't always work out that way. Do I really have to explain this to anyone? > I for one would *never* recomend to my overseas clients to use crippled > US export crypto products. There are just too many people writting > non-crippled software to justify it. > > At the very least one would think that the US vendors would put thier > crypto code in one DLL and document the API so someone overseas could > replace it with somthing worth using. I guess even that is too > much to ask. If the US government would let us, you better believe we'd do it. We have no vested interest in helping the NSA eavesdrop on people. We make money by selling software that meet our customers' needs, and that includes being secure. The strategy you describe is called "crypto with a hole", and is explicitly forbidden by the export regs. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | tomw@netscape.com transcending structure. -- The Tao of Programming | Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA20280 for ietf-open-pgp-bks; Tue, 30 Dec 1997 01:52:15 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA20275 for ; Tue, 30 Dec 1997 01:52:11 -0800 (PST) Received: from users.invweb.net (cppp08.dotstar.net [208.143.93.108]) by users.invweb.net (8.8.7/8.8.7) with SMTP id FAA29400; Tue, 30 Dec 1997 05:00:24 -0500 Message-Id: <199712301000.FAA29400@users.invweb.net> From: "William H. Geiger III" Date: Tue, 30 Dec 97 03:47:52 -0600 To: Tom Weinstein In-Reply-To: <34A88EC3.7B2C1260@netscape.com> Cc: ietf-tls@consensus.com, ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <34A88EC3.7B2C1260@netscape.com>, on 12/30/97 at 01:03 AM, Tom Weinstein said: >While I support the ideal of building standards that use strong crypto, >it does nobody any good to create a standard which won't get implemented. >The export ciphers exist because in order for US software manufacturers >to use TLS, they have to be able to export the software that includes it. >It is certainly true that there are many software developers who live in >the free world, but those of us stuck in the US still need to sell >software. But who in their right minds are going to buy it?? I for one would *never* recomend to my overseas clients to use crippled US export crypto products. There are just too many people writting non-crippled software to justify it. At the very least one would think that the US vendors would put thier crypto code in one DLL and document the API so someone overseas could replace it with somthing worth using. I guess even that is too much to ask. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKjE549Co1n+aLhhAQEiIwQAreAQBbHLNGp1LFCMVzAmgpsrpMTMoTec 4mtYP9lyByoEcoTgXh8xUW3q2h9QFcHQ2RQYh0B4iAKblzIRAzgcojSMaKPFGLjN 7lfaXycXW2E3wLKgMphOlvE1PAdOOWjZMRn/fxaurFNCqS1bEwxszqTAR9orN34t RvMxnxHvTMA= =P9wS -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA18873 for ietf-open-pgp-bks; Mon, 29 Dec 1997 22:06:02 -0800 (PST) Received: from dfw-ix14.ix.netcom.com (dfw-ix14.ix.netcom.com [206.214.98.14]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA18866 for ; Mon, 29 Dec 1997 22:05:56 -0800 (PST) Received: (from smap@localhost) by dfw-ix14.ix.netcom.com (8.8.4/8.8.4) id AAA22312; Tue, 30 Dec 1997 00:08:34 -0600 (CST) Received: from dal-tx9-15.ix.netcom.com(207.94.123.143) by dfw-ix14.ix.netcom.com via smap (V1.3) id rma022293; Tue Dec 30 00:08:27 1997 Message-ID: <34A83C25.47D8@ix.netcom.com> Date: Tue, 30 Dec 1997 00:11:17 +0000 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.03Gold (Win16; I) MIME-Version: 1.0 To: ietf-tls@consensus.com CC: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: <34A889F9.5D1F2BD6@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Tom and all, Tom Weinstein wrote: > > EKR wrote: > > > > I see several problems here: > > 1. While overloading the cipherSuites mechanism is convenient and > > backwards compatible, it strikes me as ill-advised. In the limit, > > we end up with a large number of cipherSuites that differ only > > in the types of certificational material they provide. This > > fragments effort. Here you call out an RSA/3DES/RIPEMD mode. > > If that's a good idea, wouldn't it be a good idea with X.509 > > certificates as well? > > > > Algorithm choice is largely orthogonal to certificate format and > > should be represented as such. That does seem to be a missing > > capability in TLS. We should add it rather than hacking around > > it. > > Agreed. Rather than overloading cipherSuites with information about cert > formats, I think it would be better to extend TLS to provide for cert > format negotiation. I totaly agree. Hence on of the reasons we went ahead and developed our "Interface Facility (MLPI)" which incorporates this capability for any set of ciphersuites for most cert formats. I came to this conclusion over a year ago. > > -- > What is appropriate for the master is not appropriate| Tom Weinstein > for the novice. You must understand Tao before | tomw@netscape.com > transcending structure. -- The Tao of Programming | Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. (Soon to be INEG. INC) Stay tunned! Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com Wisdom: "One who knows others is wise, one who knows himself is enlightened." Lao Tzu Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA18825 for ietf-open-pgp-bks; Mon, 29 Dec 1997 22:01:02 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA18814 for ; Mon, 29 Dec 1997 22:00:57 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id WAA26674 for ; Mon, 29 Dec 1997 22:03:48 -0800 (PST) Received: from netscape.com ([206.222.233.75]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA22675; Mon, 29 Dec 1997 22:03:48 -0800 Message-ID: <34A88EC3.7B2C1260@netscape.com> Date: Mon, 29 Dec 1997 22:03:47 -0800 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 5.0b1 [en] (X11; I; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: ietf-tls@consensus.com CC: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Will Price wrote: > > The alternative seems to be to include another subpacket in the Hello > packets negotiating certificate type just like compression is negotiated. > This would also be allowed by the spec as per 7.4.1.2. If it was to be > done that way, I felt that this negotiation should have been included in > the TLS spec. Since I assume the time for that has passed, I opted for > the ciphersuite overload. I don't think it can go into TLS 1.0, but it's definitely something we should work towards for a TLS 1.1 or 2.0. >> Here you call out an RSA/3DES/RIPEMD mode. If that's a good idea, >> wouldn't it be a good idea with X.509 certificates as well? > > Yes, it would. Unfortunately once again, I assume the time to add such > things has passed. I felt it was important to have more than one hash > algorithm associated with the OpenPGP certificates, but didn't want to > use a potentially weak algorithm like MD5 (except where the TLS protocol > requires MD5). Were the TLS spec to ignore compatibility, I'm sure MD5 > would be eliminated, so I didn't want to add it to any new ciphersuites. > RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP. HMAC-MD5 still appears to be strong. While it would be nice to eliminate MD5 from TLS at some point, there don't seem to be a lot of good alternatives. In my opinion, RIPEMD-160 hasn't seen enough analysis to feel comfortable about it. I'd prefer to give it another few years, at least. >> 3. Omitting the DistinguishedName field in the CertificateRequest >> field seems problematic. I understand PGP doesn't use DNs, >> but there should be a way to indicate who might be potential signers >> of a given key. > > OpenPGP keys generally have all the certs they need attached to them > whereas X509 certs are only a single cert unto themselves thus requiring > a chain if the specified cert is not directly certified by a root CA. > With OpenPGP, if a particular signer key is not found, the client or > server can use a certserver to look it up. Although TLS uses the X.509 cert formats, it doesn't require an X.500 directory to operate. I don't think it's a good idea to require an OpenPGP cert server, either. >> 4. In addition, I don't see what the point of prohibiting >> "Export" ciphers with PGP keys is. Obviously, if you're explicitly >> calling out cipherSuites, you can simply omit all the export cipher >> suites from that list, but frankly, stating that "Export" algorithms >> also may not be used with OpenPGP keys" seems silly. It's not our >> place as protocol designers to tell people what they may use. > > The export sections of TLS seem to me to be a holdover from the SSL > legacy days and are there mostly for compatability. OpenPGP pays no > attention to this issue as it isn't appropriate to have such limits in an > international standard. Clearly, an implementation could choose to > implement their own ciphersuites for export algorithms with OpenPGP keys, > but there doesn't seem to be any reason to specify those as none of the > export quality algorithms are supported by OpenPGP. Simply removing the > statement does seem appropriate however making them implicitly excluded > rather than explicitly. While I support the ideal of building standards that use strong crypto, it does nobody any good to create a standard which won't get implemented. The export ciphers exist because in order for US software manufacturers to use TLS, they have to be able to export the software that includes it. It is certainly true that there are many software developers who live in the free world, but those of us stuck in the US still need to sell software. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | tomw@netscape.com transcending structure. -- The Tao of Programming | Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA18716 for ietf-open-pgp-bks; Mon, 29 Dec 1997 21:40:34 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA18712 for ; Mon, 29 Dec 1997 21:40:30 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA02277 for ; Mon, 29 Dec 1997 21:43:21 -0800 (PST) Received: from netscape.com ([206.222.233.75]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA21058; Mon, 29 Dec 1997 21:43:21 -0800 Message-ID: <34A889F9.5D1F2BD6@netscape.com> Date: Mon, 29 Dec 1997 21:43:21 -0800 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 5.0b1 [en] (X11; I; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: ietf-tls@consensus.com CC: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: <34t3tb6px.fsf@kmac.terisa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk EKR wrote: > > I see several problems here: > 1. While overloading the cipherSuites mechanism is convenient and > backwards compatible, it strikes me as ill-advised. In the limit, > we end up with a large number of cipherSuites that differ only > in the types of certificational material they provide. This > fragments effort. Here you call out an RSA/3DES/RIPEMD mode. > If that's a good idea, wouldn't it be a good idea with X.509 > certificates as well? > > Algorithm choice is largely orthogonal to certificate format and > should be represented as such. That does seem to be a missing > capability in TLS. We should add it rather than hacking around > it. Agreed. Rather than overloading cipherSuites with information about cert formats, I think it would be better to extend TLS to provide for cert format negotiation. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | tomw@netscape.com transcending structure. -- The Tao of Programming | Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA05413 for ietf-open-pgp-bks; Sun, 28 Dec 1997 22:07:03 -0800 (PST) Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id WAA05409 for ; Sun, 28 Dec 1997 22:06:58 -0800 (PST) Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id WAA03538; Sun, 28 Dec 1997 22:10:11 -0800 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma003530; Sun, 28 Dec 97 22:10:02 -0800 Received: from kmac.daisy (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id WAA04256; Sun, 28 Dec 1997 22:10:10 -0800 (PST) Received: by kmac.daisy (4.1/SMI-4.1) id AA01619; Sun, 28 Dec 97 22:11:52 PST To: Cc: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: From: EKR Date: 28 Dec 1997 22:11:51 -0800 In-Reply-To: Will Price's message of Sun, 28 Dec 1997 15:20:14 -0800 Message-Id: <3pvmgk7a0.fsf@kmac.terisa.com> Lines: 160 X-Mailer: Gnus v5.4.37/XEmacs 19.15 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Will Price writes: > At 11:36 AM -0800 12/28/97, Eric Rescorla wrote: > >1. While overloading the cipherSuites mechanism is convenient and > >backwards compatible, it strikes me as ill-advised. In the limit, > >we end up with a large number of cipherSuites that differ only > >in the types of certificational material they provide. This > >fragments effort. > > I agree, certificate type negotiation is an unfortunate missing piece from > TLS. However, according to Section 7.4.2 of the TLS spec and previous > discussion on the TLS list, overloading ciphersuites appears to be the > recommended way to introduce a new certificate type. Hmm.. What it says is: All certificate profiles, key and cryptographic formats are defined by the IETF PKIX working group [PKIX]. When a key usage extension is present, the digitalSignature bit must be set for the key to be eligible for signing, as described above, and the keyEncipherment bit must be present to allow encryption, as described above. The keyAgreement bit must be set on Diffie-Hellman certificates. As CipherSuites which specify new key exchange methods are specified for the TLS Protocol, they will imply certificate format and the required encoded keying information. So, reading this literally, since OpenPGP isn't a PKIX work item, what you suggest is impermissible. (I don't really suggest reading this literally. I'm merely trying to make the point that TLS doesn't appear to have any provision whatsoever for new certificate formats, except what is required for new algorithms.) > Fortunately, the > ciphersuite field is 16 bits, so it doesn't seem that any valuable space is > being wasted. Space isn't the issue, really. It's protocol maintainance and reuse that's at issue. Nevertheless, I'd be wary of assuming that we have an infinitude of cipherSuite space. We only do if we don't waste it. > The alternative seems to be to include another subpacket in the Hello > packets negotiating certificate type just like compression is negotiated. > This would also be allowed by the spec as per 7.4.1.2. If it was to be > done that way, I felt that this negotiation should have been included in > the TLS spec. Since I assume the time for that has passed, I opted for the > ciphersuite overload. I'd suggest this as a TLS 2.0 wor k item, myself. > >Here you call out an RSA/3DES/RIPEMD mode. If that's a good idea, > >wouldn't it be > >a good idea with X.509 certificates as well? > > Yes, it would. Unfortunately once again, I assume the time to add such > things has passed. I felt it was important to have more than one hash > algorithm associated with the OpenPGP certificates, but didn't want to use > a potentially weak algorithm like MD5 (except where the TLS protocol > requires MD5). Were the TLS spec to ignore compatibility, I'm sure MD5 > would be eliminated, so I didn't want to add it to any new ciphersuites. > RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP. HMAC-MD5 is not known to be weak. And remarkably little is known about RIPEMD-160. I'm not really that confident it's better than MD5. > >2. The Certificate payload design doesn't seem to allow for > >a chain of certificates to be carried. This seems like a bug. > > > >3. Omitting the DistinguishedName field in the CertificateRequest > >field seems problematic. I understand PGP doesn't use DNs, > >but there should be a way to indicate who might be potential signers > >of a given key. > > These are both issues of certification of the received key. The OpenPGP > trust model works differently than the win or lose X.509 model where it is > essentially assumed that all clients have all root CA certificates and > those certificates are implicitly trusted. In the OpenPGP model, there is > generally no chain and if there is it could be multiple chains. In > practice, I suspect most implementations will in fact possess OpenPGP CA > keys and it will work much the same way. In this model however, a > certificate chain isn't used. OpenPGP keys generally have all the certs > they need attached to them whereas X509 certs are only a single cert unto > themselves thus requiring a chain if the specified cert is not directly > certified by a root CA. With OpenPGP, if a particular signer key is not > found, the client or server can use a certserver to look it up. One > motivation in the document is also to reduce the overhead of the key > exchange. A key need not even be sent by sending the key ID instead. On > the first connection, this may incur some overhead if the the key is not > found because the certserver may need to be accessed. On future > connections (even when the sessions are not cached), this will be a > substantial benefit. > > This method also introduces to TLS some of the flexibility afforded by SSH > where first connections could be assumed valid and future connections must > use the same keys. Again, this is an implementation dependent issue. Let's take these two separately: 2. I'm pretty familiar with the OpenPGP certification model. What I'm not that famaliar with is the OpenPGP certificate format. The purpose of the exercise here is for the public keyholder to provice enough certificates to enable the public key user to verify his certificate. If PGP keys can have enough certificates attached to them to provide this, then we don't have a problem. A quick glance at the OpenPGP spec didn't make this clear, however. In any case, this isn't an implementation issue if we don't provide the facilities to make it possible. As for cert servers, TLS with X.509 works perfectly well without The Directory. (good thing too, since The Directory doesn't exist). TLS with OpenPGP certificates should work equally well. 3. You haven't addressed the DN in certificate request issue. I don't see that the OpenPGP cert structure has much relevance here. Am I missing something. > >4. In addition, I don't see what the point of prohibiting > >"Export" ciphers with PGP keys is. Obviously, if you're explicitly > >calling out cipherSuites, you can simply omit all the export cipher > >suites from that list, but frankly, stating that "Export" algorithms > >also may not be used with OpenPGP keys" seems silly. It's not our > >place as protocol designers to tell people what they may use. > > The export sections of TLS seem to me to be a holdover from the SSL legacy > days and are there mostly for compatability. I completely disagree. The fact of the matter is that people who ship TLS products often have to export them. In order to do so, they need to use exportable ciphers. That's why SSL had them and it's why TLS has them. > OpenPGP pays no attention to > this issue as it isn't appropriate to have such limits in an international > standard. They aren't limits. They're options. > Clearly, an implementation could choose to implement their own > ciphersuites for export algorithms with OpenPGP keys, but there doesn't > seem to be any reason to specify those as none of the export quality > algorithms are supported by OpenPGP. You're failing to distinguish here between OpenPGP the messaging format and OpenPGP the certification system. What you're trying to do here is use OpenPGP certification with TLS protocol. What crypto algorithms OpenPGP messaging supports really doesn't have any relevance to this. > Simply removing the statement does > seem appropriate however making them implicitly excluded rather than > explicitly. Right. The correct behavior is to specify them. > >5. Also, you've failed to call out support for the integrity only > >cipherSuites. Is this intentional? > > Not intentional. That is an oversight. I'd observe that this is the precise problem with having the certification structure bound up in the cipherSuite. Keeping X.509 cipherSuites matched with OpenPGP cipherSuites is going to be quite difficult. -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA03001 for ietf-open-pgp-bks; Sun, 28 Dec 1997 15:16:51 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA02996 for ; Sun, 28 Dec 1997 15:16:46 -0800 (PST) Received: from [205.180.137.244] (atropos.pgp.com [205.180.137.244]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id PAA29473; Sun, 28 Dec 1997 15:20:01 -0800 (PST) X-Sender: wprice@205.180.136.16 Message-Id: In-Reply-To: <34t3tb6px.fsf@kmac.terisa.com> References: Will Price's message of Sun, 28 Dec 1997 03:00:26 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Dec 1997 15:20:14 -0800 To: From: Will Price Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:36 AM -0800 12/28/97, Eric Rescorla wrote: >1. While overloading the cipherSuites mechanism is convenient and >backwards compatible, it strikes me as ill-advised. In the limit, >we end up with a large number of cipherSuites that differ only >in the types of certificational material they provide. This >fragments effort. I agree, certificate type negotiation is an unfortunate missing piece from TLS. However, according to Section 7.4.2 of the TLS spec and previous discussion on the TLS list, overloading ciphersuites appears to be the recommended way to introduce a new certificate type. Fortunately, the ciphersuite field is 16 bits, so it doesn't seem that any valuable space is being wasted. The alternative seems to be to include another subpacket in the Hello packets negotiating certificate type just like compression is negotiated. This would also be allowed by the spec as per 7.4.1.2. If it was to be done that way, I felt that this negotiation should have been included in the TLS spec. Since I assume the time for that has passed, I opted for the ciphersuite overload. >Here you call out an RSA/3DES/RIPEMD mode. If that's a good idea, >wouldn't it be >a good idea with X.509 certificates as well? Yes, it would. Unfortunately once again, I assume the time to add such things has passed. I felt it was important to have more than one hash algorithm associated with the OpenPGP certificates, but didn't want to use a potentially weak algorithm like MD5 (except where the TLS protocol requires MD5). Were the TLS spec to ignore compatibility, I'm sure MD5 would be eliminated, so I didn't want to add it to any new ciphersuites. RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP. >Algorithm choice is largely orthogonal to certificate format and >should be represented as such. That does seem to be a missing >capability in TLS. We should add it rather than hacking around >it. Bravo. >2. The Certificate payload design doesn't seem to allow for >a chain of certificates to be carried. This seems like a bug. > >3. Omitting the DistinguishedName field in the CertificateRequest >field seems problematic. I understand PGP doesn't use DNs, >but there should be a way to indicate who might be potential signers >of a given key. These are both issues of certification of the received key. The OpenPGP trust model works differently than the win or lose X.509 model where it is essentially assumed that all clients have all root CA certificates and those certificates are implicitly trusted. In the OpenPGP model, there is generally no chain and if there is it could be multiple chains. In practice, I suspect most implementations will in fact possess OpenPGP CA keys and it will work much the same way. In this model however, a certificate chain isn't used. OpenPGP keys generally have all the certs they need attached to them whereas X509 certs are only a single cert unto themselves thus requiring a chain if the specified cert is not directly certified by a root CA. With OpenPGP, if a particular signer key is not found, the client or server can use a certserver to look it up. One motivation in the document is also to reduce the overhead of the key exchange. A key need not even be sent by sending the key ID instead. On the first connection, this may incur some overhead if the the key is not found because the certserver may need to be accessed. On future connections (even when the sessions are not cached), this will be a substantial benefit. This method also introduces to TLS some of the flexibility afforded by SSH where first connections could be assumed valid and future connections must use the same keys. Again, this is an implementation dependent issue. >4. In addition, I don't see what the point of prohibiting >"Export" ciphers with PGP keys is. Obviously, if you're explicitly >calling out cipherSuites, you can simply omit all the export cipher >suites from that list, but frankly, stating that "Export" algorithms >also may not be used with OpenPGP keys" seems silly. It's not our >place as protocol designers to tell people what they may use. The export sections of TLS seem to me to be a holdover from the SSL legacy days and are there mostly for compatability. OpenPGP pays no attention to this issue as it isn't appropriate to have such limits in an international standard. Clearly, an implementation could choose to implement their own ciphersuites for export algorithms with OpenPGP keys, but there doesn't seem to be any reason to specify those as none of the export quality algorithms are supported by OpenPGP. Simply removing the statement does seem appropriate however making them implicitly excluded rather than explicitly. >5. Also, you've failed to call out support for the integrity only >cipherSuites. Is this intentional? Not intentional. That is an oversight. Thanks. -Will Will Price, Architect Network Associates, Inc. Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Cell/VM (650)533-0399 PGPkey: Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA01125 for ietf-open-pgp-bks; Sun, 28 Dec 1997 11:31:32 -0800 (PST) Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id LAA01121 for ; Sun, 28 Dec 1997 11:31:27 -0800 (PST) Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id LAA27937; Sun, 28 Dec 1997 11:34:41 -0800 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma027935; Sun, 28 Dec 97 11:34:37 -0800 Received: from kmac.daisy (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id LAA02815; Sun, 28 Dec 1997 11:34:45 -0800 (PST) Received: by kmac.daisy (4.1/SMI-4.1) id AA01538; Sun, 28 Dec 97 11:36:27 PST To: Cc: ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP References: From: EKR Date: 28 Dec 1997 11:36:26 -0800 In-Reply-To: Will Price's message of Sun, 28 Dec 1997 03:00:26 -0800 Message-Id: <34t3tb6px.fsf@kmac.terisa.com> Lines: 38 X-Mailer: Gnus v5.4.37/XEmacs 19.15 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I see several problems here: 1. While overloading the cipherSuites mechanism is convenient and backwards compatible, it strikes me as ill-advised. In the limit, we end up with a large number of cipherSuites that differ only in the types of certificational material they provide. This fragments effort. Here you call out an RSA/3DES/RIPEMD mode. If that's a good idea, wouldn't it be a good idea with X.509 certificates as well? Algorithm choice is largely orthogonal to certificate format and should be represented as such. That does seem to be a missing capability in TLS. We should add it rather than hacking around it. 2. The Certificate payload design doesn't seem to allow for a chain of certificates to be carried. This seems like a bug. 3. Omitting the DistinguishedName field in the CertificateRequest field seems problematic. I understand PGP doesn't use DNs, but there should be a way to indicate who might be potential signers of a given key. 4. In addition, I don't see what the point of prohibiting "Export" ciphers with PGP keys is. Obviously, if you're explicitly calling out cipherSuites, you can simply omit all the export cipher suites from that list, but frankly, stating that "Export" algorithms also may not be used with OpenPGP keys" seems silly. It's not our place as protocol designers to tell people what they may use. 5. Also, you've failed to call out support for the integrity only cipherSuites. Is this intentional? -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA26330 for ietf-open-pgp-bks; Sun, 28 Dec 1997 02:57:07 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA26326 for ; Sun, 28 Dec 1997 02:57:03 -0800 (PST) Received: from [205.180.137.244] (atropos.pgp.com [205.180.137.244]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id DAA23921; Sun, 28 Dec 1997 03:00:14 -0800 (PST) X-Sender: wprice@205.180.136.16 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Dec 1997 03:00:26 -0800 To: ietf-tls@consensus.com, ietf-open-pgp@imc.org From: Will Price Subject: Proposed Extensions to TLS for OpenPGP Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is an early draft of a document I'm working on. Since it applies to both ietf-openpgp and ietf-tls, I'm sending it to both. My intent is to make this a separate document not integrated into either of the main documents from the two groups. Comments welcome. -------------------- Draft Proposed Extensions to TLS for OpenPGP keys Will Price Network Associates, Inc. December 28, 1997 Abstract This document builds upon the TLS Protocol Specification, currently an IETF Internet Draft. The extensions described herein are intended to apply to the latest draft of the IETF TLS 1.0 protocol dated November 12, 1997. The purpose of this document is to update the TLS protocol with extensions to support the certificates, public key algorithms, symmetric ciphers, hash algorithms, and trust model used by OpenPGP. This document uses the same notation used in the TLS Protocol draft. Certificate The X.509.v3 [X509] certificates recommended for use with TLS will not be used in conjunction with OpenPGP keys. An implementation should be able to support both TLS with X509 and TLS with OpenPGP keys. It is not required that an implementation support both. The "peer certificate" in the session state of TLS can refer to either X509 or OpenPGP. The contents of the Certificate (11) message sent from server to client and vice versa are determined by the Cipher Suite. Many new Cipher Suites are defined in the Cipher Suites section of this document for use with OpenPGP keys. All OpenPGP Cipher Suites require a OpenPGP key in the Certificate messages. A OpenPGP key appearing in the Certificate message will be sent in binary OpenPGP format. The Certificate message includes a OpenPGP key where the X509 certificate would normally appear. The option is also available to send a 64 bit OpenPGP Key ID instead of sending the entire key. The client will respond with a fatal alert no_certificate if the Key ID cannot be found. If the key is not valid, expired, revoked, or corrupt, the appropriate fatal alert message is sent from section A.3 of the TLS specification. If a key is valid and neither expired nor revoked, it is accepted by the protocol. A particular OpenPGP compatible TLS implementation may wish to allow users to designate certain keys specifically as Trusted Server Keys. This is a local matter outside the scope of this document. enum { keyid (0), key (1), (255) } PGPKeyDescriptorType; opaque PGPKeyID<8> opaque PGPKey<1..2^24-1> struct { PGPKeyDescriptorType descriptorType; select (descriptorType) { case keyid: PGPKeyID; case key: PGPKey; } } Certificate; Certificate Request The server is allowed to request a client certificate from the client. The meaning of this message is essentially unchanged to allow OpenPGP keys. The rsa_sign and dss_sign certificate types may be requested in conjunction with OpenPGP keys. The ClientCertificateType field is used identically to the TLS specification. The subsequent DistinguishedName field is not included when using Cipher Suites based on OpenPGP keys. The Client Certificate message is sent using the same formatting as the server Certificate message in response to the Certificate Request message. If no OpenPGP key is available from the client, the no_certificate alert is returned. The server may then respond with a fatal alert if appropriate. This transaction follows the TLS specification. Server Key Exchange When using ephemeral Diffie-Hellman, the Server Key Exchange message is sent to pass the Diffie-Hellman public value to the client. The client and server then use this value to establish the shared secret. This is identical to the operation of standard TLS. Certificate Verify The Certificate Verify message for OpenPGP key types is identical to the specification. The signature is made using either DSS or RSA depending on the Cipher Suite. Finished The Finished message for OpenPGP key types is identical to the description in the specification. Cipher Suites Since TLS does not have a certificate type field, the Cipher Suites field is used to perform the same function. A number of additional Cipher Suites are defined for use with OpenPGP keys. CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_SHA = { 0x01, 0x01 }; CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_SHA = { 0x01, 0x02 }; CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x01, 0x03 }; CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_RMD = { 0x01, 0x04 }; CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_RMD = { 0x01, 0x05 }; CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x01, 0x06 }; CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_SHA = { 0x01, 0x20 }; CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_SHA = { 0x01, 0x21 }; CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_SHA = { 0x01, 0x22 }; CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_RMD = { 0x01, 0x23 }; CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_RMD = { 0x01, 0x24 }; CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_RMD = { 0x01, 0x25 }; Note: The above numeric definitions for Cipher Suites have not yet been registered. All of the above Cipher Suites use either the CAST, IDEA, or TripleDES block ciphers in CBC mode. The choice of hash is either SHA-1 or RIPEMD-160. Use of any of these Cipher Suites requires an OpenPGP key in any Certificate and Client Certificate messages. MD5 may not be used with OpenPGP keys. "Export" algorithms also may not be used with OpenPGP keys. To be considered complaint with support for OpenPGP in TLS, an implementation must support TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Will Price, Architect Network Associates, Inc. Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Cell/VM (650)533-0399 PGPkey: Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA22439 for ietf-open-pgp-bks; Sat, 20 Dec 1997 06:50:18 -0800 (PST) Received: from mail.the-wire.com (mail.the-wire.com [198.53.192.5]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA22434 for ; Sat, 20 Dec 1997 06:50:03 -0800 (PST) Received: from [205.206.36.71] (rguerra.the-wire.com [205.206.36.71]) by mail.the-wire.com (8.8.8/8.8.8) with ESMTP id JAA20392; Sat, 20 Dec 1997 09:51:14 -0500 (EST) X-Sender: rguerra@mail.the-wire.com Message-Id: Mime-Version: 1.0 X-PGP-RSAkey: http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0x89619BC5 X-PGP-DSSkey: http://keys.pgp.com:11371/pks/lookup?op=index&search=0x4B408E7B Date: Sat, 20 Dec 1997 09:40:34 -0500 To: pgp-users@joshua.rivertown.net, ietf-open-pgp@imc.org From: Robert Guerra Subject: G10: The Free PGP Replacement Cc: Macintosh Cryptography Mailing List , werner.koch@guug.de Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Transfer-Encoding: quoted-printable I haven't seen this announced here before, and thought it might interest peo= ple (if someone ports it to the Macintosh, please let me know :) ) http://www.d.shuttle.de/isil/g10.html G10 The Free PGP Replacement Overview I recently started a project to replace PGP by a free utility. PGP is not free software in the sense of freedom as defined by the GPL; so I decided to write a replacement. Goals GPLed Full replacement of PGP Does not use any patented algorithms. Using ElGamal, Blowfish and RIPE-MD-160 as algorithms. Hooks to add a RSA module, so that non U.S. users are able to reuse there signed keys. RSA will be completely back on Sep 20th, 2000. Better functionality, including some security enhancements. Can be used as a filter. Support for Unix, GNU, OS/2, MSDOS, Windoze, NT. Uses the PGP packet format as described in RFC1991 with some enhancements. New algorithms are easy to implement. More infos The primary FTP site for G10 is ftp.guug.de. But note, that there is no code available yet; I will put up a first ALPHA version before christmas. You can subscribe to the mailing list g10@net.lut.ac.uk by sending a mail with the word "subscribe" in the body to g10-request@net-lut.ac.uk. An archive of the list is also available here. A related project is psst..., a free ssh/sshd replacement. Status Done: create signatures and detached signatures. checking signatures (data and keys). encrypt and decrypt (public key and conventional). List and check keyrings Print fingerprints Self signatures are added to generated keys. RSA and ElGamal Key generation. Ripe-MD-160 used for hashing. Works inside a pipe w/o any temporary files. autoconf/configure works. using armor files works. compressing stuff implemented. Some enhancements to make it somewhat compatible with the OpenPGP draft. Added SHA-1. Added configuration stuff (options file) Not yet done: Trust packets. Keyring management (partly done) Old style signatures Documentation. DSA, subkeys etc. and, and, and .... Updated: 18.12.97 Merry christmas, and Happy New Year. Joyeux No=EBl et Bonne Anne. Feliz navidad y prospero a=F1o nuevo. Robert Guerra - PGP public key available on PGP key servers Email-> mailto:az096@freenet.toronto.on.ca Home Page-> http://www.geocities.com/CapitolHill/3378 -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5 Comment: Digital signatures are used to verify authorship and content iQA/AwUBNJvbx4PIpEZLQI57EQJtGQCfT6fmwJZ72gt4s1fcx5z8xB812DgAn2uu t2+8agiOW+nij2xYdookEKIP =yuBv -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA21310 for ietf-open-pgp-bks; Thu, 18 Dec 1997 10:11:17 -0800 (PST) Received: from smtp3.erols.com (smtp3.erols.com [205.252.116.103]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA21303 for ; Thu, 18 Dec 1997 10:11:10 -0800 (PST) Received: from ankneyr.btec.com (spg-tnt7s78.erols.com [207.172.37.78]) by smtp3.erols.com (8.8.8/8.8.5) with ESMTP id NAA17098; Thu, 18 Dec 1997 13:07:58 -0500 (EST) Message-Id: <199712181807.NAA17098@smtp3.erols.com> From: "Rich Ankney" To: "Myron Lewis" , Cc: , , "Dan Lewis Randall" Subject: Re: Improving resistance against attacks Date: Thu, 18 Dec 1997 13:13:22 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Nice thinking, Patrick, but why go to all that trouble when there is a key > generator that continually generates unpredictable keys of any size as often > as you want and synchronizes them across a link without transmitting any > info about them. It's called the ASK ToolKit(tm). See www.keygen.com > Well, perhaps we're going to all this trouble because (a) ASK doesn't do digital signatures, (b) it doesn't accommodate an Email environment where there is no connection between sender and recipient, and (c) it requires maintaining pairwise keys and state between each sender/recipient pair, rather than just exchanging public keys. (The above comments based on checking out your web page a few weeks ago.) Regards, Rich Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA18399 for ietf-open-pgp-bks; Thu, 18 Dec 1997 08:04:16 -0800 (PST) Received: from aw.ableweb.com (www.ableweb.com [209.113.153.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA18391 for ; Thu, 18 Dec 1997 08:04:09 -0800 (PST) Received: from TIAC.tiac.net (mrlewis.tiac.net [206.119.12.211]) by aw.ableweb.com (Netscape Mail Server v2.01) with SMTP id AAA11231; Thu, 18 Dec 1997 11:07:47 -0400 From: "Myron Lewis" To: Cc: , , "Dan Lewis Randall" Subject: Re: Improving resistance against attacks Date: Thu, 18 Dec 1997 11:06:42 -0500 Message-ID: <01bd0bcf$0867d440$d30c77ce@TIAC.tiac.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Nice thinking, Patrick, but why go to all that trouble when there is a key generator that continually generates unpredictable keys of any size as often as you want and synchronizes them across a link without transmitting any info about them. It's called the ASK ToolKit(tm). See www.keygen.com Regards, Myron Lewis, President, KeyGen Corporation. 781-860-0108 -----Original Message----- From: Robert Hettinga To: espam@intertrader.com Date: Wednesday, December 17, 1997 9:14 AM Subject: Improving resistance against attacks >--------------------------------------------------------------------- >This mail is brought to you by the e$pam mailing list >--------------------------------------------------------------------- > >From: Patrick Feisthammel >Reply-To: Patrick Feisthammel >To: ietf-open-pgp@imc.org >cc: Patrick Feisthammel >Subject: Improving resistance against attacks >MIME-Version: 1.0 >Sender: owner-ietf-open-pgp@imc.org >Precedence: bulk > >-----BEGIN PGP SIGNED MESSAGE----- > > Hi! > > After the thread about weak RSA keys in sci.crypt, I tought about > improving the security against attacks on the public keys. > > My propoal in short: Use multiple keys at the same time. > > > Why using multiple keys at the same time > ======================================== > If a key is generated, there is a probability p, that there is a 'fast' > algorithm to factorize this key. For two keys, the probability, that > both are 'easy' to break is p^2. And therefore much smaler. > > > How it works > ============ > To encrypt some data d with two keys K1 and K2: > 1. Create a one time pad o (random data) of the same length as d. > 2. Encrypt the data d with o: c1= E(d, o) > 3. Encrypt the result from step 2 with the key K1: c2= E(c1, K1) > 4. Encrypt the one time pad with key K2: c3= E(o, K2) > 5. The encrypted data is the concatenation of c2 and c3. > > To decrypt: > 1. Decrypt c3 with K2: o= D(c3, K2) > 2. Decrypt c2 with K1: c1= D(c2, K1) > 3. Decrypt the data: d= D(c1, o) > > If key K1 is broken, only c2 can be decrypted. Because without the one > time pad o, the knowledge about the data is still zerol > If key K2 is broken, the one time pad is known, but this also does not > give any information about the data d. > > Some thougths have to be done for multiple recipients, that two broken > keys of different recipients don't reveal the cleartext. > > > Communication with PGP 2.6.x and PGP 5.x > ======================================== > The usage of two keys can easaly be added to the today version with > one key: > - Add the information about the key id of the second key in the > public key, as non critical information. > - pgp-2keys checks if the receipient has a one-key public key. If he > has, the old encryption/signing is used. If not, the new system is > used. > Users of pgp-1key will always encrypt/sign with only one key, which is the > today used scheme. pgp-2key users can communicate with the schema > proposed in this mail. > This way it is fully compatible with todys versions. (Or at least as > compatible as today versions) > > > 2 keys or m keys > ================ > Of course, this system can easaly be extended to the more general case > of m keys. The keys could even be from other key algorithms. > > > What do you think? Would this be a suitable way to reduce the risk > given by the usage of one signle key? > Could this be an idea for later versions of OpenPGP? > > > Cheers, Patrick > > > > > > > - -- > PGP-KeyID: DD934139 (pafei@rubin.ch) encrypt mail with PGP if possible > more about PGP on http://www.rubin.ch/pgp/ (in german only at the moment) > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3i > Charset: noconv > > iQESAwUBNJeAe5VgYabdk0E5AQFLvgfkCKj+9dmpQMAYBxyKRKUnNpMIVvbIqOIB > Cn/ja5vUy+Z9NPX8dBKkiqlTS2vbJV88awtnjGE761M0983kLiX8gzdzMUQoC8bM > CJobaGHK9J1UjOzzJdCtxGbBYkqjVAU8UQec8d1d787u1MRcpjZg/AwOvcGLFLYs > wXhWA89/wur9487Jc/wxx2gtf+rphgdQcLrSTxmx25LISwJG4jLPvINbWbk+YC7W > jqB2vwHx0ZmEyyPOHsMpIqQ+Y9s1B2Mm9ckft9jcRbmG/w0MJezr58A8SWnbJHxl > A3yAXCYivlwinfk6LyNBulh5YiV7N/rVPtj+mwRNgp5FsgPrZg== > =8pFP > -----END PGP SIGNATURE----- > > >---------------------------------------------------------------------- >Where people, networks and money come together: Consult Hyperion >http://www.hyperion.co.uk/ info@hyperion.co.uk >---------------------------------------------------------------------- >Full-Strength Cryptographic Solutions for Worldwide Electronic Commerce >http://www.c2.net/ stronghold@c2.net >---------------------------------------------------------------------- >Like e$? Help pay for it! >For e$/e$pam contributions or sponsorship: >---------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA04212 for ietf-open-pgp-bks; Wed, 17 Dec 1997 23:49:58 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA04208 for ; Wed, 17 Dec 1997 23:49:54 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id IAA26032; Thu, 18 Dec 1997 08:52:29 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Where is the symmetric algorithm defined? Date: 18 Dec 1997 07:52:29 GMT Organization: IKS GmbH Jena Lines: 5 Message-ID: References: <199712171921.LAA09987@s20.term1.sb.rain.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Hal Finney wrote: >Do you mean, in a public key encrypted message, where is it specified what >conventional (symmetric) algorithm is used to encrypt the message itself? Thnx I really stupid. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA25981 for ietf-open-pgp-bks; Wed, 17 Dec 1997 11:35:02 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA25974 for ; Wed, 17 Dec 1997 11:34:58 -0800 (PST) Received: from s20.term1.sb.rain.org (s20.term1.sb.rain.org [198.68.144.150]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id LAA20590; Wed, 17 Dec 1997 11:36:11 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id LAA09987; Wed, 17 Dec 1997 11:21:42 -0800 Date: Wed, 17 Dec 1997 11:21:42 -0800 From: Hal Finney Message-Id: <199712171921.LAA09987@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, lutz@taranis.iks-jena.de Subject: Re: Where is the symmetric algorithm defined? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lutz Donnerhacke, lutz@taranis.iks-jena.de, writes: > Where is the symmetric algorithm of an encrypted messages defined in the > OpenPGP message format? Do you mean, in a public key encrypted message, where is it specified what conventional (symmetric) algorithm is used to encrypt the message itself? This is in section 5.1: > The encrypted value "m" in the above formulas is derived from the > session key as follows. First the session key is prepended with a > one-octet algorithm identifier that specifies the conventional > encryption algorithm used to encrypt the following Symmetrically > Encrypted Data Packet. This one-octet algorithm identifier is what tells the symmetric algorithm that is used to encrypt the body of the message. It is only visible once the ESK packet has been decrypted. Third parties can't tell what algorithm was used to encrypt the message. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA21441 for ietf-open-pgp-bks; Wed, 17 Dec 1997 08:12:29 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA21437 for ; Wed, 17 Dec 1997 08:12:21 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id RAA02517; Wed, 17 Dec 1997 17:14:34 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Where is the symmetric algorithm defined? Date: 17 Dec 1997 16:14:33 GMT Organization: IKS GmbH Jena Lines: 3 Message-ID: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I'm stupid... Where is the symmetric algorithm of an encrypted messages defined in the OpenPGP message format? Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA11566 for ietf-open-pgp-bks; Tue, 16 Dec 1997 23:32:39 -0800 (PST) Received: from dns.cyberlink.ch (root@dns.cyberlink.ch [193.246.253.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA11562 for ; Tue, 16 Dec 1997 23:32:34 -0800 (PST) Received: from dns.rubin.ch (root@gwrubin.cyberlink.ch [193.246.253.129]) by dns.cyberlink.ch (8.8.4/8.8.4) with ESMTP id IAA10899; Wed, 17 Dec 1997 08:34:51 +0100 Received: from dns.rubin.ch (pafei@dns.rubin.ch [193.246.253.130]) by dns.rubin.ch (8.8.5/8.8.5) with SMTP id IAA11176; Wed, 17 Dec 1997 08:34:20 +0100 Date: Wed, 17 Dec 1997 08:34:15 +0100 (CET) From: Patrick Feisthammel Reply-To: Patrick Feisthammel To: ietf-open-pgp@imc.org cc: Patrick Feisthammel Subject: Improving resistance against attacks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi! After the thread about weak RSA keys in sci.crypt, I tought about improving the security against attacks on the public keys. My propoal in short: Use multiple keys at the same time. Why using multiple keys at the same time ======================================== If a key is generated, there is a probability p, that there is a 'fast' algorithm to factorize this key. For two keys, the probability, that both are 'easy' to break is p^2. And therefore much smaler. How it works ============ To encrypt some data d with two keys K1 and K2: 1. Create a one time pad o (random data) of the same length as d. 2. Encrypt the data d with o: c1= E(d, o) 3. Encrypt the result from step 2 with the key K1: c2= E(c1, K1) 4. Encrypt the one time pad with key K2: c3= E(o, K2) 5. The encrypted data is the concatenation of c2 and c3. To decrypt: 1. Decrypt c3 with K2: o= D(c3, K2) 2. Decrypt c2 with K1: c1= D(c2, K1) 3. Decrypt the data: d= D(c1, o) If key K1 is broken, only c2 can be decrypted. Because without the one time pad o, the knowledge about the data is still zerol If key K2 is broken, the one time pad is known, but this also does not give any information about the data d. Some thougths have to be done for multiple recipients, that two broken keys of different recipients don't reveal the cleartext. Communication with PGP 2.6.x and PGP 5.x ======================================== The usage of two keys can easaly be added to the today version with one key: - Add the information about the key id of the second key in the public key, as non critical information. - pgp-2keys checks if the receipient has a one-key public key. If he has, the old encryption/signing is used. If not, the new system is used. Users of pgp-1key will always encrypt/sign with only one key, which is the today used scheme. pgp-2key users can communicate with the schema proposed in this mail. This way it is fully compatible with todys versions. (Or at least as compatible as today versions) 2 keys or m keys ================ Of course, this system can easaly be extended to the more general case of m keys. The keys could even be from other key algorithms. What do you think? Would this be a suitable way to reduce the risk given by the usage of one signle key? Could this be an idea for later versions of OpenPGP? Cheers, Patrick - -- PGP-KeyID: DD934139 (pafei@rubin.ch) encrypt mail with PGP if possible more about PGP on http://www.rubin.ch/pgp/ (in german only at the moment) -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQESAwUBNJeAe5VgYabdk0E5AQFLvgfkCKj+9dmpQMAYBxyKRKUnNpMIVvbIqOIB Cn/ja5vUy+Z9NPX8dBKkiqlTS2vbJV88awtnjGE761M0983kLiX8gzdzMUQoC8bM CJobaGHK9J1UjOzzJdCtxGbBYkqjVAU8UQec8d1d787u1MRcpjZg/AwOvcGLFLYs wXhWA89/wur9487Jc/wxx2gtf+rphgdQcLrSTxmx25LISwJG4jLPvINbWbk+YC7W jqB2vwHx0ZmEyyPOHsMpIqQ+Y9s1B2Mm9ckft9jcRbmG/w0MJezr58A8SWnbJHxl A3yAXCYivlwinfk6LyNBulh5YiV7N/rVPtj+mwRNgp5FsgPrZg== =8pFP -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA27156 for ietf-open-pgp-bks; Sun, 14 Dec 1997 16:23:43 -0800 (PST) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA27151 for ; Sun, 14 Dec 1997 16:23:38 -0800 (PST) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id SAA01720; Sun, 14 Dec 1997 18:24:58 -0600 (CST) Received: from pax-ca12-07.ix.netcom.com(204.30.66.199) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma020174; Sun Dec 14 17:27:34 1997 Message-Id: <3.0.3.32.19971214152658.0074ae88@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 14 Dec 1997 15:26:58 -0800 To: ietf-open-pgp@imc.org, remailer-operators@anon.lcs.mit.edu From: Bill Stewart Subject: Re: Possible attack on remailer keys? In-Reply-To: <19971209.141823.13167.5.goddesshera@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:07 PM 12/09/1997 MDT, Anonymous Remailer wrote, to the remailer-operators list: >I just discovered a disturbing fact. I'm not sure how it works with other >remailers, but Juno remailers (and I think Winsock too) shell to PGP, >supplying the key passphrase to decrypt messages. This in itself is fine >(ugly, but it works), but it happens to be that a person can guess the >key passphrase by sending the remailer a CONVENTIONALLY encrypted message >(with the probable passphrase). > >PGP doesn't seem to care if the key phrase applies to a secret key, or to >the message password if conventionally encrypted. The message will pass >as normal, thus proving the passphrase is correct. While this is using PGP 2.6.x, it's still a problem for future versions (though perhaps this belongs in pgp-bugs rather than ietf-open-pgp.) The obvious workaround is to use a good passphrase (:-), but there really is a need to tell PGP what key a given passphrase is for. The PGPPASS was always a somewhat risky feature (passing sensitive information to a program you don't control is inherently risky, and at least in Unix, the environment variables are often visible as well), but it's something you need to be able to use to build non-interactive environments. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA24424 for ietf-open-pgp-bks; Sun, 14 Dec 1997 10:53:46 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA24419 for ; Sun, 14 Dec 1997 10:53:40 -0800 (PST) Received: from users.invweb.net (cppp39.dotstar.net [208.143.93.139]) by users.invweb.net (8.8.7/8.8.7) with SMTP id NAA21249; Sun, 14 Dec 1997 13:54:55 -0500 Message-Id: <199712141854.NAA21249@users.invweb.net> From: "William H. Geiger III" Date: Sun, 14 Dec 97 12:29:08 -0600 To: Rodney Thayer In-Reply-To: <3.0.3.32.19971212090510.03869c14@pop.pn.com> Cc: ietf-open-pgp@imc.org Subject: Re: PGP 5 (i, source) question... X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.3.32.19971212090510.03869c14@pop.pn.com>, on 12/12/97 at 09:05 AM, Rodney Thayer said: >Could someone suggest an appropriate forum in which to ask questions >about the PGP 5 code that was scanned in 'offshore'? >I assume it's not appropriate to ask someone from N.A. about this... Hi Rodney, You may wish to as over in the pgp-dev@pgpi.com mailing list. Has been a little slow but there are a group of people there who have worked with the 5.0i code. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNJQrV49Co1n+aLhhAQKUewP8Dh8NO2ix9sogvegDiw4ILmfCy+e3LWdl Kz6Huq1u6k3lSKu1+wsNjgYYE/PXL3Jl1SwJHd2ZR8mYS3L2mnTTPUXORXHtdN6w P5tf3qFfB0cR4B29bA9e0BK0RKtYu92Jr/F8fGOP+TIGsrAADXyZfYtmKh+yQwg4 Avvpf5+vVyI= =USGV -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA12311 for ietf-open-pgp-bks; Fri, 12 Dec 1997 10:59:28 -0800 (PST) Received: from geocities.com (mail3.geocities.com [209.1.224.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA12307 for ; Fri, 12 Dec 1997 10:59:20 -0800 (PST) Received: from maksim (tun-ad17.tver.fact400.ru [194.87.239.17]) by geocities.com (8.8.5/8.8.5) with SMTP id LAA21634; Fri, 12 Dec 1997 11:01:20 -0800 (PST) Message-Id: <199712121901.LAA21634@geocities.com> Comments: Authenticated sender is From: "Maksim Otstavnov" Organization: home office To: ietf-open-pgp@imc.org, lutz@taranis.iks-jena.de Date: Fri, 12 Dec 1997 22:09:41 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Handling 8-bit cleartext signatures - a proposal (Was: Re: O Reply-to: maksim@volga.net In-reply-to: <19971212080756.12109@taranis.iks-jena.de> References: <199712112304.PAA28684@geocities.com>; from Maksim Otstavnov on Fri, Dec 12, 1997 at 02:12:24AM +0400 X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --back onlist On Fri, 12 Dec 1997 Lutz Donnerhacke wrote: > > > >PGP/MIME in its current incarnation (RFC2015) _does not_ deal with > > > >clearsigs. > > > > > > I thought, that PGP/MIME does provide a multipart/signed type. > > > > 1. Well, multipart/signed might be called a clearsigning > > but it's a kind of "detached clearsign", that is, one cannot just > > save the whole msg in a file and verify in file mode as a last > > resort. > > I can save it. I save the whole message. ... and then manually insert armor, eh? > > 2. 2015 explicitly _forbids_ producing 8-bit first part in > > multipart/signed. > > RfC 2015 is somewhat badly designed, yes. I talked to Mark and he will fix > those points in the next version. Virtually all mailers handle other types > correctly. Great. > > I believe the general problem is not in that (3a) it is hard to > > maintain certain language environment PGP performance, and even not > > in that (3b) 8-bit texts require codepage info for > > rendering/interpretation, but in that (3c) we deal with ways of > > PGPing "objects" but have kinds of "objects" still undefined. My > > understanding is that implicitly we slill have the two flavors of > > object: "binary streams" and "texts". Texts require some > > environment-specific info. One example currently defined is the way > > EOL is represented on a certain platform. An example currently > > undefined is charset info. > > Correct. But the problem can be solved easily applying the OSI layers > strictly. Armor is Layer 6 as MIME. It has nothing to do with the message > format. It has nothing to do with hash calculation ... Right, armor is OSI Layer 6 issue. It should go to other document, but in such case we would have no armor definition in interim period (after Formats start its standard track and before 2015 successor starts its own). Anyway, direct referencing to OSI Layers definitions (which RFCs?) and indicating the layer(s) involved would enhance the draft. > > 4. Certainly, I would like "charset" to come back. > That means reimplementing MIME functionality in PGP seperatly. Maybe you're right. But still... I'd like to have it as should, for backword compatibility with 2.6i -- -- Maksim Otstavnov http://www.geocities.com/SoHo/Studios/1059/ -- -maintainer of The Russian PGP HomePage -- (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA09119 for ietf-open-pgp-bks; Fri, 12 Dec 1997 06:42:45 -0800 (PST) Received: from virtuoso.rutgers.edu (virtuoso.rutgers.edu [165.230.8.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA09114 for ; Fri, 12 Dec 1997 06:42:40 -0800 (PST) Received: from localhost (mione@localhost) by virtuoso.rutgers.edu (8.8.5/8.6.12) with SMTP id JAA16182; Fri, 12 Dec 1997 09:44:54 -0500 (EST) Date: Fri, 12 Dec 1997 09:44:54 -0500 (EST) From: Tony Mione To: Rodney Thayer cc: ietf-open-pgp@imc.org Subject: Re: PGP 5 (i, source) question... In-Reply-To: <3.0.3.32.19971212090510.03869c14@pop.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk There has been some discussion about 5.0i on pgp-users@joshua.rivertown.net. Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** On Fri, 12 Dec 1997, Rodney Thayer wrote: > Could someone suggest an appropriate forum in which to ask questions about > the PGP 5 code that was scanned in 'offshore'? > I assume it's not appropriate to ask someone from N.A. about this... Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA08636 for ietf-open-pgp-bks; Fri, 12 Dec 1997 06:03:59 -0800 (PST) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA08631 for ; Fri, 12 Dec 1997 06:03:55 -0800 (PST) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.184.129.129]) with SMTP; 12 Dec 1997 14:06:09 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.8.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id JAA14027 for ; Fri, 12 Dec 1997 09:06:08 -0500 (EST) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 12 Dec 1997 14:06:07 UT Received: from ietf40-1-128.dc.ietf.org (stat1-128.dc.ietf.org [166.49.1.128]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id JAA20825 for ; Fri, 12 Dec 1997 09:16:05 -0500 (EST) Message-Id: <3.0.3.32.19971212090510.03869c14@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 12 Dec 1997 09:05:10 -0500 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: PGP 5 (i, source) question... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Could someone suggest an appropriate forum in which to ask questions about the PGP 5 code that was scanned in 'offshore'? I assume it's not appropriate to ask someone from N.A. about this... Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA07244 for ietf-open-pgp-bks; Wed, 10 Dec 1997 12:53:16 -0800 (PST) Received: from geocities.com (mail4.geocities.com [209.1.224.24]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA07240 for ; Wed, 10 Dec 1997 12:53:11 -0800 (PST) Received: from maksim (tun-ad17.tver.fact400.ru [194.87.239.17]) by geocities.com (8.8.5/8.8.5) with SMTP id MAA24672; Wed, 10 Dec 1997 12:54:41 -0800 (PST) Message-Id: <199712102054.MAA24672@geocities.com> Comments: Authenticated sender is From: "Maksim Otstavnov" Organization: home office To: ietf-open-pgp@imc.org, lutz@taranis.iks-jena.de (Lutz Donnerhacke) Date: Thu, 11 Dec 1997 00:02:56 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Handling 8-bit cleartext signatures - a proposal (Was: Re: O Reply-to: maksim@volga.net In-reply-to: X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lutz Donnerhacke wrote: > * Maksim Otstavnov wrote: > >An OP application SHOULD mark an outgoing message produced in > >a way defined hereabove with either the following headers: > > > >% MIME-Version: > >% Content-Type: text/plain; charset= > >% Content-Transfer-Encoding: bit > > Your proposal deals with MIME, but PGP/MIME still solved the problem. PGP/MIME in its current incarnation (RFC2015) _does not_ deal with clearsigs. If MIME is considered for any reason a four-letter word in this draft, the text starting with the words Lutz quoted and up to the end of 2.7.1 section should be excluded from my proposal. -- -- Maksim Otstavnov http://www.geocities.com/SoHo/Studios/1059/ -- -maintainer of The Russian PGP HomePage -- (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA01992 for ietf-open-pgp-bks; Wed, 10 Dec 1997 07:28:29 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA01986 for ; Wed, 10 Dec 1997 07:28:24 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id QAA32122; Wed, 10 Dec 1997 16:30:05 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Handling 8-bit cleartext signatures - a proposal (Was: Re: OP an Date: 10 Dec 1997 15:30:04 GMT Organization: IKS GmbH Jena Lines: 9 Message-ID: References: <199712041814.KAA18032@geocities.com> <199712062010.MAA26891@geocities.com> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Maksim Otstavnov wrote: >An OP application SHOULD mark an outgoing message produced in >a way defined hereabove with either the following headers: > >% MIME-Version: >% Content-Type: text/plain; charset= >% Content-Transfer-Encoding: bit Your proposal deals with MIME, but PGP/MIME still solved the problem. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA22574 for ietf-open-pgp-bks; Wed, 10 Dec 1997 00:47:12 -0800 (PST) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA22568 for ; Wed, 10 Dec 1997 00:47:07 -0800 (PST) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id JAA06745 for ietf-open-pgp@imc.org; Wed, 10 Dec 1997 09:49:12 +0100 (MET) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 19098 invoked from network); 10 Dec 1997 08:37:43 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 10 Dec 1997 08:37:43 -0000 Received: (qmail 258 invoked by uid 501); 10 Dec 1997 08:42:26 -0000 Message-ID: <19971210094226.09931@isil.d.shuttle.de> Date: Wed, 10 Dec 1997 09:42:26 +0100 From: Werner Koch To: Jon Callas Cc: ietf-open-pgp@imc.org, g10@net.lut.ac.uk Subject: Re: DSA and patents References: <19971209202343.55399@isil.d.shuttle.de> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.79 In-Reply-To: ; from Jon Callas on Tue, Dec 09, 1997 at 06:30:50PM -0800 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas writes: > The current draft of OpenPGP allows for Elgamal signatures. It *is* true > that PGP 5.x does not implement them, but the standard allows them. If > there's anything in the draft that forbids them, let me know and I'll > correct it, as I consider that a bug in the spec. It´s okay, we would only have a problem with the MUST DSA requirement if we can´t use DSA due to patent issues - according to Peter Gutmann´s message this will not be the case. By the way: The bit fiddling stuff with the length headers is somewhat annoying: If there is need for partial length headers, the document will anyway be quite large and spending some extra bytes does matter. I hope that can be fixed with next OpenPGP version. Werner -- Werner Koch, Duesseldorf - werner.koch@guug.de - PGP keyID: 0C9857A5 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA19524 for ietf-open-pgp-bks; Tue, 9 Dec 1997 19:53:46 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA19520 for ; Tue, 9 Dec 1997 19:53:43 -0800 (PST) Received: from [38.232.7.6] (mg-20425421-93.ricochet.net [204.254.21.93]) by fusebox.pgp.com (8.8.7/8.8.5) with ESMTP id TAA13878; Tue, 9 Dec 1997 19:55:34 -0800 (PST) X-Sender: jon@mail.pgp.com Message-Id: In-Reply-To: <19971209202343.55399@isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Dec 1997 18:30:50 -0800 To: Werner Koch , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: DSA and patents Cc: g10@net.lut.ac.uk Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:23 AM -0800 12/9/97, Werner Koch said: Another issue with the OpenPGP draft is, that it requires DSA signatures and has no provisions for plain ElGamal signatures. If it=B4s true, that DSA may infringe on some patents, can ElGamal signatures be made an optio= n for OpenPGP and DSA be a SHOULD and not a MUST? The current draft of OpenPGP allows for Elgamal signatures. It *is* true that PGP 5.x does not implement them, but the standard allows them. If there's anything in the draft that forbids them, let me know and I'll correct it, as I consider that a bug in the spec. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA14476 for ietf-open-pgp-bks; Tue, 9 Dec 1997 12:20:37 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA14471 for ; Tue, 9 Dec 1997 12:20:31 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id JAA06739; Wed, 10 Dec 1997 09:22:30 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88169894927902>; Wed, 10 Dec 1997 09:22:29 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: wk@isil.d.shuttle.de Subject: Re: DSA and patents Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Wed, 10 Dec 1997 09:22:29 (NZDT) Message-ID: <88169894927902@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >2. The Schnorr patent (4,995,082): In a letter to the NIST Schnorr > claimed that the DSA infringes his patent. FIPS 186 (about DSS) > states that "The Department of Commerce is not aware of any patents > that would be infringed by this standard". I also heard, that the > government will help if someone is sued on patent infringement while > working on a project implementing DSS for governmental purposes. The Schnorr patent is a so-called "scarecrow patent" which only applies to a very restricted set of smart-card based applications. A number of lawyers from companies big enough to care about possible lawsuits have examined it and decided that any claims against typical software implementations are baseless. >Another issue with the OpenPGP draft is, that it requires DSA signatures >and has no provisions for plain ElGamal signatures. If itM-4s true, that >DSA may infringe on some patents, can ElGamal signatures be made an option >for OpenPGP and DSA be a SHOULD and not a MUST? There are various issues with Elgamal signatures, the main one is that the keys PGP 5 currently generates with g=2 makes the signatures forgeable using an attack which Daniel Bleichenbacher described at EuroCrypt'96. You'd need to modify the PGP keygen to avoid this. There's a draft RFC draft-rfced-info-gutmann-elgamal-00.txt which covers this and other issues. >From the draft: >3. Security considerations > >Although the use of the Elgamal algorithm for digital signature >generation is not directly addressed in this document, it should be >pointed out that some care needs to be taken with both the choice of >keys and the use of the algorithm. Details on the safe use of Elgamal >are given in [4]. A weakness of Elgamal when used for digital >signatures, and workarounds to avoid the weakness, are given in [5]. > >Ongoing research into the security of Elgamal may reveal other factors >which need to be taken into account to provide adequate security for >signature and encryption applications, for example it is desirable that >g generate a large subgroup of Zp*; it is recommended that implementors >keep abreast of current research on the choice of parameters and use of >the algorithm in order to avoid potential security weaknesses. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA13801 for ietf-open-pgp-bks; Tue, 9 Dec 1997 11:25:10 -0800 (PST) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA13797 for ; Tue, 9 Dec 1997 11:25:01 -0800 (PST) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id UAA22522 for ietf-open-pgp@imc.org; Tue, 9 Dec 1997 20:27:03 +0100 (MET) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 18345 invoked from network); 9 Dec 1997 19:27:10 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Dec 1997 19:27:10 -0000 Received: (qmail 2980 invoked by uid 501); 9 Dec 1997 19:23:43 -0000 Message-ID: <19971209202343.55399@isil.d.shuttle.de> Date: Tue, 9 Dec 1997 20:23:43 +0100 From: Werner Koch To: ietf-open-pgp@imc.org Cc: g10@net.lut.ac.uk Subject: DSA and patents Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.79 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Richard Stallman asked me to clarify the status of possible patent conflicts on DSA. I know of these two points: 1. There is a a patent of Kravitz (5,231,668) assigned to "The United States of America as ...". The NIST said, that they will make this patent world-wide available on a royalty-free basis. 2. The Schnorr patent (4,995,082): In a letter to the NIST Schnorr claimed that the DSA infringes his patent. FIPS 186 (about DSS) states that "The Department of Commerce is not aware of any patents that would be infringed by this standard". I also heard, that the government will help if someone is sued on patent infringement while working on a project implementing DSS for governmental purposes. If anyone here has more information, can [s]he be so kind and comment on this? Another issue with the OpenPGP draft is, that it requires DSA signatures and has no provisions for plain ElGamal signatures. If it´s true, that DSA may infringe on some patents, can ElGamal signatures be made an option for OpenPGP and DSA be a SHOULD and not a MUST? -- Werner Koch, Duesseldorf - werner.koch@guug.de - PGP keyID: 0C9857A5 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA24976 for ietf-open-pgp-bks; Mon, 8 Dec 1997 15:47:09 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA24972 for ; Mon, 8 Dec 1997 15:47:03 -0800 (PST) Message-Id: <199712082347.PAA24972@mail.proper.com> Received: (qmail 9670 invoked from network); 8 Dec 1997 23:49:02 -0000 Received: from ts5112.powerup.com.au (HELO lindsay) (202.139.237.12) by enterprise.powerup.com.au with SMTP; 8 Dec 1997 23:49:02 -0000 Date: 9 Dec 1997 0:38:43 GMT From: Lindsay Mathieson Subject: Re: co-chair resigns To: Charles Breed , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk We'll miss your chairing Charles - its been good. I hope we continue to see you on the list ? Cheers - Linz -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on December 9, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA23031 for ietf-open-pgp-bks; Mon, 8 Dec 1997 14:32:16 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA23009 for ; Mon, 8 Dec 1997 14:32:06 -0800 (PST) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id OAA23436 for ; Mon, 8 Dec 1997 14:34:07 -0800 (PST) Message-Id: <3.0.2.32.19971208143846.00cb3210@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 08 Dec 1997 14:38:46 -0800 To: ietf-open-pgp@imc.org From: Charles Breed Subject: co-chair resigns Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To all OpenPGP list members, I'm resigning as co-chair of the IETF OpenPGP working group, John Noerenberg at Qualcomm will be the one and only chairperson. My employment has been terminated as part of the Network Associates buy-out, and it's critical that the OpenPGP specification gets done and adopted by many without having to pay ANYTHING to Network Associates. Open, Free, Unencumbered, no royalties will make the spec successful with lots of independent implementations. I'll be working for Interlink / NetLock on IPsec starting Jan. '98 Cheers, Charles Breed -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQA/AwUBNIx29mHp4fWkSVeLEQLtvACfYnLJr/8WT6YV1G08ngtQQPu+RLQAn3SW NhzmTr0oxO09sCxNIjGf6z+v =J7It -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA19342 for ietf-open-pgp-bks; Mon, 8 Dec 1997 10:28:01 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA19338 for ; Mon, 8 Dec 1997 10:27:57 -0800 (PST) Received: by brickwall.ceddec.com id <43010>; Mon, 8 Dec 1997 13:29:56 -0500 Date: Mon, 8 Dec 1997 13:31:00 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars.ceddec.com To: ietf-open-pgp@imc.org Subject: Re: Discrete log signature key sizes In-Reply-To: <199712041344.FAA09543@s20.term1.sb.rain.org> Message-Id: <97Dec8.132956est.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 4 Dec 1997, Hal Finney wrote: > Anybody have a good way to synthesize a 320 bit hash out of a 160 bit one? > I found a paper which suggested doing a "butterfly" using 8 instances of > the smaller hash which looked pretty good (Eurocrypt 96, Aiello). > > Hal What about concatenating SHA1 and RIPEMD160 hashes? Or are they too related so that it would be significantly less than the square of the cost of finding either? What about the second hash being over the message and the first hash? Also, if a 320 bit hash was available, how would you modify DSS to allow for that, simply change Q to a 320 bit number? --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA16652 for ietf-open-pgp-bks; Mon, 8 Dec 1997 07:10:42 -0800 (PST) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA16647 for ; Mon, 8 Dec 1997 07:10:37 -0800 (PST) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.86.127.224]) with SMTP; 8 Dec 1997 15:12:37 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.8.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id KAA07402 for ; Mon, 8 Dec 1997 10:15:16 -0500 (EST) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 8 Dec 1997 15:12:34 UT Received: from testbed ([166.49.1.128]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id KAA28480 for ; Mon, 8 Dec 1997 10:20:48 -0500 (EST) Message-Id: <3.0.3.32.19971207164534.038d466c@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 07 Dec 1997 16:45:34 -0500 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: r.e. code fragments in the documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Has the BXA ruled on itef drafts? Snuffle is smaller than many code >fragments, but (barring a further ruling) still cannot be posted on the >internet. I have lots of concise working examples of how PGP does things, >from my implementations, but will we run into the "crypto is a munition" >problem if the draft contains the wrong type of example? In IETF land it is ok to put code fragments in drafts. It is strongly recommended they fall across page boundries so that it's clearly a technical paper. See the RC5 RFC by Rivest for an example, it's basically code with a light topping of page footers. This is a technical/academic paper in a public forum, I believe, so that's why it's ok. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA14318 for ietf-open-pgp-bks; Mon, 8 Dec 1997 04:09:26 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA14314 for ; Mon, 8 Dec 1997 04:09:22 -0800 (PST) Received: from [129.46.54.92] (ra4000-p12.qualcomm.com [129.46.54.92]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id EAA24752 for ; Mon, 8 Dec 1997 04:10:47 -0800 (PST) X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <199712030514.AAA13775@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0b46-1.98] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Sun, 7 Dec 1997 21:46:49 -0500 To: ietf-open-pgp@imc.org From: "John W. Noerenberg" Subject: Agenda for Monday's WG meeting Sender: owner-ietf-open-pgp@imc.org Precedence: bulk So you all have some idea how I plan to order the meeting tomorrow, here's how I'll break it down: 1 Outline meeting John N (5 min) 2 WG goals John N (10 min) restate the charter 3 Phil Zimmerman -- Design philosophy of PGP (10 min) 4 2015 status -- Dave Del Torto (20 min) 5 format draft status -- Jon Callas (45 min) 6 revise charter to add Trust Model doc (15 min) 7 any other new business (15 min) The Trust Model is something we talked about in the early days of organizing the WG, and I've lately been thinking it would be worthwhile bringing it back into our scope. Mike Elkins was unable to attend the meeting, so Dave Del Torto has graciously stepped in to conduct the discussion on 2015. The heart of the meeting is the format draft discussion. There has been a lot of discussion over the last 2 weeks. I expect the meeting will help us bring closure to some of these discussions. The results of the live(ly) discussion will be posted as soon as possible. I'll be looking for a volunteer to keep notes during the discussion for the benefit of those who won't be at the meeting. john w noerenberg, ii jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com ----------------- --------------------------- ---------------------- "The great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." -- Ralph Waldo Emerson, "Self Reliance", 1841 ----------------- --------------------------- ---------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA10571 for ietf-open-pgp-bks; Mon, 8 Dec 1997 01:02:31 -0800 (PST) Received: from lsf008.gateway.com (gate4.gateway.com [208.215.59.158]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA10556; Mon, 8 Dec 1997 01:02:16 -0800 (PST) From: 6vc8eqq93@m1Im.net Received: by lsf008.gateway.com; id CAA07961; Mon, 8 Dec 1997 02:55:38 -0600 (CST) Received: from sdn-ts-001fljackp01.dialsprint.net(206.133.84.20) by lsf008.gateway.com via smap (V3.1) id xmala7273; Mon, 8 Dec 97 02:55:10 -0600 DATE: 07 Dec 97 4:02:02 AM Message-ID: TO: ads@4uonthe.net SUBJECT: We bulk Email for You Sender: owner-ietf-open-pgp@imc.org Precedence: bulk LET US DO YOUR BULK MAILINGS!!! ...$350 PER MILLION ADDRESSES SENT ...$250 PER 1/2 MILLION ADDRESSES SENT THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. DON'T BE LEFT IN THE DUST OF YOUR COMPETORS, ADVERTISE TODAY!!! Addresses are extracted daily by 6 of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. Estimated 60-80,000 addresses extracted daily. They are fresh! Over 40 million addresses on file. More computers with cable modems are being added due to increasing responses. All ads can not be more than 2 pages (50 lines) and 68 characters wide. More than 50 lines, there will be an additional charge of $50 per page or 25 lines or less. No porn, no foul language or sex relative material will be sent. ->->->->->->->-> TARGETED MAILINGS <-<-<-<-<-<-<-<- ->-> $150 per 50,000 addresses extracted or less ->-> This price includes mailing of material ->-> Allow 3-7 days for extracting of addresses ->-> Mailings to US only (general addresses) $500 per 500,000 ->-> Many targeted list on file ->-> Purchased target list $150 per 50,000 or less If you have your own list, we will email your list for $200 per 500,000 or less. All list must be in text format and each address must be on individual lines. ***Mailings are done all at once, not broken down into multiple mailings.*** Addrsses are processed against our remove list of those individuals who have asked to be elimated from any of our mailings. All mailings are de-duped for duplicates. No .mil, .gov or .edu included. There are no lower prices on the net. Your mailing can be done in a matter of hours. Turn around time for mailings range from 3 to 5 days. This time varies according to the demand of mailings. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST (English only). If the line is busy or no repsonse, please keep trying, as bulk mailing is growing fast and we are busy responding to those who are interested in advertsing on the internet. We DO want to work with you to advertise your product/service. No collect calls. Our computers are working 24 hours a day to better serve YOU! To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA07513 for ietf-open-pgp-bks; Sun, 7 Dec 1997 18:18:50 -0800 (PST) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA07509 for ; Sun, 7 Dec 1997 18:18:45 -0800 (PST) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id UAA21244; Sun, 7 Dec 1997 20:16:33 -0600 (CST) Received: from pax-ca5-17.ix.netcom.com(199.35.217.177) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma021231; Sun Dec 7 20:16:29 1997 Message-Id: <3.0.3.32.19971207181613.02f65430@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 07 Dec 1997 18:16:13 -0800 To: Ian Grigg From: Bill Stewart Subject: Re: Speculative Mode for KeyIDs of all zeroes Cc: ietf-open-pgp@imc.org In-Reply-To: <3489208C.773C2448@systemics.com> References: <3.0.3.32.19971204021239.006ea164@schloss.li> <3.0.3.32.19971204133500.00754cb8@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:53 AM 12/06/1997 +0000, Ian Grigg wrote: >Hmmm. True, a very good point, a test would be needed. Maybe it should >only be supported in text mode ('t' flag on?), or maybe there should be >a magic number within. If it was only in test mode, then binaries could >be done by armouring (or whatever) inside. Binary's fine, if the Symmetrically Encrypted Data Packets contains a Compressed Data Packet or Literal Data Packet or Signature Packet or OnePass Signature Packet or other recognizable PGP form. >> Another option is to only check the "default" key, >> though default key really an artifact of the user interface >> rather than something OPGP needs to know about. >Another problem is that most PGP implementations will treat the keys on >the rings in a simple fashion, so the first implementations of the >Zeroes feature are likely to ask the user for *all* the keys in >succession ... . Boring, eh? But most people don't have too many secret keys, so it isn't really that much slower, and you can skip any keys that aren't the right length to match the encrypted session key. (E.g. if the ESK is 1024 bits long, you can skip that 2047-bit signature-only key and your 512-bit regular-use key. It's probably a good idea for people who are this paranoid to use standard length keys, probably 1024, since that 1984-bit key is somewhat of a giveaway.) >I wouldn't even make it SHOULD as it will be quite difficult to get >right, from the comments above. MAY is fine by me. Agreed, especially since you can do it with wrappers and not need to trouble the OPGP implementation directly. MAY accept KeyID 0, and MAY generate KeyID 0 instead of a real key, and if you send a KeyID 0 to somebody who you don't know has it, you should expect to lose. I suppose Notation Subpackets aren't a bad place to indicate that you support KeyID 0. >As a side-effect, would we add "An implementation SHOULD treat KeyID of >all zeroes as a reserved and/or bad key?" What is the source and >semantics of a KeyID of zero? Presumably it must happen as keyservers >are worried about clashes, so should a key that generates with this be >considered a bad key? The probability of a generating a key with KeyID of 0 is 2**-64. It could happen by accident, though it probably won't, and worst case is the lucky user of such a key will just have to check all messages sent to him that have KeyID 0 against all his keys. Annoying, but no loss of functionality. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA06505 for ietf-open-pgp-bks; Sun, 7 Dec 1997 15:50:36 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA06500 for ; Sun, 7 Dec 1997 15:50:31 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id MAA14363 for ; Mon, 8 Dec 1997 12:52:25 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88153874400957>; Mon, 8 Dec 1997 12:52:24 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-open-pgp@imc.org Subject: PGP Inc. cleans off the KRAP Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Mon, 8 Dec 1997 12:52:24 (NZDT) Message-ID: <88153874400957@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Just appeared on PGP Inc's home page: "Network Associates Withdraw from Key Recovery Alliance". Cool. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA25170 for ietf-open-pgp-bks; Sat, 6 Dec 1997 14:32:56 -0800 (PST) Received: from www.talweb.com (mail.talweb.com [199.44.243.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA25141 for ; Sat, 6 Dec 1997 14:32:44 -0800 (PST) From: H1CAK5mNb@m1Im.net Received: from 976DH2D7U (unverified [206.133.65.63]) by www.talweb.com (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 06 Dec 1997 17:20:25 -0500 DATE: 05 Dec 97 5:25:06 PM Message-ID: TO: lasers@44optic.com SUBJECT: Lasers/Optics/Optical Tables - Save! Sender: owner-ietf-open-pgp@imc.org Precedence: bulk MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK@WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA24197 for ietf-open-pgp-bks; Sat, 6 Dec 1997 12:08:59 -0800 (PST) Received: from geocities.com (mail2.geocities.com [209.1.224.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA24193 for ; Sat, 6 Dec 1997 12:08:55 -0800 (PST) Received: from maksim (tun-ad13.tver.fact400.ru [194.87.239.13]) by geocities.com (8.8.5/8.8.5) with SMTP id MAA26891; Sat, 6 Dec 1997 12:10:29 -0800 (PST) Message-Id: <199712062010.MAA26891@geocities.com> Comments: Authenticated sender is From: "Maksim Otstavnov" Organization: home office To: Jon Callas Date: Sat, 6 Dec 1997 23:12:39 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Handling 8-bit cleartext signatures - a proposal (Was: Re: OP an Reply-to: maksim@volga.net CC: IETF OpenPGP In-reply-to: <3.0.3.32.19971204105728.00ae3530@mail.pgp.com> References: <199712041814.KAA18032@geocities.com> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 04 Dec 1997 10:57:28 -0800 Jon Callas wrote: > At 09:22 PM 12/4/97 +0400, Maksim Otstavnov wrote: > >>Besides, it has nothing to do with PGP/MIME. PGP/MIME is a separate >>question currentely not discussed by this WG according to its >>agenda. (right?). > > No, PGP/MIME (a.k.a. OP-MIME, or RFC 2015) is covered by this working group. > >>The OP is to obsolete rfc1991, not 2015, right? Ascii-armor is >>currently defined in 1991, not 2015. So I just wish OP rfc to contain >>both a concept of "8-bit text" and definition of actions order for >>plugins/glues producing _non-PGP/MIME_ messages. Just so little ;) > > This working group has two things under its charter (presently) -- the > OP-FORMAT document and RFC 2015. So each are relevant, we just have two > documents. ...But a new PGP(OP?)/MIME is not scheduled yet... Handling clearsigs _does_ belong to OP draft domain currently and all ambiguities imho should be fixed before it starts on its standard track. I apologize if a subject of my previous postings was ambiguos. The exact problem I face is that pgp 5.0i users in Russian environment suffer a set of complications derived (I believe) from the fact that 8-bit text clearsigning is performed differently in different cases. For example, I apply a procedure (recommended by PGP 5.0 manual) for clearsingning msg to be sent with an _unsupported_ MUA (eg MS Internet Mail). The MUA operates in a Windows native codepage (so called "Windows-cp1251") and PGP produces a clearsign of this codepage rendering of the plaintext. Then I send a message. Before sending, the message (mime, 8-bit, plaintext) is usually converted to cross-platform standard, KOI8-R (RFC 1489, officially registered with RFC 1700, also registered by the POSIX WG15 character set collection, the latest Registered Charsets List from IANA and by IBM as CP878) either as 8-bit or printed-quotable. If a receiving MUA isn't Win-based, the message normally never returns to the native Win cp, so signature can't be verified. Furthermore, a _supported_ plugin developer currently not bound (nor even advised) by any document to a particular _order_ of performing both conversion and PGP-clearsigning a single message. So, it may happen that a message clearsigned with one plugin won't be verified by an other one, even on _the same_ platform. (I don't know for sure how current 5.0 MUA plugins (I am aware of the four - Eudora, MS Exchange/Outlook, Mail'97, and QDPGP 1.60 for Pegasus for 32-bit Windows) handle the two operations of a single message). In recent days I've been trying to figure how OP would fix the problem. The following proposals are the result (I browsed through the entire archive of the OP list and found no proposals which would contradict these; pls advise me if I'm wrong). I am not overall happy with them, for clipboard clearsigning remains a problem, but it would at least make all OP-compliant applications ("supported MUAs") intercompatible over 8-bit clearsigned texts. Suggestions? Comments? - -----cut here----- >2.6 Cleartext signature framework > >Sometimes it is necessary to sign a textual octet stream Proposal: , consisting either of 7-bit or 8-bit textual octets, >without ASCII >armoring the stream itself, so the signed text is still readable >without special software. In order to bind a signature to such a >cleartext, this framework is used. (Note that RFC 2015 defines >another way to clear sign messages for environments that support >MIME.) Proposal: 2.7 Handling 8-bit cleartext signatures Sometimes it is desirable to perform cleartext signature over a 8-bit textual octet stream. In certain environments performing of other, not defined in this document, conversion ("Non-OP conversion") of a 8-bit textual octet stream is also required (e.g. for handling non-English messages in a cross-platform environment). If an OP application allows handling 8-bit textual octet stream it MUST apply cleartext signature and perform a non-OP conversion of a single 8-bit textual octet stream in the following way. 2.7.1 Producing 8-bit cleartext signature - - perform non-OP conversion of the original textual octet stream (producing either 8-bit or 7-bit output) required by a specific environment; then - - apply cleartext signature framework (defined in 2.6 of this document) over the product of such conversion. The product of the two consequential procedures described hereabove is either 8-bit or 7-bit textual octet stream, depending on specific environment requirements. An OP application SHOULD mark an outgoing message produced in a way defined hereabove with either the following headers: % MIME-Version: % Content-Type: text/plain; charset= % Content-Transfer-Encoding: bit or the following headers: % MIME-Version: % Content-Type: text/printed-quotable; charset= % Content-Transfer-Encoding: 7bit where - - is a version of MIME supported by the OP application; - - is a registered charset corresponding with the semantics of the output of the non-OP conversion applied; - - is either "8" or "7" depending on the octet width of non-OP conversion. 2.7.2 Verifying 8-bit cleartext signature - - verify cleartext signature; then - - perform non-OP conversion of the message in accordance with its "MIME-Version", "Content-Type", and "Content-Transfer-Encoding" headers values. - -----cat there----- -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQCVAwUBNImG1XGCEHWOiJDhAQGlPAP/b7sSbSgVS27cQzpZ7D4OJ+voYWil64Hi iSdrMqYrLdDj1si8i0VGsCOR0YX09KA4tbmV4lDzDYuqeoJB6kRrlL47cCwT2Oyv pVOAy3xX1yNtk95Gbp8FUkYEIfSMFZhgq2LZhkThjgKO/UuHffyVD8ujQTRZCZWy wATyQDWu4WE= =oO86 -----END PGP SIGNATURE----- -- -- Maksim Otstavnov http://www.geocities.com/SoHo/Studios/1059/ -- -maintainer of The Russian PGP HomePage -- (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html) -- -moderator of "Security&Privacy" (Russian language) Web-forum -- (http://www.rocit.ru/forum) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA27494 for ietf-open-pgp-bks; Sat, 6 Dec 1997 01:50:35 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA27490 for ; Sat, 6 Dec 1997 01:50:31 -0800 (PST) Received: from hayek.guvnet (noddy [192.168.1.5]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id MAA02764; Sat, 6 Dec 1997 12:20:16 +0100 (MET) Message-ID: <3489208C.773C2448@systemics.com> Date: Sat, 06 Dec 1997 09:53:16 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: stewarts@ix.netcom.com CC: ietf-open-pgp@imc.org Subject: Re: Speculative Mode for KeyIDs of all zeroes References: <3.0.3.32.19971204021239.006ea164@schloss.li> <3.0.3.32.19971204133500.00754cb8@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk stewarts@ix.netcom.com wrote: (stego stuff cut, this is too much for V1 IMHO) > On the other hand, if OPGP does support the 0s mode, > it'll have to successively try each secret key it has > until it either finds one that works or finds that > none of them work; an alternative is to have an external > preprocessor program that drives it, by trying each KeyID in succession. > This requires that the driver know what KeyIDs are available > (either reading directly from the keyring or > just from a list), and that the OPGP implementation > have some easily-parsed response that lets the driver > decide whether or not the decryption worked. Hmmm. True, a very good point, a test would be needed. Maybe it should only be supported in text mode ('t' flag on?), or maybe there should be a magic number within. If it was only in test mode, then binaries could be done by armouring (or whatever) inside. > Another option is to only check the "default" key, > though default key really an artifact of the user interface > rather than something OPGP needs to know about. Another problem is that most PGP implementations will treat the keys on the rings in a simple fashion, so the first implementations of the Zeroes feature are likely to ask the user for *all* the keys in succession ... . > Internal support is more efficient, but non-critical, > so I'd recommend against making it a MUST, but it'd be > nice to have it as a SHOULD. I doubt it could be a MUST as it is not used anywhere yet, and it is too adventurous of us to mandate anything that is not yet in use. I wouldn't even make it SHOULD as it will be quite difficult to get right, from the comments above. MAY is fine by me. As a side-effect, would we add "An implementation SHOULD treat KeyID of all zeroes as a reserved and/or bad key?" What is the source and semantics of a KeyID of zero? Presumably it must happen as keyservers are worried about clashes, so should a key that generates with this be considered a bad key? -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA19635 for ietf-open-pgp-bks; Fri, 5 Dec 1997 10:57:28 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA19631 for ; Fri, 5 Dec 1997 10:57:25 -0800 (PST) Received: from s20.term1.sb.rain.org (s27.term1.sb.rain.org [198.68.144.157]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id LAA08290 for ; Fri, 5 Dec 1997 11:00:53 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA00513 for ietf-open-pgp@imc.org; Fri, 5 Dec 1997 10:44:14 -0800 Date: Fri, 5 Dec 1997 10:44:14 -0800 From: Hal Finney Message-Id: <199712051844.KAA00513@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Comments on draft - Long. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Peter Gutmann, pgut001@cs.auckland.ac.nz, writes: > To get around this, you could use Elgamal for signatures (although the current > PGP doesn't support this, the code is commented out). One word of caution for those who may be tempted to un-comment the ElGamal signature code in the 5.0 source: there is a security flaw as written. The problem is not in the signatures per se but in the key generation. ElGamal signatures require some care in the choice of the generator. We use a generator of 2 for ElGamal encryption, which is safe for that purpose, but is not safe for ElGamal signatures. So before enabling ElGamal signatures, they must change the keygen code. (I don't know of any reason to use ElGamal signatures in place of DSS signatures though.) Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA18620 for ietf-open-pgp-bks; Fri, 5 Dec 1997 10:02:03 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA18613 for ; Fri, 5 Dec 1997 10:01:59 -0800 (PST) Received: from hayek.guvnet (noddy [192.168.1.5]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id UAA29944; Fri, 5 Dec 1997 20:31:42 +0100 (MET) Message-ID: <34884241.13728473@systemics.com> Date: Fri, 05 Dec 1997 18:04:49 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: US participation in International Standards (was: Re: Complexity...) References: <97Dec5.121526est.43009@brickwall.ceddec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk nospam-seesignature@ceddec.com wrote: > Has the BXA ruled on itef drafts? I believe that there is an exemption on Americans being permitted to participate on standards committees of an international nature. If anybody knows the precise wording of the exemption, I'd be interested to see. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA17809 for ietf-open-pgp-bks; Fri, 5 Dec 1997 09:13:44 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA17805 for ; Fri, 5 Dec 1997 09:13:40 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 5 Dec 1997 12:15:26 -0500 Date: Fri, 5 Dec 1997 12:16:47 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars.ceddec.com To: Ian Grigg cc: Hal Finney , ietf-open-pgp@imc.org Subject: Re: Complexity not a dominant strategy for independant deployment In-Reply-To: <347A7F9F.3D12DFA1@systemics.com> Message-Id: <97Dec5.121526est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 25 Nov 1997, Ian Grigg wrote: > Hal Finney wrote: > > > Maybe a more constructive approach is to ask whether the description > > in the new draft is clear and useful. The draft is lengthy, yes, > > but not very much of it is occupied discussing packet length headers, > > and perhaps that portion could be made more concise. We could include > > some code samples if this is an area where people are afraid of the > > implementation difficulty. > > Adding code fragments is a good idea. Code does not lie where text can > not help but spread mistruths. > > Psuedo code or C or even Java would be very useful. We may even be able > to make this easier by adopting the convention that comments on the > draft, within this mailgroup, include code fragments to explain their > points, as Adam did earlier. Then, the editors can simply cut and past. Has the BXA ruled on itef drafts? Snuffle is smaller than many code fragments, but (barring a further ruling) still cannot be posted on the internet. I have lots of concise working examples of how PGP does things, from my implementations, but will we run into the "crypto is a munition" problem if the draft contains the wrong type of example? --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA17710 for ietf-open-pgp-bks; Fri, 5 Dec 1997 09:08:09 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA17701 for ; Fri, 5 Dec 1997 09:08:04 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 5 Dec 1997 12:09:48 -0500 Date: Fri, 5 Dec 1997 12:11:15 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars.ceddec.com To: ietf-open-pgp@imc.org Subject: Re: Complexity not a dominant strategy for independant deployment In-Reply-To: <199711250629.WAA27455@s20.term1.sb.rain.org> Message-Id: <97Dec5.120948est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 25 Nov 1997, Hal Finney wrote: > Ian Grigg, , writes: > > It never occurred to me until right now - probably because I have > > cauterised that part of my brain - but it would be a big win for future > > generations if we can add an alternate CFB method that is straight down > > the line, and start deprecating the existing method. > > We will need to make some alterations when it is time to support ciphers > with block sizes larger than 64 bits. There is language in the draft > which would allow us to fix it at that time. The current wording is: ... > Notice "resynchronized if the cipher block size is 8 octets or less". > This means the resync will go away for larger block ciphers. However now > I realize that the 8+2 header will not be right for such ciphers, either. > Probably we should replace the "8" with the block size of the cipher. > Any other suggestions on how to revise this? > > (Note that the purpose of the two redundant bytes is to tell if you have > the right key for decryption.) Either way, however lock in either a fixed 8, or fixed "Cipher Block Size" early. Right now I have 8 hardcoded, but all three existing algorithms use 8 byte blocks. Also quickly define a >8 byte block size cipher with number and implement something so interoperability can be easily checked. ... > I considered another way of documenting the resynchronization of the > CFB mode. It can be described pretty cleanly as follows: Encrypt the > first 8 bytes in CFB-64 mode, the next two bytes in CFB-16 mode, and > the remainder of the message in CFB-64. I managed to get totally confused by the CFB stuff, but managed to hack something that worked for 2.6.x starting with idea_cfb64_encrypt(buf1, buf2, 10...) (from SSLeay - yes, 10 bytes), and after verifying the last two byte pairs are identical, I reset the iv counter and load the ivec with the original first 8 bytes, and then just use idea_cfb64_encrypt normally. It is much easier to just do than to explain. I had to create my own generic cfb, which was fairly simple, and cfbreset routines for PGP 5.0 since it applied the cfb function over multiple algorithms. Cfbreset should be just: void cfbreset() { memmove(&cfbivec[8 - ivleft], cfbivec, ivleft); memcpy(cfbivec, &lastiv[ivleft], 8 - ivleft); /* lastiv is the iv previous to the current image */ ivleft = 0; } Replace 8 with cipherblocksize if/when that is changed. Also note that if the only reset occurs at the beginning, and the initial iv is all zeros, simply copying the original cipherblocksize bytes into the iv is sufficient. This is currently true of how cfbreset is used in the existing PGP implementations. The worst problem I have is that various libraries have different data types (sizes), so the iv data must be converted from/to the 8 byte cfb vector to/from the 32bit words or whatever in a portable way. So although there is not an "endian" assumption per se, when DES and IDEA use 32 bit entities, I have to insure that the char[4] aligns properly. This isn't a problem if there is an internal X_cfb64_encrypt call in the lib for all conventional algorithms I want to implement. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA14116 for ietf-open-pgp-bks; Fri, 5 Dec 1997 05:48:51 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA14112 for ; Fri, 5 Dec 1997 05:48:47 -0800 (PST) Received: from hayek.guvnet (noddy [192.168.1.5]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id QAA28453; Fri, 5 Dec 1997 16:18:09 +0100 (MET) Message-ID: <348806D5.1CFBAE39@systemics.com> Date: Fri, 05 Dec 1997 13:51:17 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: Jon Callas CC: Hironobu Suzuki , ietf-open-pgp@imc.org Subject: Re: new algorithm identifier of the symmetric cryptosystem. References: <3.0.3.32.19971204140456.00a68340@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas wrote: > Few years later, someone will hack AES (Advanced Encryption Standard) > into PGP. I think several people will hack it at the same time. Who > does allocate/control id number of AES? > > You're correct, it makes sense to reserve a constant for the AES now. Thank > you for the suggestion. Actually, the AES will be chosen from a group of 5 submitted algorithms. As all of those algorithms are likely to be independantly hacked in before the winner is chosen, they will all need numbers, and it is likely that we can simply use the winning number as a continuation if it has been deployed. However, in the event that NIST asks for any changes in the algorithm, it would be a wise precaustion to reserve the extra number for the eventual AES as well. Numbers are cheap, reservations are not. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA07513 for ietf-open-pgp-bks; Fri, 5 Dec 1997 00:18:15 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA07509 for ; Fri, 5 Dec 1997 00:18:09 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id JAA10633; Fri, 5 Dec 1997 09:19:48 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: More draft comments Date: 5 Dec 1997 08:19:48 GMT Organization: IKS GmbH Jena Lines: 52 Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Tony Mione wrote: [Signatures] > Why is the keyID needed? It should be present in the actual >signature packet at the end of the message (in an Issuer ID subpacket >within the actual signature packet). Isn't this a waste of space? Also, No. The additional package nac provide more bits of the fingerprint (aka key ID) that the fixed size field. But this is truly optional. >what if you are setting up one pass signing for multiple keys? Do you need >multiple one pass signature packets if all of the other information is the >same (pk algorithm, sig type, hash alg, etc)? No, only for the hashes. [Secret key] > Why are p and q saved? My understanding was that these are not >needed should be thrown away after the keypair is generated. If the secret >key exponent is saved in addition to the public exponent, then there is no >need for these pieces of data. Or am I totally missing something? There are several shortcuts in modular arithmetics which requires p, q, and some modular inverses. > How about a new packet type for all certificates. Internally, it >can included a certificate type (PGP Classic = 1, OpenPGP = 2, X.509 = 3, >SPKI = 4, etc.) followed by certificate-specific contents (ASN.1 crud >for X.509, s-expression for SPKI, etc). You like to introduce an other layer. But OpenPGP defines only the PGP layer not a framework on top of such layers. > In each case, exactly what material is the key signing? The >signature packet says which subpackets are included in the signed material, >however, what parts of the preceding packets are hashed and signed: > > - The entire public key packet followed by the entire user-id packet? > - The MPIs from the pk packet + user-id data? > - only the actual key material from the pk packet + the user-id data? Quote from my proposal: 13 - Key certification, positive ID. Heavy-duty identification efforts, photo ID, direct contact with personal friend, etc. Material signed is public key pkt and User ID pkt. MUST be supported. > Ok, now I'm confused. How does this relate to the public key >packet? If this is not a packet, but rather a stored structure, then why is >it in a document on Message Formats? Im confused, too. My major problem is, that the current draft status is unavailable. I do not know what's edited and what's not. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA06197 for ietf-open-pgp-bks; Thu, 4 Dec 1997 22:11:12 -0800 (PST) Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA06192 for ; Thu, 4 Dec 1997 22:11:07 -0800 (PST) Received: from localhost (mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) with SMTP id BAA17267; Fri, 5 Dec 1997 01:12:53 -0500 (EST) Date: Fri, 5 Dec 1997 01:12:53 -0500 (EST) From: Tony Mione To: ietf-open-pgp@imc.org cc: Tony Mione Subject: More draft comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Some more comments....hope they are helpful. Secition 5.4: ... - A one-octet number describing the public key algorithm used. - An eight-octet number holding the key ID of the signing key. - A one-octet number holding a flag showing whether the signature... ... Why is the keyID needed? It should be present in the actual signature packet at the end of the message (in an Issuer ID subpacket within the actual signature packet). Isn't this a waste of space? Also, what if you are setting up one pass signing for multiple keys? Do you need multiple one pass signature packets if all of the other information is the same (pk algorithm, sig type, hash alg, etc)? Section 5.5.3: Why are p and q saved? My understanding was that these are not needed should be thrown away after the keypair is generated. If the secret key exponent is saved in addition to the public exponent, then there is no need for these pieces of data. Or am I totally missing something? Section 5.12, second editor's note: ... {{Editor's note: should we put in an X.509 encapsulation packet type?}} ... How about a new packet type for all certificates. Internally, it can included a certificate type (PGP Classic = 1, OpenPGP = 2, X.509 = 3, SPKI = 4, etc.) followed by certificate-specific contents (ASN.1 crud for X.509, s-expression for SPKI, etc). Section 7.1: In each case, exactly what material is the key signing? The signature packet says which subpackets are included in the signed material, however, what parts of the preceding packets are hashed and signed: - The entire public key packet followed by the entire user-id packet? - The MPIs from the pk packet + user-id data? - only the actual key material from the pk packet + the user-id data? Section 8: Ok, now I'm confused. How does this relate to the public key packet? If this is not a packet, but rather a stored structure, then why is it in a document on Message Formats? Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA04697 for ietf-open-pgp-bks; Thu, 4 Dec 1997 19:34:51 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA04693 for ; Thu, 4 Dec 1997 19:34:47 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id TAA19027; Thu, 4 Dec 1997 19:36:27 -0800 (PST) Message-Id: <3.0.3.32.19971204193558.00a63550@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Dec 1997 19:35:58 -0800 To: az096@freenet.toronto.on.ca, From: Jon Callas Subject: Re: new algorithm identifier of the symmetric cryptosystem. Cc: ietf-open-pgp@imc.org In-Reply-To: References: <3.0.3.32.19971204140456.00a68340@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:47 PM 12/4/97 -0500, Robert Guerra wrote: is there a spec. for an eliptic curve encryption algorithym? I've added one in for Elliptic Curve encryption and for ECDSA. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA04576 for ietf-open-pgp-bks; Thu, 4 Dec 1997 19:19:51 -0800 (PST) Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by mail.proper.com (8.8.7/8.7.3) with SMTP id TAA04570 for ; Thu, 4 Dec 1997 19:19:45 -0800 (PST) Received: from [128.100.160.138] ([128.100.160.138]) by bureau6.utcc.utoronto.ca with SMTP id <159973(1)>; Thu, 4 Dec 1997 21:48:08 -0500 Date: Thu, 4 Dec 1997 21:47:52 -0500 From: Robert Guerra Reply-To: az096@freenet.toronto.on.ca To: Subject: Re: new algorithm identifier of the symmetric cryptosystem. cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971204140456.00a68340@mail.pgp.com> Message-ID: X-Authenticated: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 4 Dec 1997 17:04:56 -0500 jon@pgp.com (Jon Callas) wrote: > >Presently, the OP-FORMAT spec defines 4 for Blowfish. I'll reserve one for >GOST. > is there a spec. for an eliptic curve encryption algorithym? Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA03408 for ietf-open-pgp-bks; Thu, 4 Dec 1997 17:45:38 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA03403 for ; Thu, 4 Dec 1997 17:45:33 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id OAA18387; Fri, 5 Dec 1997 14:47:02 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88128642113958>; Fri, 5 Dec 1997 14:47:01 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hal@rain.org, ietf-open-pgp@imc.org Subject: Re: new algorithm identifier of the symmetric cryptosystem. Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 5 Dec 1997 14:47:01 (NZDT) Message-ID: <88128642113958@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >One problem we have (which was discussed a while back on this list) is that >our algorithm identifiers have no provision for variants. With IDEA this was >not a problem as there was only one IDEA. 3DES is pretty well standardized >on the version we use (EDE). CAST is technically a design procedure rather >than a cipher, and what we call CAST is properly known as CAST5-128, with >several other variations possible. Why not just use the ISO AlgorithmIdentifiers, which (where they exist) are well-know and standardised, and handle parameters and variants? The only problem is that they're variable-length, but that shouldn't be a major problem, especially since the current format doesn't handle algorithm parameters and will need some sort of major change to support this anyway. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA03387 for ietf-open-pgp-bks; Thu, 4 Dec 1997 17:45:12 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA03382 for ; Thu, 4 Dec 1997 17:45:07 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id OAA18380; Fri, 5 Dec 1997 14:46:37 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88128639714026>; Fri, 5 Dec 1997 14:46:37 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-open-pgp@imc.org, jon@pgp.com Subject: Re: DSS lengths Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 5 Dec 1997 14:46:37 (NZDT) Message-ID: <88128639714026@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >[DSA 1Kbit limit] >I've tried in OP-FORMAT not to talk about this -- I don't want to limit an >implementation to 1024 bits, nor to mandate how to get a larger hash value. >Is there something I need to change in the spec? It would be a good idea to at least warn people about this, because without it people will (a) use keys > 1K bits thinking they're getting extra security, or (b) try to cobble together their own hash functions to get > 160 bits output. It's probably worth a note in the "Security Considerations" section to say that people shouldn't do this. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA01456 for ietf-open-pgp-bks; Thu, 4 Dec 1997 15:19:57 -0800 (PST) Received: from coyote.rain.org (hal@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA01452 for ; Thu, 4 Dec 1997 15:19:52 -0800 (PST) Received: (from hal@localhost) by coyote.rain.org (8.8.8/8.8.8) id PAA11698; Thu, 4 Dec 1997 15:23:11 -0800 (PST) Date: Thu, 4 Dec 1997 15:23:11 -0800 (PST) From: Hal Message-Id: <199712042323.PAA11698@coyote.rain.org> To: hironobu@h2np.suginami.tokyo.jp, jon@pgp.com Subject: Re: new algorithm identifier of the symmetric cryptosystem. Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk One problem we have (which was discussed a while back on this list) is that our algorithm identifiers have no provision for variants. With IDEA this was not a problem as there was only one IDEA. 3DES is pretty well standardized on the version we use (EDE). CAST is technically a design procedure rather than a cipher, and what we call CAST is properly known as CAST5-128, with several other variations possible. The newer ciphers we are reserving alg identifiers for also have this problem. In the case of Blowfish, it can support any key size up to some maximum. I think 128 bit keys may be a common implementation. GOST does not specify the S-boxes so there will be variations on that, similar to CAST. AES is planned to support a few different key and block sizes so there will be at least two or three variations on that one. I'm not sure it makes sense to reserve single algorithm identifiers for these ciphers. Maybe we should just do it as they are implemented. When someone implements Blowfish with a 128 bit key they get an algorithm ID for that. If someone else wants to implement a 256 bit key they get a new identifier. There is probably not a need for a huge spectrum of variations on any of these functions. Hal Finney hal@pgp.com hal@rain.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01944 for ietf-open-pgp-bks; Thu, 4 Dec 1997 13:53:11 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01937 for ; Thu, 4 Dec 1997 13:53:07 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id NAA15628; Thu, 4 Dec 1997 13:54:54 -0800 (PST) Message-Id: <3.0.3.32.19971204135424.00a64390@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Dec 1997 13:54:24 -0800 To: ietf-open-pgp@imc.org From: Jon Callas Subject: DSS lengths Cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971204015523.006e0240@popd.ix.netcom.com> References: <88118582801112@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk As Peter said, to make a DSA implementation greater than 1024 bits, you need a hash that is bigger that 160 bits. Also as Peter noted, we've been investigating how to do this. We plan on getting larger hashes and thus longer DSA keys. I've tried in OP-FORMAT not to talk about this -- I don't want to limit an implementation to 1024 bits, nor to mandate how to get a larger hash value. Is there something I need to change in the spec? Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA01064 for ietf-open-pgp-bks; Thu, 4 Dec 1997 14:55:54 -0800 (PST) Received: from att.com (kcgw2.att.com [192.128.133.152]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA01057 for ; Thu, 4 Dec 1997 14:55:40 -0800 (PST) From: stewarts@ix.netcom.com Received: by kcgw2.att.com; Thu Dec 4 16:41 CST 1997 Received: from attrh1.attrh.att.com (attrh1.attrh.att.com [135.71.27.39]) by kcig2.att.att.com (AT&T/GW-1.0) with SMTP id QAA04217; Thu, 4 Dec 1997 16:46:27 -0600 (CST) Received: from ca07b8bl.bns.att.com by attrh1.attrh.att.com (SMI-8.6/EMS-1.2 sol2) id RAA00650 for ; Thu, 4 Dec 1997 17:56:20 -0500 Message-Id: <3.0.3.32.19971204133500.00754cb8@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 04 Dec 1997 13:35:00 -0800 To: "William H. Geiger III" Original-From: Bill Stewart Subject: Re: Speculative Mode for KeyIDs of all zeroes Cc: ietf-open-pgp@imc.org In-Reply-To: <199712041041.FAA29002@users.invweb.net> References: <3.0.3.32.19971204021239.006ea164@schloss.li> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 04:22 AM 12/04/1997 -0600, William H. Geiger III wrote: >I believe that there is a program PGP Stealth that works well for striping >this information from PGP messages before Stego is applied. > >We had a rather lengthy discussion on Stego techniques on #pgp the other >day. I have primarily playing with the bit hiding and haven't looked too >much at the PGP header striping. I imagine that if a PGP implementation >could not handle a "striped" PGP message that the Stego preprocessor could >"fix" the encrypted message before passing it to PGP. This isn't a spelling flame, but you're ambiguous here - do you mean - "Stripping" - taking out unnecessary stuff, or - "Striping" - spreading information out in thin stripes, similarly to striped file systems spread across disk drives ? But yes, using an all-zero KeyID as a speculative mode would fit in very well with a stealth preprocessor, which can use whatever values it wants in the field when stealthed, and then replace with 0s when destealthing if it doesn't have a better alternative. On the other hand, if OPGP does support the 0s mode, it'll have to successively try each secret key it has until it either finds one that works or finds that none of them work; an alternative is to have an external preprocessor program that drives it, by trying each KeyID in succession. This requires that the driver know what KeyIDs are available (either reading directly from the keyring or just from a list), and that the OPGP implementation have some easily-parsed response that lets the driver decide whether or not the decryption worked. Another option is to only check the "default" key, though default key really an artifact of the user interface rather than something OPGP needs to know about. Internal support is more efficient, but non-critical, so I'd recommend against making it a MUST, but it'd be nice to have it as a SHOULD. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA00485 for ietf-open-pgp-bks; Thu, 4 Dec 1997 14:23:43 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA00481 for ; Thu, 4 Dec 1997 14:23:39 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id OAA15792; Thu, 4 Dec 1997 14:05:25 -0800 (PST) Message-Id: <3.0.3.32.19971204140456.00a68340@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Dec 1997 14:04:56 -0800 To: Hironobu Suzuki , Jon Callas From: Jon Callas Subject: Re: new algorithm identifier of the symmetric cryptosystem. Cc: ietf-open-pgp@imc.org In-Reply-To: <9712040620.AA10643@h2np.suginami.tokyo.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 03:20 PM 12/4/97 +0900, Hironobu Suzuki wrote: I wrote the GOST/BLOWFISH with PGP as prototype and testing version, not to open it to the public. But I need to distribute to someone who criticize my idea or my source codes. Sometime, both things contradict each other. If ID #4 and #5 are already assinged for other algorithms, it makes a trouble and a confusion for PGP community. I hope to avoid this situation. Your previous message said that your implementation of GOST and Blowfish was a kind of a joke, so I didn't know if you were requesting a constant or not. Presently, the OP-FORMAT spec defines 4 for Blowfish. I'll reserve one for GOST. Few years later, someone will hack AES (Advanced Encryption Standard) into PGP. I think several people will hack it at the same time. Who does allocate/control id number of AES? You're correct, it makes sense to reserve a constant for the AES now. Thank you for the suggestion. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA03643 for ietf-open-pgp-bks; Thu, 4 Dec 1997 11:55:06 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA03635 for ; Thu, 4 Dec 1997 11:55:00 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id IAA13904; Fri, 5 Dec 1997 08:56:42 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88126540111276>; Fri, 5 Dec 1997 08:56:41 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: whgiii@invweb.net Subject: Re: Comments on draft - Long. Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 5 Dec 1997 08:56:41 (NZDT) Message-ID: <88126540111276@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk "William H. Geiger III" writes: >In <88118582801112@cs26.cs.auckland.ac.nz>, on 12/04/97 > at 10:50 AM, pgut001@cs.auckland.ac.nz (Peter Gutmann) said: >>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP >>>should be free to do longer keys, even though the standard doesn't actually >>>support them. >>There's no point in moving to p > 1K bits if q is only 160 bits because >>it'll be vulnerable to a small-exponent attack. Since q is governed by >>the hash function associated with DSA, you then need to define a new >>hash function with a larger output block size, and suddenly things get >>very messy. At the moment I don't think it's sensible to use keys > 1K >>bits, all it'll do is lead to confusion about the amount of security >>offered. >I am not that well versed on DSA but what is involved in increasing p if a >corresponding q can be supplied? > >Will a p of 2048 work with a corresponding q of 320? Here's a table of p vs q (generated by Colin Plumb). /* Once the DSA p goes above 1024 bits, we need to increase q correspondingly to provide equivalent security from small-exponent attacks. The following information for doing this was provided by Colin Plumb. This is based on a paper by Michael Wiener on | The function defined the difficulty of the two attacks, which has | below (not part of the the following table: | original paper) | produces the following Table 1: Subgroup Sizes to Match Field Sizes | results: Size of p Cost of each attack Size of q (bits) (instructions or (bits) modular multiplies) 512 9 x 10^17 119 768 6 x 10^21 145 1024 7 x 10^24 165 1280 3 x 10^27 183 1536 7 x 10^29 198 1792 9 x 10^31 212 2048 8 x 10^33 225 2304 5 x 10^35 237 2560 3 x 10^37 249 2816 1 x 10^39 259 3072 3 x 10^40 269 3328 8 x 10^41 279 3584 2 x 10^43 288 3840 4 x 10^44 296 4096 7 x 10^45 305 4352 1 x 10^47 313 4608 2 x 10^48 320 4864 2 x 10^49 328 5120 3 x 10^50 335 */ As you can see, you'd need a hash of >300 bits for keys of up to 4096 bits, so in theory you could use some double-width variant of SHA for keys > 1K bits. I remember someone from PGP Inc asking about wide hashes about a year ago on some mailing list, so it looks like PGP Inc have already considered (and rejected) something like this in the past. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA02646 for ietf-open-pgp-bks; Thu, 4 Dec 1997 10:56:29 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA02640 for ; Thu, 4 Dec 1997 10:56:25 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA12906; Thu, 4 Dec 1997 10:57:58 -0800 (PST) Message-Id: <3.0.3.32.19971204105728.00ae3530@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Dec 1997 10:57:28 -0800 To: maksim@volga.net, Ian Brown From: Jon Callas Subject: Re: OP and pgp5.0i: some problems Cc: IETF OpenPGP In-Reply-To: <199712041814.KAA18032@geocities.com> References: <3486CDCA.ECABA73F@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:22 PM 12/4/97 +0400, Maksim Otstavnov wrote: Besides, it has nothing to do with PGP/MIME. PGP/MIME is a separate question currentely not discussed by this WG according to its agenda. (right?). No, PGP/MIME (a.k.a. OP-MIME, or RFC 2015) is covered by this working group. The OP is to obsolete rfc1991, not 2015, right? Ascii-armor is currently defined in 1991, not 2015. So I just wish OP rfc to contain both a concept of "8-bit text" and definition of actions order for plugins/glues producing _non-PGP/MIME_ messages. Just so little ;) This working group has two things under its charter (presently) -- the OP-FORMAT document and RFC 2015. So each are relevant, we just have two documents. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA00285 for ietf-open-pgp-bks; Thu, 4 Dec 1997 10:13:26 -0800 (PST) Received: from geocities.com (mail1.geocities.com [209.1.224.29]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA00277 for ; Thu, 4 Dec 1997 10:13:16 -0800 (PST) Received: from maksim (tun-ad17.tver.fact400.ru [194.87.239.17]) by geocities.com (8.8.5/8.8.5) with SMTP id KAA18032; Thu, 4 Dec 1997 10:14:34 -0800 (PST) Message-Id: <199712041814.KAA18032@geocities.com> Comments: Authenticated sender is From: "Maksim Otstavnov" Organization: home office To: Ian Brown Date: Thu, 4 Dec 1997 21:22:10 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: OP and pgp5.0i: some problems Reply-to: maksim@volga.net CC: IETF OpenPGP In-reply-to: <3486CDCA.ECABA73F@cs.ucl.ac.uk> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk on Thu, 04 Dec 1997 15:35:38 +0000 Ian Brown quoted Maksim Otstavnov and wrote: > > Currently, PGP/MIME (RFC2015) allows only 7-bit content. > > You said you wanted: > >Content-Type: text/plain; charset=KOI8-R > >Content-Transfer-Encoding: 8bit > > Content-Transfer-Encoding could be base64 just as easily. PGP/MIME would > then sign that encoded data. Yes it works in most 2.6-compatible mailers. I'd like to have abovequouted format as an option, though, for the advantage of legibility. Besides, it has nothing to do with PGP/MIME. PGP/MIME is a separate question currentely not discussed by this WG according to its agenda. (right?). The OP is to obsolete rfc1991, not 2015, right? Ascii-armor is currently defined in 1991, not 2015. So I just wish OP rfc to contain both a concept of "8-bit text" and definition of actions order for plugins/glues producing _non-PGP/MIME_ messages. Just so little ;) > > There are 2 questions: > > 1) do plugins in existence support the operation? > > 2) Should it be documented in OP or in a separate document? > > MIME-compatible mailers will do the encoding. Which encoding: base64 or 8-bit or both? thanks, -- -- Maksim Otstavnov http://www.geocities.com/SoHo/Studios/1059/ -- -maintainer of The Russian PGP HomePage -- (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html) -- -moderator of "Security&Privacy" (Russian language) Web-forum -- (http://www.rocit.ru/forum) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA27667 for ietf-open-pgp-bks; Thu, 4 Dec 1997 08:18:20 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA27654 for ; Thu, 4 Dec 1997 08:18:14 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id RAA19164; Thu, 4 Dec 1997 17:19:56 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Comments on draft - Long. Date: 4 Dec 1997 16:19:56 GMT Organization: IKS GmbH Jena Lines: 6 Message-ID: References: <199712031809.KAA03631@s20.term1.sb.rain.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Hal Finney wrote: >No, the length is meant to be one byte. However counted strings are no >longer used in the document proper, and so they could probably go away. Pathnames are stored in that way. (at least) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA27458 for ietf-open-pgp-bks; Thu, 4 Dec 1997 08:09:53 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA27454 for ; Thu, 4 Dec 1997 08:09:47 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id RAA18868; Thu, 4 Dec 1997 17:11:31 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: OP and pgp5.0i: some problems Date: 4 Dec 1997 16:11:30 GMT Organization: IKS GmbH Jena Lines: 18 Message-ID: References: <199712031833.KAA03688@s20.term1.sb.rain.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Hal Finney wrote: >I don't know much about the charset stuff. Does it just affect how >the signature is calculated, or does it actually affect how the data >is decoded out of a literal packet? Yes. In cleartext signed messages the conversation is done before hashing. >> (2) "charset" setting is somewhat misleading. For instance, when I >> sign a 8-bit text content of Windows clipboard, it is usually >> meaningful in Windows native coding (the so called Windows-cpXXXX, is It is a subset of Unicode not a special charset. >I hope not. Can't we just leave the messages alone? Trying to translate >an 8-bit Cyrillic document into 7-bit printable US-ASCII sounds like a >nightmare. Exactly that's what RfC 2015 is for. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA26815 for ietf-open-pgp-bks; Thu, 4 Dec 1997 07:37:11 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA26792 for ; Thu, 4 Dec 1997 07:37:00 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Dec 1997 15:38:29 +0000 Message-ID: <3486CDCA.ECABA73F@cs.ucl.ac.uk> Date: Thu, 04 Dec 1997 15:35:38 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: maksim@volga.net CC: IETF OpenPGP Subject: Re: OP and pgp5.0i: some problems References: <199712041301.FAA15027@geocities.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Currently, PGP/MIME (RFC2015) allows only 7-bit content. You said you wanted: >Content-Type: text/plain; charset=KOI8-R >Content-Transfer-Encoding: 8bit Content-Transfer-Encoding could be base64 just as easily. PGP/MIME would then sign that encoded data. > There are 2 questions: > 1) do plugins in existence support the operation? > 2) Should it be documented in OP or in a separate document? MIME-compatible mailers will do the encoding. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA24829 for ietf-open-pgp-bks; Thu, 4 Dec 1997 05:57:42 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA24825 for ; Thu, 4 Dec 1997 05:57:37 -0800 (PST) Received: from s20.term1.sb.rain.org (s17.term2.sb.rain.org [198.68.144.177]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id GAA25759; Thu, 4 Dec 1997 06:00:53 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id FAA09543; Thu, 4 Dec 1997 05:44:31 -0800 Date: Thu, 4 Dec 1997 05:44:31 -0800 From: Hal Finney Message-Id: <199712041344.FAA09543@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, pgut001@cs.auckland.ac.nz Subject: Discrete log signature key sizes Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Peter Gutmann, pgut001@cs.auckland.ac.nz, writes: > >Bill Stewart writes: > >At 10:50 AM 12/04/1997, Peter Gutmann wrote: > >>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP > >>>should be free to do longer keys, even though the standard doesn't actually > >>>support them. > >>There's no point in moving to p > 1K bits if q is only 160 bits because it'll > >>be vulnerable to a small-exponent attack. Since q is governed by the hash > >>function associated with DSA, you then need to define a new hash function wit > >>a larger output block size, and suddenly things get very messy. At the momen > >>I don't think it's sensible to use keys > 1K bits, all it'll do is lead to > >>confusion about the amount of security offered. > >Also, as I look at PGP key generation again, it does limit the DSA keys to > >1024 bits, even when you're doing longer ElGamal. Doesn't necessarily have to > >do that, but I didn't find a way to input different behaviour. > > To get around this, you could use Elgamal for signatures (although the current > PGP doesn't support this, the code is commented out). I published an Elgamal > profile for X.509 a few months ago (available from RFC draft repositories) > which specifies how to do this and covers various security issues. It's still questionable to go to longer key sizes even with ElGamal. A birthday attack against the hash function has the same work factor as breaking a 1024 discrete log, approximately (which is why DSS used the 160 bit / 1024 bit structure). Now for some apps a birthday attack is not good enough, you need to duplicate the hash, which takes the square of the effort, and for them using a longer key could work. But for general use there is no point in increasing key size until you have a larger hash. Anybody have a good way to synthesize a 320 bit hash out of a 160 bit one? I found a paper which suggested doing a "butterfly" using 8 instances of the smaller hash which looked pretty good (Eurocrypt 96, Aiello). Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA24397 for ietf-open-pgp-bks; Thu, 4 Dec 1997 05:32:40 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA24389 for ; Thu, 4 Dec 1997 05:32:35 -0800 (PST) Received: from users.invweb.net (ppp20.dotstar.net [208.143.93.39]) by users.invweb.net (8.8.7/8.8.7) with SMTP id IAA30392; Thu, 4 Dec 1997 08:32:20 -0500 Message-Id: <199712041332.IAA30392@users.invweb.net> From: "William H. Geiger III" Date: Thu, 04 Dec 97 07:17:33 -0600 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) In-Reply-To: <88118582801112@cs26.cs.auckland.ac.nz> Cc: stewarts@ix.netcom.com, ietf-open-pgp@imc.org Subject: Re: Comments on draft - Long. X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <88118582801112@cs26.cs.auckland.ac.nz>, on 12/04/97 at 10:50 AM, pgut001@cs.auckland.ac.nz (Peter Gutmann) said: >>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP >>should be free to do longer keys, even though the standard doesn't actually >>support them. > >There's no point in moving to p > 1K bits if q is only 160 bits because >it'll be vulnerable to a small-exponent attack. Since q is governed by >the hash function associated with DSA, you then need to define a new >hash function with a larger output block size, and suddenly things get >very messy. At the moment I don't think it's sensible to use keys > 1K >bits, all it'll do is lead to confusion about the amount of security >offered. > I am not that well versed on DSA but what is involved in increasing p if a corresponding q can be supplied? Will a p of 2048 work with a corresponding q of 320? Does q need to be the entire Hash or can it be only part of it? Say you have a p of 512 and a 160 hash does one use only 80 bits of the 160 hash and discard the rest? The lines I am thinking along are as follows: You desire a key of size p which requires a certain q. You have a hash which is a fraction of q. Rather than generating 1 hash of the message you evenly divide the message into parts and create a hash for each part then concatenate the hashes to provide the required q for the size p key you wish to work with. If there is a gaping flaw in the logic here please be gentle with the flames as I have been up all night working. :) - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNIawqI9Co1n+aLhhAQJvIwQAj44OLr4Zt8wuZ50GC/ihPUP6nYPcL9Qz FRjSsCzfhyUGrx40ha5HErAmCWF6s0CC4kP1WG0fr1CdD8kGuvtutff97QemAxS2 mRvjmAoFWqY4QCftNqLM6RJFB9BCT4BcMeDM6LvoU5zhX9KB8rdDEifgaE88opCV aNanX9+MFfU= =Ro5G -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA23833 for ietf-open-pgp-bks; Thu, 4 Dec 1997 05:01:27 -0800 (PST) Received: from geocities.com (mail3.geocities.com [209.1.224.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA23827 for ; Thu, 4 Dec 1997 05:01:23 -0800 (PST) Received: from maksim (tun-ad17.tver.fact400.ru [194.87.239.17]) by geocities.com (8.8.5/8.8.5) with SMTP id FAA15027; Thu, 4 Dec 1997 05:01:17 -0800 (PST) Message-Id: <199712041301.FAA15027@geocities.com> Comments: Authenticated sender is From: "Maksim Otstavnov" Organization: home office To: Ian Brown Date: Thu, 4 Dec 1997 16:09:05 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: OP and pgp5.0i: some problems Reply-to: maksim@volga.net CC: IETF OpenPGP In-reply-to: <34868473.8523C4B7@cs.ucl.ac.uk> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk From: Self To: Ian Brown Subject: Re: OP and pgp5.0i: some problems Copies to: IETF OpenPGP Send reply to: maksim@volga.net Date sent: Thu, 4 Dec 1997 15:50:34 +0400 on Thu, 04 Dec 1997 10:22:43 Ian Brown quoted Maksim Otstavnov and wrote: > > It would be nice but Windows or Mac native Cyrillic codepages will > > look gibberish to each other. (Of course there are tools to read > > cp1251 on Mac or Unix, but we aim at Mr Common User). Normalization to > > KOI8 is currently the only safe way to achive cross-platform legibility > > (even MS mailers learned to understand koi8 nowadays). > > PGP/MIME would be perfect for this. A MIME encoding of your message > would be signed rather than the message itself. Currently, PGP/MIME (RFC2015) allows only 7-bit content. The perfect solution would be to have an option of 8-bit MIME (eg >Content-Type: text/plain; charset=KOI8-R >Content-Transfer-Encoding: 8bit for Russian) containing clearsigned message. There are 2 questions: 1) do plugins in existence support the operation? (of course I would just test it, but it requires installing rather huge MS Outlook and _warez_ Eudora plugin, the latter not included in 5.0i kit). 2) Should it be documented in OP or in a separate document? I'd welcome comments from plugins developers. -- -- Maksim Otstavnov http://www.geocities.com/SoHo/Studios/1059/ -- -maintainer of The Russian PGP HomePage -- (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html) -- -moderator of "Security&Privacy" (Russian language) Web-forum -- (http://www.rocit.ru/forum) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA19473 for ietf-open-pgp-bks; Thu, 4 Dec 1997 02:57:38 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA19467 for ; Thu, 4 Dec 1997 02:57:32 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id XAA09866; Thu, 4 Dec 1997 23:59:14 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88123315408427>; Thu, 4 Dec 1997 23:59:14 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: stewarts@ix.netcom.com Subject: Re: Comments on draft - Long. Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 4 Dec 1997 23:59:14 (NZDT) Message-ID: <88123315408427@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Bill Stewart writes: >At 10:50 AM 12/04/1997, Peter Gutmann wrote: >>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP >>>should be free to do longer keys, even though the standard doesn't actually >>>support them. >>There's no point in moving to p > 1K bits if q is only 160 bits because it'll >>be vulnerable to a small-exponent attack. Since q is governed by the hash >>function associated with DSA, you then need to define a new hash function wit >>a larger output block size, and suddenly things get very messy. At the momen >>I don't think it's sensible to use keys > 1K bits, all it'll do is lead to >>confusion about the amount of security offered. >Also, as I look at PGP key generation again, it does limit the DSA keys to >1024 bits, even when you're doing longer ElGamal. Doesn't necessarily have to >do that, but I didn't find a way to input different behaviour. To get around this, you could use Elgamal for signatures (although the current PGP doesn't support this, the code is commented out). I published an Elgamal profile for X.509 a few months ago (available from RFC draft repositories) which specifies how to do this and covers various security issues. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA19243 for ietf-open-pgp-bks; Thu, 4 Dec 1997 02:40:17 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA19239 for ; Thu, 4 Dec 1997 02:40:11 -0800 (PST) Received: from users.invweb.net (ppp20.dotstar.net [208.143.93.39]) by users.invweb.net (8.8.7/8.8.7) with SMTP id FAA29002; Thu, 4 Dec 1997 05:41:16 -0500 Message-Id: <199712041041.FAA29002@users.invweb.net> From: "William H. Geiger III" Date: Thu, 04 Dec 97 04:22:03 -0600 To: Black Unicorn In-Reply-To: <3.0.3.32.19971204021239.006ea164@schloss.li> Cc: Jonathan Wienke , ietf-open-pgp@imc.org, jon@pgp.com, stewarts@ix.netcom.com Subject: Re: Speculative Mode for KeyIDs of all zeroes X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.3.32.19971204021239.006ea164@schloss.li>, on 12/04/97 at 03:12 AM, Black Unicorn said: >At 11:20 PM 12/3/97 -0800, you wrote: >>If >>you are worried about being tortured, the best defense is for Big Brother >>to be unable to verify the existence of a PGP message at all. Some stego >>programs already kludge this by removing various message headers, but I >>don't have references to the techniques handy. I would like to see some >>kind of "stealth message" format defined, where the first N bits of the >>message (N corresponding to the length of the asymmetric key you are using >>to speculatively decrypt) contain the session key, signature keyid, message >>length, symmetric algorithm ID, hash algorithm ID, random padding, and >>other such details so that if you stego a .WAV file, the only way to tell >>is to collect the first 2048 sample LSBits and try decrypting them with >>your private key(s) to see if a message header shows up. Otherwise, all >>you see is random-looking data that may or may not be a PGP message. >Even more substantial kudos. I believe that there is a program PGP Stealth that works well for striping this information from PGP messages before Stego is applied. We had a rather lengthy discussion on Stego techniques on #pgp the other day. I have primarily playing with the bit hiding and haven't looked too much at the PGP header striping. I imagine that if a PGP implementation could not handle a "striped" PGP message that the Stego preprocessor could "fix" the encrypted message before passing it to PGP. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNIaIkI9Co1n+aLhhAQKregQAhSdq511Ww4rBjQsBH8B4kD1bNyk8rSyY bEIHWD6UeoiRUnZSZBX3Nx2uZ7L1IsG8REDyKAmAHMCL0k20frtn2OWMjfF/VY/Q Drp6VORG4fHozjEj9BaaemET+B7Y+qf2nEi7ZJls0pqT4FFA5ZIKH/cMhzhNorm3 6CCTimeuwWU= =ecAY -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA19102 for ietf-open-pgp-bks; Thu, 4 Dec 1997 02:26:52 -0800 (PST) Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA19098 for ; Thu, 4 Dec 1997 02:26:47 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with UUCP id LAA03810 for ietf-open-pgp@imc.org; Thu, 4 Dec 1997 11:12:58 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id LAA01341 ; Thu, 4 Dec 1997 11:08:36 +0100 Message-ID: <19971204110836.20710@sobolev.rhein.de> Date: Thu, 4 Dec 1997 11:08:36 +0100 From: Thomas Roessler To: ietf-open-pgp@imc.org Subject: Fingerprints once again... Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ZPt4rx8FFjLCG7dd Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88.6 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit The draft's description of V4 fingerprints contains some traps for implementors, e.g., it is _not_ clear that the Packet Tag for subkeys has to be changed to a Public Key Packet Tag. Thus, I'd like to propose the attached change to the draft. tlr -- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/ 1280/593238E1 · AE 24 38 88 1B 45 E4 C6 03 F5 15 6E 9C CA FD DB --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=draft-diff --- draft-ietf-openpgp-formats-00.txt.orig Thu Dec 4 10:55:35 1997 +++ draft-ietf-openpgp-formats-00.txt Thu Dec 4 11:06:14 1997 @@ -2145,11 +2145,15 @@ 8.2 V4 Key IDs and Fingerprints -A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag, -followed by the two-octet packet length, followed by the entire Public -Key packet starting with the version field. The key ID is either the -low order 32 bits or 64 bits of the fingerprint. Here are the fields -of the hash material, with the example of a DSA key: +A V4 fingerprint is the 160-bit SHA-1 hash of a valid old-style public +key packet containing the public key in question. This packet consists +of the public key packet tag, followed by a two-octet packet length +field, followed by the entire Public Key material starting with the +version field. Note that the packet used for fingerprint generation will +always be denoted as a Public Key Packet (content tag 6), but never as a +Subkey Packet (content tag 14). The key ID is either the low order 32 +bits or 64 bits of the fingerprint. Here are the fields of the hash +material, with the example of a DSA key: a.1) 0x99 (1 byte) a.2) high order length byte of (b)-(f) (1 byte) --ZPt4rx8FFjLCG7dd-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA19070 for ietf-open-pgp-bks; Thu, 4 Dec 1997 02:23:59 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA19066 for ; Thu, 4 Dec 1997 02:23:53 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Dec 1997 10:25:27 +0000 Message-ID: <34868473.8523C4B7@cs.ucl.ac.uk> Date: Thu, 04 Dec 1997 10:22:43 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: maksim@volga.net CC: IETF OpenPGP Subject: Re: OP and pgp5.0i: some problems References: <199712032041.MAA13966@geocities.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > It would be nice but Windows or Mac native Cyrillic codepages will > look gibberish to each other. (Of course there are tools to read > cp1251 on Mac or Unix, but we aim at Mr Common User). Normalization to > KOI8 is currently the only safe way to achive cross-platform > legibility (even MS mailers learned to understand koi8 nowadays). PGP/MIME would be perfect for this. A MIME encoding of your message would be signed rather than the message itself. Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA18830 for ietf-open-pgp-bks; Thu, 4 Dec 1997 02:04:33 -0800 (PST) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA18826 for ; Thu, 4 Dec 1997 02:04:29 -0800 (PST) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id EAA03296; Thu, 4 Dec 1997 04:05:36 -0600 (CST) Received: from pax-ca27-03.ix.netcom.com(207.93.145.35) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma003279; Thu Dec 4 04:05:10 1997 Message-Id: <3.0.3.32.19971204015523.006e0240@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 04 Dec 1997 01:55:23 -0800 To: pgut001@cs.auckland.ac.nz From: Bill Stewart Subject: Re: Comments on draft - Long. Cc: ietf-open-pgp@imc.org In-Reply-To: <88118582801112@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:50 AM 12/04/1997, Peter Gutmann wrote: >>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP >>should be free to do longer keys, even though the standard doesn't actually >>support them. > >There's no point in moving to p > 1K bits if q is only 160 bits because it'll >be vulnerable to a small-exponent attack. Since q is governed by the hash >function associated with DSA, you then need to define a new hash function with >a larger output block size, and suddenly things get very messy. At the moment >I don't think it's sensible to use keys > 1K bits, all it'll do is lead to >confusion about the amount of security offered. Also, as I look at PGP key generation again, it does limit the DSA keys to 1024 bits, even when you're doing longer ElGamal. Doesn't necessarily have to do that, but I didn't find a way to input different behaviour. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA16868 for ietf-open-pgp-bks; Thu, 4 Dec 1997 01:06:11 -0800 (PST) Received: from archduke.torgo.net (archduke.torgo.net [207.229.134.19]) by mail.proper.com (8.8.7/8.7.3) with SMTP id BAA16863 for ; Thu, 4 Dec 1997 01:06:07 -0800 (PST) Received: from zug.schloss.li by archduke.torgo.net (AppleShare IP Mail Server 5.0.1) id 26890 via TCP with SMTP; Thu, 04 Dec 1997 02:14:08 -0600 Message-Id: <3.0.3.32.19971204021239.006ea164@schloss.li> X-Sender: unicorn@schloss.li X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Dec 1997 02:12:39 -0600 To: Jonathan Wienke From: Black Unicorn Subject: Re: Speculative Mode for KeyIDs of all zeroes Cc: ietf-open-pgp@imc.org, jon@pgp.com, stewarts@ix.netcom.com In-Reply-To: <3.0.3.32.19971203232005.006d0bf0@popd.netcruiser> References: <3485C130.446B9B3D@systemics.com> <199712031809.KAA03631@s20.term1.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:20 PM 12/3/97 -0800, you wrote: >If >you are worried about being tortured, the best defense is for Big Brother >to be unable to verify the existence of a PGP message at all. Some stego >programs already kludge this by removing various message headers, but I >don't have references to the techniques handy. I would like to see some >kind of "stealth message" format defined, where the first N bits of the >message (N corresponding to the length of the asymmetric key you are using >to speculatively decrypt) contain the session key, signature keyid, message >length, symmetric algorithm ID, hash algorithm ID, random padding, and >other such details so that if you stego a .WAV file, the only way to tell >is to collect the first 2048 sample LSBits and try decrypting them with >your private key(s) to see if a message header shows up. Otherwise, all >you see is random-looking data that may or may not be a PGP message. Even more substantial kudos. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA15581 for ietf-open-pgp-bks; Wed, 3 Dec 1997 23:27:14 -0800 (PST) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA15577 for ; Wed, 3 Dec 1997 23:27:10 -0800 (PST) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id BAA16727; Thu, 4 Dec 1997 01:27:09 -0600 (CST) Received: from ffd-ca1-03.ix.netcom.com(205.186.177.35) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma016649; Thu Dec 4 01:26:25 1997 Message-Id: <3.0.3.32.19971203232005.006d0bf0@popd.netcruiser> X-Sender: JonWienk@popd.netcruiser X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 03 Dec 1997 23:20:05 -0800 To: Ian Grigg , Hal Finney From: Jonathan Wienke Subject: Re: Speculative Mode for KeyIDs of all zeroes Cc: ietf-open-pgp@imc.org, jon@pgp.com, stewarts@ix.netcom.com In-Reply-To: <3485C130.446B9B3D@systemics.com> References: <199712031809.KAA03631@s20.term1.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 08:29 PM 12/3/97 +0000, Ian Grigg wrote: >"An implementation MAY interpret a KeyID of all zeroes to mean that all >keys available should be used to decrypt the message speculatively." >or some such. > >I don't think adding any extra features will work for the intended >audience. For reasons that I won't go into now, I don't think any users >who really need the speculative mode will be using anything but pgp2.6 >(the C version, not any compatibility suite like Cryptix). The rest of >us might like to implement it for fun. For "deniable steganography" applications, such as hiding a PGP message in the background noise in TIFF images or .WAV files, the KeyID field should be able to go away entirely, causing the speculative decryption mode. If you are worried about being tortured, the best defense is for Big Brother to be unable to verify the existence of a PGP message at all. Some stego programs already kludge this by removing various message headers, but I don't have references to the techniques handy. I would like to see some kind of "stealth message" format defined, where the first N bits of the message (N corresponding to the length of the asymmetric key you are using to speculatively decrypt) contain the session key, signature keyid, message length, symmetric algorithm ID, hash algorithm ID, random padding, and other such details so that if you stego a .WAV file, the only way to tell is to collect the first 2048 sample LSBits and try decrypting them with your private key(s) to see if a message header shows up. Otherwise, all you see is random-looking data that may or may not be a PGP message. Most people have a fairly small number of private keys, so doing speculative decryption in this manner shouldn't be too computationally expensive, especially if the user can specify the order in which the keys are tried. -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQA/AwUBNIZZo8JF0kXqpw3MEQL1TACeP5It/MOwR2WfRQTEtNAUvAw1tzUAoIeB bs1PXy6cws5PY6jYZh9yt3pM =SwKF -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA15231 for ietf-open-pgp-bks; Wed, 3 Dec 1997 22:38:46 -0800 (PST) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA15227 for ; Wed, 3 Dec 1997 22:38:41 -0800 (PST) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [202.232.2.201]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id PAA26056; Thu, 4 Dec 1997 15:40:16 +0900 (JST) Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id PAA15941; Thu, 4 Dec 1997 15:40:16 +0900 Received: from localhost by h2np.suginami.tokyo.jp (NX5.67c/IIJ-U1.2c) id AA10643; Thu, 4 Dec 97 15:20:33 +0900 Message-Id: <9712040620.AA10643@h2np.suginami.tokyo.jp> To: Jon Callas Cc: ietf-open-pgp@imc.org Subject: Re: new algorithm identifier of the symmetric cryptosystem. In-Reply-To: Your message of "Wed, 03 Dec 1997 12:20:56 PST." <3.0.3.32.19971203122056.00a19ae0@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Dec 1997 15:20:33 +0900 From: Hironobu Suzuki Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I don't know this topic is a good for IETF mailing list. If someone knows a good ML(s) for this topic, please let me know about it. Jon Callas said: > Does mean you want me to put in an algorithim identifier for GOST, > or not? I wrote the GOST/BLOWFISH with PGP as prototype and testing version, not to open it to the public. But I need to distribute to someone who criticize my idea or my source codes. Sometime, both things contradict each other. If ID #4 and #5 are already assinged for other algorithms, it makes a trouble and a confusion for PGP community. I hope to avoid this situation. I hope to use id numbers which nobody complains me :-). Even if id number should be #11 or #101 or #1001, it's OK. Ian Grigg said: > Until the full paramaters are known (S Boxes, etc, as mentioned by > Bill), perhaps a provisional number could be allocated pending an > RFC for GOST/PGP, that includes the relevant detail. This suggestion is better than what I thought. Thanks Mr. Grigg. Provisional number: GOST/PGP -- #4 BLOWFISH/PGP -- #5 It's sounds good :-) Few years later, someone will hack AES (Advanced Encryption Standard) into PGP. I think several people will hack it at the same time. Who does allocate/control id number of AES? HAPPY HACKING! -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.suginami.tokyo.jp URL://www.pp.iij4u.or.jp/~h2np Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA14877 for ietf-open-pgp-bks; Wed, 3 Dec 1997 21:59:47 -0800 (PST) Received: from archduke.torgo.net (archduke.torgo.net [207.229.134.19]) by mail.proper.com (8.8.7/8.7.3) with SMTP id VAA14873 for ; Wed, 3 Dec 1997 21:59:43 -0800 (PST) Received: from zug.schloss.li by archduke.torgo.net (AppleShare IP Mail Server 5.0.1) id 26780 via TCP with SMTP; Wed, 03 Dec 1997 23:11:33 -0600 Message-Id: <3.0.3.32.19971203231006.006deb50@schloss.li> X-Sender: unicorn@schloss.li X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 03 Dec 1997 23:10:06 -0600 To: Ian Grigg , Hal Finney From: Black Unicorn Subject: Re: Speculative Mode for KeyIDs of all zeroes Cc: ietf-open-pgp@imc.org, jon@pgp.com, stewarts@ix.netcom.com In-Reply-To: <3485C130.446B9B3D@systemics.com> References: <199712031809.KAA03631@s20.term1.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 08:29 PM 12/3/97 +0000, Ian Grigg wrote: >I agree with this. This would be a MAY, would it not? > >"An implementation MAY interpret a KeyID of all zeroes to mean that all >keys available should be used to decrypt the message speculatively." >or some such. > >I don't think adding any extra features will work for the intended >audience. For reasons that I won't go into now, I don't think any users >who really need the speculative mode will be using anything but pgp2.6 >(the C version, not any compatibility suite like Cryptix). The rest of >us might like to implement it for fun. Outstanding. Kudos. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12868 for ietf-open-pgp-bks; Wed, 3 Dec 1997 18:44:22 -0800 (PST) Received: from michonline.com (www.michonline.com [152.160.183.192]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12864 for ; Wed, 3 Dec 1997 18:44:18 -0800 (PST) Received: from localhost (ryan@localhost) by michonline.com (8.8.5/8.8.5) with SMTP id VAA24409 for ; Wed, 3 Dec 1997 21:43:44 -0500 (EST) Date: Wed, 3 Dec 1997 21:43:37 -0500 (EST) From: Ryan Anderson X-Sender: ryan@king To: ietf-open-pgp@imc.org Subject: Re: expedience, consensus and editing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On 27 Nov 1997, Lutz Donnerhacke wrote: > >2) MIME as MAY/SHOULD/MUST? > > Has nothing to do with OpenPGP. OpenPGP deals with the application layer not > with the presentation layer MIME is for. Same goes for Ascii Armor. The WG charter specifically mentions MIME, and I thought we were working on an e-mail spec. From that point of view, future impementations are going to need to interoperate with MIME. So I'd definitely say MUST for MIME (for e-mail applications) and SHOULD for Armor (to be reduced to MAY in v2). > >3) 32 bit int clean up shelved for OpenPGPv2, or discussed now > > 32bit is an unnecessary restriction. (640k are enough for everybody!) It's an increase from the current hacked bit format, from what's been posted here. Shelved for v2 is my vote. > >4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2, > > Drop it completely but mark the subsignature ID as in use. It must be mentioned for proper handling of the critical bit. Mark it as used for a proprietary (PGP Inc.) signature addition that can be ignored if not supported. Ryan Anderson - Alpha Geek PGP fp: 7E 8E C6 54 96 AC D9 57 E4 F8 AE 9C 10 7E 78 C9 print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Wed, 3 Dec 1997 16:15:41 -0800 (PST) Received: from hayek.guvnet (noddy [192.168.1.5]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id CAA24167; Thu, 4 Dec 1997 02:44:49 +0100 (MET) Message-ID: <3485F6C8.1CFBAE39@systemics.com> Date: Thu, 04 Dec 1997 00:18:16 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: Jon Callas CC: hironobu@h2np.suginami.tokyo.jp, ietf-open-pgp@imc.org Subject: Re: new algorithm identifier of the symmetric cryptosystem. References: <3.0.3.32.19971203122056.00a19ae0@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > At 01:37 PM 12/3/97 +0900, Hironobu Suzuki wrote: > > I'd like to know who is control the algorithm identifier of the > symmetric cryptosystem. Jon Callas wrote: > Does mean you want me to put in an algorithim identifier for GOST, or not? Until the full paramaters are known (S Boxes, etc, as mentioned by Bill), perhaps a provisional number could be allocated pending an RFC for GOST/PGP, that includes the relevant detail. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA10239 for ietf-open-pgp-bks; Wed, 3 Dec 1997 15:38:07 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA10221 for ; Wed, 3 Dec 1997 15:37:55 -0800 (PST) Received: (qmail 11041 invoked from network); 3 Dec 1997 23:39:32 -0000 Received: from unknown (HELO GK.us.integralis.com) (206.63.221.161) by smtp.dial.pipex.com with SMTP; 3 Dec 1997 23:39:32 -0000 Message-Id: <3.0.32.19971203043108.0082a100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 04 Dec 1997 00:37:10 +0000 To: david@sternlight.com From: Graham Klyne Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Cc: Gunther Schadow , crocker@cybercash.com, galvin@tis.com, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, murphy@tis.com, ned@innosoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 15:54 30/11/97 -0800, David Sternlight wrote: >[...] For instance it is >mutually exclusive to allow anyone to be a signer and to allow only those >meeting certain standards to be signers. Leaving aside, for the moment, any reference to any particular system: is this necessarily true? I can imagine a system in which the signature itself may carry an authority. So those signers meeting certain standards may supply a credential (as part of the signature) which is verifiable using a public key of the body which set those standards. But as a non-expert in this field, I may be missing something. GK. --- ------------ Graham Klyne Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA08413 for ietf-open-pgp-bks; Wed, 3 Dec 1997 13:49:00 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA08409 for ; Wed, 3 Dec 1997 13:48:55 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id KAA16086; Thu, 4 Dec 1997 10:50:29 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88118582801112>; Thu, 4 Dec 1997 10:50:28 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: stewarts@ix.netcom.com Subject: Re: Comments on draft - Long. Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 4 Dec 1997 10:50:28 (NZDT) Message-ID: <88118582801112@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP >should be free to do longer keys, even though the standard doesn't actually >support them. There's no point in moving to p > 1K bits if q is only 160 bits because it'll be vulnerable to a small-exponent attack. Since q is governed by the hash function associated with DSA, you then need to define a new hash function with a larger output block size, and suddenly things get very messy. At the moment I don't think it's sensible to use keys > 1K bits, all it'll do is lead to confusion about the amount of security offered. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06970 for ietf-open-pgp-bks; Wed, 3 Dec 1997 12:40:40 -0800 (PST) Received: from geocities.com (mail2.geocities.com [209.1.224.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06966 for ; Wed, 3 Dec 1997 12:40:35 -0800 (PST) Received: from maksim (tun-ad17.tver.fact400.ru [194.87.239.17]) by geocities.com (8.8.5/8.8.5) with SMTP id MAA13966; Wed, 3 Dec 1997 12:41:15 -0800 (PST) Message-Id: <199712032041.MAA13966@geocities.com> Comments: Authenticated sender is From: "Maksim Otstavnov" Organization: home office To: Hal Finney , ietf-open-pgp@imc.org Date: Wed, 3 Dec 1997 23:49:08 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: OP and pgp5.0i: some problems Reply-to: maksim@volga.net In-reply-to: <199712031833.KAA03688@s20.term1.sb.rain.org> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- on Wed, 3 Dec 1997 10:33:45 -0800 Hal Finney quoted Maksim Otstavnov and wrote: > > "Charset" header needs defining. Values defined in 2.6.xi need > > enlisting. A mechanism for charsets registration, or embracing > > charsets otherwise registered needs defining. > > I don't know much about the charset stuff. Does it just affect how > the signature is calculated, or does it actually affect how the data > is decoded out of a literal packet? since it is undefined, nobody knows :( Probably the question should be sent to Colin Plumb? > There are really two questions the signature software needs to know. > Is the input to be clearsigned vs binary signed, and should the output > be in text form. In 5.0 these were combined into one checkbox, but > logically there is another possibility, a binary signed file which is > ascii armored for output. Yes. > > > 2.2 Problems with clearsigning > > > > There are still problems however. > > > > (1) 8-bit clearsigning is not described anywhere (I presume). I > > strongly believe it needs defining at least as "SHOULD" in OP. > > How does this differ from the clearsigning description in the draft? The draft reads: ..."textual octet stream"... [2.6] West of Koenigsberg the phrase will most probably be read as "plain vanilla 7-bit ascii". Am I wrong? > > (3) If sending MUA is to perform any other (not cryptographic) > > 8-bit-to-8-bit or 8-bit-to-7-bit transmutation of a msg, the MUA must > > first do this transmutation, then sign the message, and a receiving > > MUA must first check signature, then perform any other transmutations. > > Right? > > I hope not. Can't we just leave the messages alone? It would be nice but Windows or Mac native Cyrillic codepages will look gibberish to each other. (Of course there are tools to read cp1251 on Mac or Unix, but we aim at Mr Common User). Normalization to KOI8 is currently the only safe way to achive cross-platform legibility (even MS mailers learned to understand koi8 nowadays). >Trying to translate > an 8-bit Cyrillic document into 7-bit printable US-ASCII sounds like a > nightmare. Yes. Unfortunately some older SMTP server truncate or bounce 8-bit msgs (is it obsoleted by any document?), so sometimes 7-bitization is needed. > Sorry can't be more help, this is not an area I know much about. Thank you anyway Hal. I hope MUA plugins developers will keep up the thread. -----BEGIN PGP SIGNATURE----- Version: PGP 5.0iRu Alpha 2 iQCVAwUBNIWainGCEHWOiJDhAQGUbgQAxuG5OdP75PAxjWZIoXsdAS6ZJLUMJb9R cTricXZmu5EiRiLiwGaIYg9m5pgJfEAa0mLvCdRJ+Vzq7mKmON1LZeGqFHrXhrug 2AQtQEjoHyQRSe9j0D05S9LzDjEGiB2Uc0iNGtQBDA2Qq+0vSQhWABPrbdt3ydQy VhJazZU1XMo= =UyRM -----END PGP SIGNATURE----- -- -- Maksim Otstavnov http://www.geocities.com/SoHo/Studios/1059/ -- -maintainer of The Russian PGP HomePage -- (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html) -- -moderator of "Security&Privacy" (Russian language) Web-forum -- (http://www.rocit.ru/forum) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06785 for ietf-open-pgp-bks; Wed, 3 Dec 1997 12:27:25 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06781 for ; Wed, 3 Dec 1997 12:27:20 -0800 (PST) Received: from hayek.guvnet (noddy [192.168.1.5]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id WAA23245; Wed, 3 Dec 1997 22:56:04 +0100 (MET) Message-ID: <3485C130.446B9B3D@systemics.com> Date: Wed, 03 Dec 1997 20:29:36 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: Hal Finney CC: ietf-open-pgp@imc.org, jon@pgp.com, stewarts@ix.netcom.com Subject: Speculative Mode for KeyIDs of all zeroes References: <199712031809.KAA03631@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney wrote: > > Thanks to Bill Stewart for some very helpful comments.... > > 5.1 Encrypted Session Key Packet - Traffic Analysis Risk - > > The KeyID field, as defined, leads to a major traffic analysis risk, > > but the format doesn't depend critically on the value in the field. > > At a previous Bay Area Cypherpunks meeting, somebody from PGP > > mentioned a request from some freedom fighter users that KeyIDs > > be shorter, because the current tyrannical government was > > using them to identify who to torture into decrypting messages - > > having PGP was incriminating enough, but with short KeyIDs, > > e.g. 0-3 or 0-16, it's possible to reduce decryption workload > > without indentifying the user of the message. > > I raised this possibility on the list a few weeks ago, but the only > response was negative (I think because it would break the way the > keyids were being used as indexes). If you have that sort of risk, then *any* clues can be used to incriminate you. 2 bits is enough for torture purposes, in my admittedly limited experience of the art. > > Some obvious alternative implementations are to keep the field > > for compatibility, while specifying that the > > - - the receiver of a message MAY attempt decryption regardless > > of the value in the field, regardless of whether > > it's intended for him or not. > > - - the sender must output a value in the field that > > - -- SHOULD be the KeyID, but > > - -- MAY be all-0, for which the receiver SHOULD/MAY decrypt ... > Interesting possibilities. Jon Callas also suggested (internally) the > idea of putting all zeros into the keyid field to mean that the receiver > should try all his keys. This is a good idea. All zeroes, and when confined to small groups who all know what is going on, and have the software that understands this, would work well. > > Since this just requires permission in the spec, rather than > > needing specific implementation, and since the main negative impact > > on non-implementing users is attempting to decrypt > > an occasional message that wasn't intended for them that they > > happened to receive, I'd like to ask that it be included. I agree with this. This would be a MAY, would it not? "An implementation MAY interpret a KeyID of all zeroes to mean that all keys available should be used to decrypt the message speculatively." or some such. I don't think adding any extra features will work for the intended audience. For reasons that I won't go into now, I don't think any users who really need the speculative mode will be using anything but pgp2.6 (the C version, not any compatibility suite like Cryptix). The rest of us might like to implement it for fun. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06683 for ietf-open-pgp-bks; Wed, 3 Dec 1997 12:19:51 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06679 for ; Wed, 3 Dec 1997 12:19:46 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id MAA27968; Wed, 3 Dec 1997 12:21:27 -0800 (PST) Message-Id: <3.0.3.32.19971203122056.00a19ae0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 03 Dec 1997 12:20:56 -0800 To: hironobu@h2np.suginami.tokyo.jp, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: new algorithm identifier of the symmetric cryptosystem. In-Reply-To: <9712030437.AA08543@h2np.suginami.tokyo.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:37 PM 12/3/97 +0900, Hironobu Suzuki wrote: I'd like to know who is control the algorithm identifier of the symmetric cryptosystem. I hacked GOST and BLOWFISH into PGP but still buggy. The algorithm identifier of GOST as FOUR(#4) and BLOWFISH as FIVE(#5) were assigned for my hacked PGP. You may get patch file for pgp50i-b8 from URL://www.pp.iij4u.or.jp/~h2np/pgp Note: THIS IS NOT FOR ANY OFFICIAL OR UNOFFICAL VERSION OF PGP. IT'S A KIND OF JOKE. DON'T BE A SERIOUS. Does mean you want me to put in an algorithim identifier for GOST, or not? Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06595 for ietf-open-pgp-bks; Wed, 3 Dec 1997 12:15:04 -0800 (PST) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06588 for ; Wed, 3 Dec 1997 12:14:59 -0800 (PST) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id OAA06932; Wed, 3 Dec 1997 14:15:14 -0600 (CST) Received: from lax-ca69-52.ix.netcom.com(207.223.161.180) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma006735; Wed Dec 3 14:13:45 1997 Message-ID: <3485BD71.30D28DCF@sternlight.com> Date: Wed, 03 Dec 1997 12:13:39 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: Tony Mione CC: ietf-open-pgp@imc.org, whgiii@invweb.net Subject: Re: What is going on?!? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Tony Mione wrote: > > > Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his > > rants fill up the pgp newsgroups do we really need him here? > > > > If we want him to go away, we need to consistently ignore him > regardless of how inflamatory his remarks are. People like this want some > cause to fight for (really, they just want to get other people ticked). If >no one is playing the game, it is no fun. He will just pick up his ball and > go home (please, please, please). An unbiased review of my posts to the ietf open pgp list will show that I have made no personal remarks about any interlocutor on this list, nor posted any "rants". To the contrary I have bent over backwards to be fair-minded, presenting (for example) advantages of web of trust as well as rigid heirarchical in the context both of this group and the instructions this group and the S/MIME 3 group are under to work together in areas of commonality. I have raised some issues in the context of trust models and the robustness of signature structures. In return, several have mounted vicious personal attacks against me. Readers who aren't trying to obfuscate those issues will realize that personal attacks come from those who feel threatened by a discussion of such issues because they conflict with some hidden agenda. The attackers are attempting to pseudo-speciate my posts in order to avoid those issues. Such behavior speaks for itself, and I assume fair-minded readers see it for what it is. Those who wish to use this group to pursue a partisan political or commercial agenda will have to live with the self-exposure their behavior has now produced. This will be my only post on this topic, since the purpose of this list is to discuss open PGP and not me or attackers on me. I leave it to the good sense of readers to deal with the latter issue as they see fit, in the privacy of their kill files. David Sternlight, Ph.D. Los Angeles -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBNIW9NkwgH+NYrQ81AQGU6gP+No+DwwWQoETdrf6POv/VRG38vxV2UphA 6EEWSpdnELacXeeC/MTYSLGnaIagK1QFjIUnrwXhTRNsOWWeMhbzti4N102/ivXu iQ3v2HEaOsndE6/CMlpfjgvujLbSioqLdDd1voY8L2+o06qJpKMp6m0Otoq8SHJi s+cw/QRsaTk= =R4RD -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06578 for ietf-open-pgp-bks; Wed, 3 Dec 1997 12:14:26 -0800 (PST) Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA06573 for ; Wed, 3 Dec 1997 12:14:09 -0800 (PST) From: stewarts@ix.netcom.com Received: by kcgw1.att.com; Wed Dec 3 14:11 CST 1997 Received: from attrh1.attrh.att.com (attrh1.attrh.att.com [135.71.27.39]) by kcig1.att.att.com (AT&T/GW-1.0) with SMTP id OAA27049; Wed, 3 Dec 1997 14:03:31 -0600 (CST) Received: from ca07b8bl.bns.att.com by attrh1.attrh.att.com (SMI-8.6/EMS-1.2 sol2) id PAA16351 for ; Wed, 3 Dec 1997 15:13:36 -0500 Message-Id: <3.0.3.32.19971203095024.006e28f4@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 03 Dec 1997 09:50:24 -0800 To: IETF OpenPGP , jon@pgp.com Original-From: Bill Stewart Subject: Re: Comments on draft - Long. In-Reply-To: <3.0.3.32.19971203025320.0074b3b0@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Forgot to add one comment: DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP should be free to do longer keys, even though the standard doesn't actually support them. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06563 for ietf-open-pgp-bks; Wed, 3 Dec 1997 12:13:40 -0800 (PST) Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA06555 for ; Wed, 3 Dec 1997 12:13:23 -0800 (PST) From: stewarts@ix.netcom.com Received: by kcgw1.att.com; Wed Dec 3 14:11 CST 1997 Received: from attrh1.attrh.att.com (attrh1.attrh.att.com [135.71.27.39]) by kcig1.att.att.com (AT&T/GW-1.0) with SMTP id OAA27087; Wed, 3 Dec 1997 14:03:36 -0600 (CST) Received: from ca07b8bl.bns.att.com by attrh1.attrh.att.com (SMI-8.6/EMS-1.2 sol2) id PAA16386 for ; Wed, 3 Dec 1997 15:13:40 -0500 Message-Id: <3.0.3.32.19971203111451.006e28f4@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 03 Dec 1997 11:14:51 -0800 To: hironobu@h2np.suginami.tokyo.jp, ietf-open-pgp@imc.org Original-From: Bill Stewart Subject: Re: new algorithm identifier of the symmetric cryptosystem. In-Reply-To: <9712030437.AA08543@h2np.suginami.tokyo.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:37 PM 12/03/1997 +0900, Hironobu Suzuki wrote: >I'd like to know who is control the algorithm identifier of the >symmetric cryptosystem. > >I hacked GOST and BLOWFISH into PGP but still buggy. The algorithm >identifier of GOST as FOUR(#4) and BLOWFISH as FIVE(#5) were assigned >for my hacked PGP. You may get patch file for pgp50i-b8 from Note that GOST is not a single algorithm - it's a family of algorithms, and the security depends on the set of S-Boxes you use. The USSR Military used one set, USSR non-military government another, but we don't know what those sets were, and the set you have may be just as strong, or much weaker. > URL://www.pp.iij4u.or.jp/~h2np/pgp > Note: > THIS IS NOT FOR ANY OFFICIAL OR UNOFFICAL VERSION OF PGP. > IT'S A KIND OF JOKE. DON'T BE A SERIOUS. My company's firewall censorware didn't like the page, and gave me a blocking banner. Must have been a politically incorrect joke.... Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA04774 for ietf-open-pgp-bks; Wed, 3 Dec 1997 10:47:07 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA04768 for ; Wed, 3 Dec 1997 10:46:59 -0800 (PST) Received: from s20.term1.sb.rain.org (s06.term2.sb.rain.org [198.68.144.166]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id KAA06393; Wed, 3 Dec 1997 10:50:09 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA03688; Wed, 3 Dec 1997 10:33:45 -0800 Date: Wed, 3 Dec 1997 10:33:45 -0800 From: Hal Finney Message-Id: <199712031833.KAA03688@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, maksim@volga.net Subject: Re: OP and pgp5.0i: some problems Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 3 Dec 1997, Maksim Otstavnov, , wrote: > 1.1 > > "Charset" header needs defining. Values defined in 2.6.xi need > enlisting. A mechanism for charsets registration, or embracing > charsets otherwise registered needs defining. I don't know much about the charset stuff. Does it just affect how the signature is calculated, or does it actually affect how the data is decoded out of a literal packet? > 5.0(i) for Windows works with the three exact types > of object: (1) files, (2) clipboard text, and (3) data provided > by an MUA plugin through API. Right? > > I cannot test mode (3) now, but the first two (files, with "Text > output" on and "Sign clipboard text" from PGPtray) both produce > a clearsigned 8-bit text which is in some sence "correct" There are really two questions the signature software needs to know. Is the input to be clearsigned vs binary signed, and should the output be in text form. In 5.0 these were combined into one checkbox, but logically there is another possibility, a binary signed file which is ascii armored for output. > 2.2 Problems with clearsigning > > There are still problems however. > > (1) 8-bit clearsigning is not described anywhere (I presume). I > strongly believe it needs defining at least as "SHOULD" in > OP. How does this differ from the clearsigning description in the draft? > (2) "charset" setting is somewhat misleading. For instance, when I > sign a 8-bit text content of Windows clipboard, it is usually > meaningful in Windows native coding (the so called Windows-cpXXXX, is > it described anywhere?), "windows-cp1251" for Russian. But I have > "charset" header in sig armor set in "noconv". PGP 2.6.3i (on all > platforms) and most other programs interprete "noconv" as equivalent > to a native codepage of the receiving system. (In particular, "KOI8-R" > extended charset as Russian standard for open systems). I don't understand charsets so I can't comment on this. > (3) If sending MUA is to perform any other (not cryptographic) > 8-bit-to-8-bit or 8-bit-to-7-bit transmutation of a msg, the MUA must > first do this transmutation, then sign the message, and a receiving > MUA must first check signature, then perform any other transmutations. > Right? I hope not. Can't we just leave the messages alone? Trying to translate an 8-bit Cyrillic document into 7-bit printable US-ASCII sounds like a nightmare. Sorry can't be more help, this is not an area I know much about. Hal Finney hal@pgp.com hal@rain.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA04463 for ietf-open-pgp-bks; Wed, 3 Dec 1997 10:34:32 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA04457 for ; Wed, 3 Dec 1997 10:34:27 -0800 (PST) Received: from s20.term1.sb.rain.org (s06.term2.sb.rain.org [198.68.144.166]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id KAA05288; Wed, 3 Dec 1997 10:37:36 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA03672; Wed, 3 Dec 1997 10:21:13 -0800 Date: Wed, 3 Dec 1997 10:21:13 -0800 From: Hal Finney Message-Id: <199712031821.KAA03672@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, mione@boeing.rutgers.edu Subject: Re: Comments on current draft Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 3 Dec 1997, Tony Mione, , wrote: > 1) There are a few places where the wording suggests and order in which > message processing must take place. It would be better to word things such > that the implementor can decide order of operations as long as the elements > are processed in the correct manner (i.e. hashes are applied to the correct > octet string, etc). One example is on page 4, section 2.1: > > ... > Both digital signature and confidentiality services may be applied to > the same message. First, a signature is generated for the message and > attached to the message. Then, the message plus signature is encrypted > using a conventional session key. Finally, the session key is > encrypted using public-key encryption and prepended to the encrypted > block. > ... This is just introductory and expository and is intended to give a broad overview of the process, not constrain an implementation. > 2) Section 2.2: > > ... > 1. The sender creates a message. > 2. The sending software generates a hash code of the message > 3. The sending software generates a signature from the hash code using > the sender's private key. > 4. The binary signature is attached to the message. > 5. The receiving software keeps a copy of the message signature. > ^^^^^huh? > Better: > > 5. The receiving software decrypts the signature with the sender's > public key and saves that hash code. > > 6. The receiving software generates a new hash code for the received > message and verifies it using the message's signature. If the > ^^^^^^^^^^^^^^^^^^ > verification is successful, the message is accepted as authentic. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > Better: > > 6. The receiving software generates a new hash code for the received > message. If the new hash code matches the hash code derived from the > signature, the message is accepted as authentic. It's not a matter of matching hash codes, it is a matter of running it through the signature verification algorithm. I agree that the "keeps a copy" wording is unclear. > 3) Section 2.6, last paragraph: > > ... > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > ... > > Is this text historical? It seems counter intuitive to me to modify > the text of a message in any way before signing it. This is not historical, it is how it works. Some gateways munge messages by altering trailing whitespace, and this allows such messages to verify correctly. > 4) Section 3.3: > > ... > A counted string consists of a length and then N octets of string data. > ... > > How long is the length (1 octet, 2 octets, same length encoding as > the packet length calculations in section 4.2)? 1 octet, but counted strings are not used. > 5) Section 3.5.3.3: > > ... > count of octets to be hashed = (16 + CMANT) << (CEXP + 6) > ... > > Just curious? Why the constants 16 and 6? The 16 is the implicit first bit, as is standard for floating point formats. The 6 is a normalization so that a more useful range of values can be expressed. > 6) Section 5.2.2.2: > It would be good to specify which subpackets are required and which > are optional (or under which conditions they are required/optional). There > are hints in the text, but it would be good to be explicit (perhaps a small > table would make this clear). Yes, Bill Stewart suggested something similar. Personally I would prefer not to make any of them mandatory but perhaps it is necessary as a temporary measure so that current software can work efficiently. > > Also: > > ... > {{Editor's note: The above preference (hash algs) is controversial. I > included it in for symmetry, because if someone wants to build a > ... > > Why is this controversial? Hash algs would normally be chosen by the signer. They are closely related to the choice of signing key. For example, DSS requires SHA. It doesn't work well for the message recipient(s) to try to say how it should be hashed for signing, since normally we sign before encrypting (possibly long before). > 7) Further down in the same section: > > ... > Regular expression (null-terminated regular expression) (Hashed) > ... > > Which implementation of regular expressions? (See O'Reilly's > 'Mastering Regular Expressions') Good point. We need to document the regexps. > That's all for now. Have fun. Thanks for your comments! Hal Finney hal@pgp.com hal@rain.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA04347 for ietf-open-pgp-bks; Wed, 3 Dec 1997 10:28:31 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA04341 for ; Wed, 3 Dec 1997 10:28:26 -0800 (PST) Received: from [199.106.106.130] (servo.qualcomm.com [129.46.101.170]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id KAA04742; Wed, 3 Dec 1997 10:27:48 -0800 (PST) X-Sender: jwn2@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <199712030514.AAA13775@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0b44-1.98] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 3 Dec 1997 10:23:19 -0800 To: "William H. Geiger III" From: "John W. Noerenberg" Subject: Re: What is going on?!? (FROM The CHAIR) Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:57 PM -0600 12/2/97, you wrote: > >I am rather disapointed to see the amount of bickering going on over >non-issues. The whole ascii issue has been blown way out of proportion. >It's only a couple of lines of code people spend an afternoon write the >code and be done with it. Shesh!! That's my fault. I've been sick with pneumonia the last couple of weeks and haven't been able to wade in to bring this to a close. There are some subtleties here. I'm just now trying to catch up myself. I'm unhappy with MIME and armor both as SHOULDs and no MUST to express the objects. . This is no way to guarantee interoperability. Of course the resolution may simply be that objects MUST be encapsulated in pgp binary packets and rendition of the packets in some ascii printable form can be safely relegated to SHOULDs. There is another thread where this is under discussion (see "expedience, consensus and editing") > >Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his >rants fill up the pgp newsgroups do we really need him here? IETF mailing lists are open to all who wish to make a contribution. However (and this is not directed at you Bill, but to all)... Discussion of these and other off-topic issues should simply be ignored. We waste more time writing messages about how we should not be talking about these things than simply not indulging ourselves. Everyone, please show some restraint! THIS IS A TECHNICAL FORUM FOR DISCUSSION OF PGP FORMAT. THIS IS A TECHNICAL FORUM FOR DISCUSSION OF PGP FORMAT. THIS IS A TECHNICAL FORUM FOR DISCUSSION OF PGP FORMAT. Other discussions has no place here. Is that sufficiently clear? > >Well the IETF meeting is next week. I hope that we can get some productive >work done afterwards. > Yes, let's hope. john w noerenberg, ii jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com ----------------- --------------------------- ---------------------- "The great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." -- Ralph Waldo Emerson, "Self Reliance", 1841 ----------------- --------------------------- ---------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA04331 for ietf-open-pgp-bks; Wed, 3 Dec 1997 10:28:10 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA04326 for ; Wed, 3 Dec 1997 10:28:02 -0800 (PST) Received: from s20.term1.sb.rain.org (s06.term2.sb.rain.org [198.68.144.166]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id KAA04621; Wed, 3 Dec 1997 10:30:51 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA03631; Wed, 3 Dec 1997 10:09:54 -0800 Date: Wed, 3 Dec 1997 10:09:54 -0800 From: Hal Finney Message-Id: <199712031809.KAA03631@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, jon@pgp.com, stewarts@ix.netcom.com Subject: Re: Comments on draft - Long. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Thanks to Bill Stewart for some very helpful comments. There are too many valid issues raised for me to try to address them in one message. Maybe we should collect comments, sort them by section, and then work through them to achieve a decision on each one. I will only respond to a few areas that I can address right now: On Wed, 03 Dec 1997, Bill Stewart, , writes: > 3.3 Counted Strings - > "A counted string consists of a length and > then N octets of string data" > How long is the length field? What's its format? > I'm guessing it's one of the various variable-length-packed-number > formats used in PGP, but you need to specify which one. No, the length is meant to be one byte. However counted strings are no longer used in the document proper, and so they could probably go away. > 3.4 Time Fields - Y2038 problem - Also 5.2.2.2, 5.5.2. 5.9 It is only a problem in 2038 if your software assumes dates are signed or otherwise limits them to 31 bits. With 32 bits it is good until 2106. By then we'll either have destroyed our civilization or transcended into immortal beings of pure energy, right? > 3.5.1.3 / 3.5.3.3 Iterated-Salted > What a blazingly ugly design! Is it really necessary to use > a byte-count in a special one-octet-floating-point format, > rather than using an iteration count? Probably saves one > multiplication when preparing the argument for a hash, > at the cost of a couple masks and shifts and adds a hunk of code. > Especially with the "Conventionally Encrypted Session Key" > available, the extra complexity seems unnecessary. The actual format of these stringtokey specifiers was established before I got involved, so I don't know the history. But let me say a few words in defense of this one, which several other people have objected to. First, this option is by far the most important of the stringtokey specifiers. In fact, it is the only one which should ever be used. The "simple" works like old PGP, but that version never used stringtokey specifiers so it is not even needed for backwards compatibility. "Salted" is a subset of "iterated/salted". Only "iterated/salted" provides the maximum security against dictionary based passphrase attacks. The salt prevents precalculation, and the iteration increases the cost to the attacker manyfold. Lutz suggested that the iteration didn't help because it applies the same cost to the legitimate user as to the attacker, but in most contexts the user can tolerate a small delay while for the attacker it makes his attack hugely harder. He can generate a hash very quickly to test a passphrase. Making him iterate his hash function thousands or millions of times means he can test only one passphrase in the time he could have tried thousands or millions. As for the one-byte hash length count, granted that may be a bit over-optimized. But it only takes one line of code to turn it into a length count, so it is hardly a major implementation cost. Sure, it could have used a 24 or 32 bit field, but that is not really necessary for the purpose. You want to set the passphrase testing cost in almost order-of-magnitude terms. You don't need to differentiate between one million bytes of hashing versus one million and one versus one million and two. You just need to specify it roughly as say 1,000 bytes or 1,000,000. The format provides four bits of precision, which is more than enough for this purpose. > If anybody's really using this option, it probably should be kept, > but as a MAY read, DEPRECATED generate. Otherwise reserve the > S2K-type indicator 0x03 and drop it. We could make another one which used a 32 bit length but was otherwise the same, and deprecate this one. I'm not sure it's worthwhile, though. The thing which I object to about the stringtokey specifiers is that they have no internal length field. If you don't recognize the type of stringtokey object, you don't know where it ends. Apparently that is OK as they are used now, because if you can't interpret them there is no data following them which is of any use to you. But it will constrain any future uses of them. > 4.2 Packet Headers - Packet Length. > Meanwhile, it appears that the Partial Body Length can > support indefinite-length material, which is critical, > since it allows PGP to be used with streaming input such as > speech that goes on for a long time, (though the particular > encoding is inefficient if the data comes in natural chunk sizes > that aren't powers of 2 (or at least 3*2**n), or compresses > to irregular sizes.) It's worth noting this kind of application > in the draft, to encourage OpenPGP implementations to be designed > in ways that aren't limited by temp files with maximum lengths. This is a good application for this packet. Many people seem to have trouble understanding the significance of the one-pass model. It could be that some motivation would help here. > 5.1 Encrypted Session Key Packet - Traffic Analysis Risk - > The KeyID field, as defined, leads to a major traffic analysis risk, > but the format doesn't depend critically on the value in the field. > At a previous Bay Area Cypherpunks meeting, somebody from PGP > mentioned a request from some freedom fighter users that KeyIDs > be shorter, because the current tyrannical government was > using them to identify who to torture into decrypting messages - > having PGP was incriminating enough, but with short KeyIDs, > e.g. 0-3 or 0-16, it's possible to reduce decryption workload > without indentifying the user of the message. I raised this possibility on the list a few weeks ago, but the only response was negative (I think because it would break the way the keyids were being used as indexes). > Some obvious alternative implementations are to keep the field > for compatibility, while specifying that the > - - the receiver of a message MAY attempt decryption regardless > of the value in the field, regardless of whether > it's intended for him or not. > - - the sender must output a value in the field that > - -- SHOULD be the KeyID, but > - -- MAY be all-0, for which the receiver SHOULD/MAY decrypt > - -- MAY be Z=1-63 bits of leading 0 followed by the low-order > 64-Z bits of the intended recipient's KeyID, which the > receiver SHOULD/MAY decrypt if it matches his KeyID's low bits. > - -- MAY be some other prearranged value, e.g. a multicast code, > which the receiver MAY decide to attempt to decrypt. Interesting possibilities. Jon Callas also suggested (internally) the idea of putting all zeros into the keyid field to mean that the receiver should try all his keys. I would prefer to see a new version of the ESK packet (or PKESK if we want to call it that). One problem we have is that messages encrypted to DH subkeys have only the keyid of the subkey in them, not the keyid of the DSS key. The current PGP client software tries to simplify things for users by not exposing the complexity of the dual-key model, so users only see the keyid of the top level DSS key. Then if they don't have the key for a message recipient, displaying the keyid of the missing key won't match the keyid they see. One solution we've been discussing would be to add some subpacket information to the ESK packet similar to what we have in the signatures. There could be "hint" subpackets to help find the decryption key, like one which tells the keyid of the DSS key. Maybe other hints could be useful too, as we have proposed for the signatures (key server URLs, etc.). This would be for V2. > Since this just requires permission in the spec, rather than > needing specific implementation, and since the main negative impact > on non-implementing users is attempting to decrypt > an occasional message that wasn't intended for them that they > happened to receive, I'd like to ask that it be included. Definately worth considering, at least the all zeros one. The subset one has the obvious problem that there is no specification of the matching length. You may want to send the low order 4 bits of the keyid to use for decryption, but if they happen to be all zeros then you can't do it. > 5.2.2 Version 4 Signature Packet Format > > The format does not contain a KeyID field, and does not > document how to find the KeyID from the various Public Key types -- > there needs to be at least a reference to the section > currently numbered 8.2. There is a keyID field, subpacket type 16, but it got left out of this section by mistake. That should be corrected. > The subpacket stuff is confusing (no surprise, it's new.) > The descriptions of the Hashed and Unhashed subpacket data should be > - - one or more hashed subpackets Actually zero or more > - - zero or more unhashed subpackets > or else these two lines and their preceding lines should be replaced by > - - hashed_subpacket block > - - unhashed_subpacket block > and the definitions of the subpacket blocks (here or in 5.2.2.1) should be > - - Two-octet octet count for following subpacket data. > - - zero or more (un)hashed subpackets Maybe some rewording will help here. We just refer to "subpacket data" where you mention a "subpacket block". > 5.2.2.1 - Signature Subpacket Specification > I'm assuming the "Two-octet octet count" in this section is the > same field as in 5.2.2? (Should be anyway.) Only should appear once. No, it's not. This is the count of the size of one subpacket, while the 5.2.2 count is the size of all the subpackets. > The description up front needs to say something like > - ------------- > Some subpacket types are mandatory, others are optional. > Some subpacket types only apply to self-signatures. > Some subpacket types can appear multiple times, others just once. > Some subpacket types are always hashed, some are always unhashed. > (Are any of them optionally hashed?) > A hashed subpacket MUST be in the hashed_subpacket block, and > an unhashed subpacket MUST/MAY appear in the unhashed_subpacket block. > - ------------- I like the idea of showing this kind of information in tabular form. One quibble is that I'm not sure the optional/mandatory makes sense. I think there could be contexts in which all of them are optional. A signature does not necessarily need a creation date. We don't force them to have expiration dates so symmetry might suggest there are some contexts where a creation date is not appropriate. Also, maybe there is no time source handy for the signer. Signer KeyID could be optional if there was some other subpacket created to help identify the signer (say signer key fingerprint). Or maybe the signer identity is implicit. > It would be nice to reserve some of this space for > user-defined functions, though it's a tossup whether the best mechanism > is to define additional numbers (e.g. reserve 64-127 or 96-127) > or to use the notation data with user-specified values (better?). This was the intention of the notation data subpacket. I've run out of time and steam to do more now. There are many more very good points raised by Bill which we should consider. Hal Finney hal@pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA02168 for ietf-open-pgp-bks; Wed, 3 Dec 1997 08:24:21 -0800 (PST) Received: from geocities.com (mail4.geocities.com [209.1.224.24]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA02163 for ; Wed, 3 Dec 1997 08:24:16 -0800 (PST) Received: from maksim (tun-ad17.tver.fact400.ru [194.87.239.17]) by geocities.com (8.8.5/8.8.5) with SMTP id IAA01494 for ; Wed, 3 Dec 1997 08:25:54 -0800 (PST) Message-Id: <199712031625.IAA01494@geocities.com> Comments: Authenticated sender is From: "Maksim Otstavnov" Organization: home office To: ietf-open-pgp@imc.org Date: Wed, 3 Dec 1997 19:33:52 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: OP and pgp5.0i: some problems Reply-to: maksim@volga.net X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- A set of problems have arisen during the initial testing of 5.0i for Windows in a non-English environment. I believe it is desirable to treat (or at least identify) them in OP, for the benefits of OP worldwide promulgation. 1. "charset" header. [2.4.1 in the November OP Draft] 1.1 "Charset" header needs defining. Values defined in 2.6.xi need enlisting. A mechanism for charsets registration, or embracing charsets otherwise registered needs defining. 1.2 Discussion PGP 5.0 is unable to process correctly armors with "charset" headers other than "noconv" and equivalents. (However, 5.0 doesn't claim 2.6i compatibility, but 2.6). 1.3 Note It would be neat to advise developers (SHOULD?) to set "charset" to "noconv" if related material is pure 7-bit ASCII, regardles of the settings of native 8-bit interpretation in the environment. 2. Clearsigning 8-bit [2.6 in the November OP Draft] 2.1 Discussion 5.0(i) for Windows works with the three exact types of object: (1) files, (2) clipboard text, and (3) data provided by an MUA plugin through API. Right? I cannot test mode (3) now, but the first two (files, with "Text output" on and "Sign clipboard text" from PGPtray) both produce a clearsigned 8-bit text which is in some sence "correct" "Correct" means that resulting file passes signcheck with 2.6.3, ("charset=noconv"), and v.v., clearsigned text produced with 2.6.3 ("charset=noconv") passes signcheck by 5.0(i) (when the known "123-213" bug in 5.0 is fixed). 2.2 Problems with clearsigning There are still problems however. (1) 8-bit clearsigning is not described anywhere (I presume). I strongly believe it needs defining at least as "SHOULD" in OP. (2) "charset" setting is somewhat misleading. For instance, when I sign a 8-bit text content of Windows clipboard, it is usually meaningful in Windows native coding (the so called Windows-cpXXXX, is it described anywhere?), "windows-cp1251" for Russian. But I have "charset" header in sig armor set in "noconv". PGP 2.6.3i (on all platforms) and most other programs interprete "noconv" as equivalent to a native codepage of the receiving system. (In particular, "KOI8-R" extended charset as Russian standard for open systems). (3) If sending MUA is to perform any other (not cryptographic) 8-bit-to-8-bit or 8-bit-to-7-bit transmutation of a msg, the MUA must first do this transmutation, then sign the message, and a receiving MUA must first check signature, then perform any other transmutations. Right? I believe it _is not_ defined anywhere presently. (RFC2015 defines 8-bit-to-7-bit only "normalization"). -----BEGIN PGP SIGNATURE----- Version: PGP 5.0iRu Alpha 2 iQCVAwUBNIVeR3GCEHWOiJDhAQFR8gP8D+hb2n4hRCzL9c0KeRJ8XY4Afa4TVCa7 0WvQNno3KV/oR7d4YCavHxvkC8/2747z8gp7bBpTVK+BZrDxJ6DcaDjrCHeFDasF oSKnGGyIUpe7vHu9xgtWDViDCYJ9GZ1zuti8SG5mbvCV9pVBogpjNUMbMWvOt9ek 0ca1ZuXM8eg= =Raiu -----END PGP SIGNATURE----- -- -- Maksim Otstavnov http://www.geocities.com/SoHo/Studios/1059/ -- -maintainer of The Russian PGP HomePage -- (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html) -- -moderator of "Security&Privacy" (Russian language) Web-forum -- (http://www.rocit.ru/forum) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA09031 for ietf-open-pgp-bks; Wed, 3 Dec 1997 06:15:53 -0800 (PST) Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA09027 for ; Wed, 3 Dec 1997 06:15:48 -0800 (PST) Received: from localhost (mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) with SMTP id JAA14734; Wed, 3 Dec 1997 09:17:30 -0500 (EST) Date: Wed, 3 Dec 1997 09:17:30 -0500 (EST) From: Tony Mione To: ietf-open-pgp@imc.org cc: Tony Mione Subject: Comments on current draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Here are some comments on the first half of draft-ietf-openpgp-formats-00.txt. Some are nits. Take them for what they are worth. 0) Before I start, I will quote from the page header: ... Callas, et. al. Expires May 1998 [Page 1] ^L Internet Draft OpenPGP Message Format Nov 1998 ... ^^^^^^^^OOPS! (I remember....doing the TIME WARP!) 1) There are a few places where the wording suggests and order in which message processing must take place. It would be better to word things such that the implementor can decide order of operations as long as the elements are processed in the correct manner (i.e. hashes are applied to the correct octet string, etc). One example is on page 4, section 2.1: ... Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and attached to the message. Then, the message plus signature is encrypted using a conventional session key. Finally, the session key is encrypted using public-key encryption and prepended to the encrypted block. ... 2) Section 2.2: ... 1. The sender creates a message. 2. The sending software generates a hash code of the message 3. The sending software generates a signature from the hash code using the sender's private key. 4. The binary signature is attached to the message. 5. The receiving software keeps a copy of the message signature. ^^^^^huh? Better: 5. The receiving software decrypts the signature with the sender's public key and saves that hash code. 6. The receiving software generates a new hash code for the received message and verifies it using the message's signature. If the ^^^^^^^^^^^^^^^^^^ verification is successful, the message is accepted as authentic. ^^^^^^^^^^^^^^^^^^^^^^^^^^ Better: 6. The receiving software generates a new hash code for the received message. If the new hash code matches the hash code derived from the signature, the message is accepted as authentic. ... 3) Section 2.6, last paragraph: ... Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. ... Is this text historical? It seems counter intuitive to me to modify the text of a message in any way before signing it. 4) Section 3.3: ... A counted string consists of a length and then N octets of string data. ... How long is the length (1 octet, 2 octets, same length encoding as the packet length calculations in section 4.2)? 5) Section 3.5.3.3: ... count of octets to be hashed = (16 + CMANT) << (CEXP + 6) ... Just curious? Why the constants 16 and 6? 6) Section 5.2.2.2: It would be good to specify which subpackets are required and which are optional (or under which conditions they are required/optional). There are hints in the text, but it would be good to be explicit (perhaps a small table would make this clear). Also: ... {{Editor's note: The above preference (hash algs) is controversial. I included it in for symmetry, because if someone wants to build a ... Why is this controversial? 7) Further down in the same section: ... Regular expression (null-terminated regular expression) (Hashed) ... Which implementation of regular expressions? (See O'Reilly's 'Mastering Regular Expressions') That's all for now. Have fun. Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNIVpp/MKRuSgNA5pAQG2eQL+OgQqIXF1hoGKQ7stPi9LbpRuqj99GeKu cZaKrQji+TeIBDbFbWyTsEVp9LeQh2Wq+Ccu7YbFNZBtJ5blJjqkpwur2D0OmAC0 K9nFjl2EIoMf9VxE3wW9Ec78qLIxtXcd =bZeC -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA07763 for ietf-open-pgp-bks; Wed, 3 Dec 1997 04:28:01 -0800 (PST) Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA07747; Wed, 3 Dec 1997 04:26:57 -0800 (PST) Received: from localhost (mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) with SMTP id HAA14596; Wed, 3 Dec 1997 07:28:36 -0500 (EST) Date: Wed, 3 Dec 1997 07:28:36 -0500 (EST) From: Tony Mione To: ietf-open-pgp@imc.org, ietf-smime@imc.org, pgp-users@joshua.rivertown.net cc: Tony Mione Subject: PGP Implementor's survey : First results snapshot available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I have compiled the surveys returned to me so far. You can find the results from my web page (look for 'IETF involvment') or go directly to the survey page: http://www-ns.rutgers.edu/~mione/openpgp/ I will be updating the page regularly (I am hoping to do this on at least a weekly basis). Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNIVQavMKRuSgNA5pAQFaiAL/ZUt2Sa2WAwQZxU3+Z7u6a9dwQcLeI/Km TVsA88Jj9FTA/Lsr25KxvEIwB37mBOS8Msjls9btt6X4zdFm2PIsRCknrJD5tJsX NtOUK1qjvwYZK9pJjMoO4vuwpS8WhBxl =xWvT -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA07181 for ietf-open-pgp-bks; Wed, 3 Dec 1997 03:42:40 -0800 (PST) Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA07177 for ; Wed, 3 Dec 1997 03:42:37 -0800 (PST) Received: from localhost (mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) with SMTP id GAA14532; Wed, 3 Dec 1997 06:44:18 -0500 (EST) Date: Wed, 3 Dec 1997 06:44:18 -0500 (EST) From: Tony Mione To: ietf-open-pgp@imc.org cc: whgiii@invweb.net, Tony Mione Subject: Re: What is going on?!? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > > Hello, > > Well between a switch in ISP's and a rather hetic couple of weeks I fail > to notice that I had not changed my address for the mail list. I am now in > the process of catching up on +90 messages. > > I am rather disapointed to see the amount of bickering going on over > non-issues. The whole ascii issue has been blown way out of proportion. > It's only a couple of lines of code people spend an afternoon write the > code and be done with it. Shesh!! > I whole-heartedly agree with this! Just make ARMOR a SHOULD and leave it as a 'quality-of-implementation' issue. The code is trivial and the market will drive most implementations to include it before very long. > Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his > rants fill up the pgp newsgroups do we really need him here? > If we want him to go away, we need to consistently ignore him regardless of how inflamatory his remarks are. People like this want some cause to fight for (really, they just want to get other people ticked). If no one is playing the game, it is no fun. He will just pick up his ball and go home (please, please, please). > I saw that someone sugested droping all support of current implemntations > and starting from scratch. I hope this was just a bad joke. > > Well the IETF meeting is next week. I hope that we can get some productive > work done afterwards. > > - -- > - --------------------------------------------------------------- > William H. Geiger III http://users.invweb.net/~whgiii > Geiger Consulting Cooking With Warp 4.0 > Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNIVF8PMKRuSgNA5pAQGa1wL/aHBX/udcn6p5UFbB9jK7aaXhyjQ3VdL7 hBwe88p/0HiwNClAIFIzOP44QtoLrNQt69t4Etn9P6NsuHeftSP0+UnrsP8YsLCh u3LXuxO/4b86MLXKKRCW53SUEBfPR2YM =Gp2V -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA05964 for ietf-open-pgp-bks; Wed, 3 Dec 1997 02:53:01 -0800 (PST) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA05960 for ; Wed, 3 Dec 1997 02:52:56 -0800 (PST) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id EAA14723; Wed, 3 Dec 1997 04:54:07 -0600 (CST) Received: from pax-ca11-01.ix.netcom.com(204.30.66.161) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma014707; Wed Dec 3 04:53:28 1997 Message-Id: <3.0.3.32.19971203025320.0074b3b0@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 03 Dec 1997 02:53:20 -0800 To: IETF OpenPGP , jon@pgp.com From: Bill Stewart Subject: Comments on draft - Long. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- OpenPGP Comments - Bill Stewart, bill.stewart@pobox.com, 12/2/97 Based on 11/97 draft-ietf-openpgp-formats-00.txt , plus some mailing list discussion. =================================================== Structural comment - the draft is a bottom-up document, rather than a top-down document. That generally makes the syntax clearer, in that you never use a FooObject as a component of a BarObject until you've seen the syntax for the FooObject, but it's difficult to use for recursive structures, and it's extremely difficult to do a good job of explaining the semantics, at least when the context and meaning are as closely intertwined as they are here. I say this partly as a call for careful, clear writing, and partly as an apology for stuff I get wrong because I don't quite follow it :-) ==================================================== Major missing capability - support for Stealth formats. I suppose that, since I haven't written up a proposal by now, I can't complain (:-), but it'd be nice to leave this open for OpenPGPv2 or something. ============= Various packed number formats - it's probably cleaner to describe these up front, or at least before they're used. ============= 3.3 Counted Strings - "A counted string consists of a length and then N octets of string data" How long is the length field? What's its format? I'm guessing it's one of the various variable-length-packed-number formats used in PGP, but you need to specify which one. 3.4 Time Fields - Y2038 problem - Also 5.2.2.2, 5.5.2. 5.9 Using Unix-style "seconds since 1970" dates as the only format is not a bright thing to do in 1997.... A couple of alternatives: a) Define a new format, like "yyyymmdd,milliseconds of day" or "microseconds since 1AD/01/01/00:00:00" (easy fit in 64bits) or "yyyymmddhhmmss.nanosec", that'll be good for all reasonable applications (are microseconds enough??) b) Time values below 10,000,000 are days since 1AD/01/01 (assumes 1 day granularity is enough, and no PGP in first 115 days of 1970 :-) Or hours since 1AD/01/01/00:00:00. (Another packed number format - sigh :-) c) At very minimum, make the times modulo-2**32, with values assumed to be later than ~1990, and validity intervals adjusted appropriately. That still limits you to 68-year usage, or 34 for safety, which is unfortunately a real problem for long-term e-commerce. d) Use the notation field in signatures if you really care... There's also the problem that times can't be trusted, so you shouldn't depend on them too strongly. 3.5.1.3 / 3.5.3.3 Iterated-Salted What a blazingly ugly design! Is it really necessary to use a byte-count in a special one-octet-floating-point format, rather than using an iteration count? Probably saves one multiplication when preparing the argument for a hash, at the cost of a couple masks and shifts and adds a hunk of code. Especially with the "Conventionally Encrypted Session Key" available, the extra complexity seems unnecessary. If anybody's really using this option, it probably should be kept, but as a MAY read, DEPRECATED generate. Otherwise reserve the S2K-type indicator 0x03 and drop it. 4.2 Packet Headers - Packet Length. I'd rather have seen a cleaner format for the length, but that's a job for OpenPGPv2 to clean up. (In particular, I'd like to see a format that allows for padding to multiples of 4 or 8 octets.) Meanwhile, it appears that the Partial Body Length can support indefinite-length material, which is critical, since it allows PGP to be used with streaming input such as speech that goes on for a long time, (though the particular encoding is inefficient if the data comes in natural chunk sizes that aren't powers of 2 (or at least 3*2**n), or compresses to irregular sizes.) It's worth noting this kind of application in the draft, to encourage OpenPGP implementations to be designed in ways that aren't limited by temp files with maximum lengths. 4.3 Packet Tags / 5.1 Encrypted Session Key Packet - (nitpick) should "Encrypted Session Key Packet" be renamed "Public Key Encrypted Session Key Packet" now that there's also a "Conventionally Encrypted Session Key Packet"? Also, the "Name Packet" (Tag 13) is yet another packet that's later called a "UserID Packet". My personal preference is to call it a "User Data Packet" - see 5.11 for discussion. 5.1 Encrypted Session Key Packet - Traffic Analysis Risk - The KeyID field, as defined, leads to a major traffic analysis risk, but the format doesn't depend critically on the value in the field. At a previous Bay Area Cypherpunks meeting, somebody from PGP mentioned a request from some freedom fighter users that KeyIDs be shorter, because the current tyrannical government was using them to identify who to torture into decrypting messages - having PGP was incriminating enough, but with short KeyIDs, e.g. 0-3 or 0-16, it's possible to reduce decryption workload without indentifying the user of the message. Some obvious alternative implementations are to keep the field for compatibility, while specifying that the - - the receiver of a message MAY attempt decryption regardless of the value in the field, regardless of whether it's intended for him or not. - - the sender must output a value in the field that - -- SHOULD be the KeyID, but - -- MAY be all-0, for which the receiver SHOULD/MAY decrypt - -- MAY be Z=1-63 bits of leading 0 followed by the low-order 64-Z bits of the intended recipient's KeyID, which the receiver SHOULD/MAY decrypt if it matches his KeyID's low bits. - -- MAY be some other prearranged value, e.g. a multicast code, which the receiver MAY decide to attempt to decrypt. Since this just requires permission in the spec, rather than needing specific implementation, and since the main negative impact on non-implementing users is attempting to decrypt an occasional message that wasn't intended for them that they happened to receive, I'd like to ask that it be included. 5.2 Signature Packet ===== documentation comments This section deals with some of the most complex parts of PGP. It needs to address where the signature packets fall in the grand scheme of things, e.g. needs enough BNF here or elsewhere to say Signed_Thing::= Signed_Key | Signed_Doc | One_Pass_Signed_Doc Signed_Key ::= one Public Key Packet (Tag 6) FOLLOWED BY one or more Signature_Packet(Tag 2) Signed_Doc ::= one Signature_Packet(Tag 2) FOLLOWED BY one Data_Packet Data_Packet ::= Compressed_Data_Packet(Tag 8) | Literal Data Packet One_Pass_Signed_Doc::= one One_Pass_Signature_Packet(Tag4) FOLLOWED BY one Data_Packet FOLLOWED BY one Signature Packet (Correcting this as needed.) It also would be nice to put some of the semantic issues in the front section here - at very least, the definition of "self-signature". Also, while PGP 2.6.2 uses Version 3 Signature Packets, either section 5.2 or 5.2.1 should indicate that it only supports RSA and not also the DSA signatures. === proposed semantic issues for 5.2: Implementations SHOULD support generation of V3 signatures, and PROBABLY (??) SHOULD generate them when encrypting to RSA keys, or at least RSA keys received from a Public Key Packet Version 3. Implementations SHOULD NOT generate V3 signatures for non-RSA keys? 5.2.2 Version 4 Signature Packet Format The format does not contain a KeyID field, and does not document how to find the KeyID from the various Public Key types -- there needs to be at least a reference to the section currently numbered 8.2. The subpacket stuff is confusing (no surprise, it's new.) The descriptions of the Hashed and Unhashed subpacket data should be - - one or more hashed subpackets - - zero or more unhashed subpackets or else these two lines and their preceding lines should be replaced by - - hashed_subpacket block - - unhashed_subpacket block and the definitions of the subpacket blocks (here or in 5.2.2.1) should be - - Two-octet octet count for following subpacket data. - - zero or more (un)hashed subpackets 5.2.2.1 - Signature Subpacket Specification I'm assuming the "Two-octet octet count" in this section is the same field as in 5.2.2? (Should be anyway.) Only should appear once. The description up front needs to say something like - ------------- Some subpacket types are mandatory, others are optional. Some subpacket types only apply to self-signatures. Some subpacket types can appear multiple times, others just once. Some subpacket types are always hashed, some are always unhashed. (Are any of them optionally hashed?) A hashed subpacket MUST be in the hashed_subpacket block, and an unhashed subpacket MUST/MAY appear in the unhashed_subpacket block. - ------------- The header format description is clumsy, and should be restructured. Replace the - subpacket type (1 octet): If bit 7 is set, subpacket understanding is critical, with - subpacket_type_and_criticality_flag (1 octet) bit 7 - Criticality Flag bits 6-0 - subpacket type. I'd recommend that the table of subpacket types indicate which of these attributes apply to it, e.g.: - -------------- 2 = signature creation time, (hashed,mandatory,once) 3 = signature expiration time, (hashed,optional,once) 4 = exportable, (hashed,optional,once) 5 = trust signature, (hashed,????,????) 6 = regular expression, (hashed,optional,once) 7 = revocable, (hashed,optional,once) 9 = key expiration time, (hashed,optional,once,self) 10 = reserved for PGP use (hashed,optional,multiple,self) 11 = preferred symmetric algorithms, (hashed,optional,once) 12 = revocation key, (hashed,optional,????,self) 16 = issuer key ID, (unhashed,mandatory,once) 20 = notation data, (unhashed,optional,multiple) 21 = preferred hash algorithms, (hashed,optional,once) 22 = preferred compression algorithms, (hashed,optional,once) 23 = key server preferences, (hashed,optional,once,self) 24 = preferred key server hashed,optional,once,self) - ------------ Semantics Question - is support for optional subpacket types MUST? or only SHOULD or MAY? Is support for types not defined here MAY or MUST NOT? It would be nice to reserve some of this space for user-defined functions, though it's a tossup whether the best mechanism is to define additional numbers (e.g. reserve 64-127 or 96-127) or to use the notation data with user-specified values (better?). The Criticality Flag stuff is confusing. I think I understand it better now than I did before, so here's what I think it means (and if I'm wrong, I hope somebody will rewrite it so it sinks in next time:-) The Criticality Flag is a request from the signer to the recipient's OpenPGP implementation for strict semantic support for optional and undefined subpacket types. If the recipient's implementation does not recognize or recognizes but does not implement a subpacket type for which the signer has set the Criticality Flag - For a Signed_Doc or One_Pass_Signed_Doc, the implementation ? SHOULD ignore the Criticality Flag ? SHOULD use the implementation-defined bad-signature handling response. - For a Signed_Public_Key, Define a Valid Self-Signature as The packet contains an Issuer KeyID subpacket, The implementation must calculate the Key's KeyID The Issuer KeyID matches the Key's KeyID The implementation must calculate the signature for the public key packet, using the public key, as described in Section #.## The calculated signature matches. Depending on whether the signature is a self-signature, - If the Signature Packet is not a Self-Signature, --- the implementation SHOULD discard the Signature Packet --- the implementation SHOULD invoke error-handling - If the Signature Packet is a Valid Self-Signature, --- the implementation MUST? discard the Signature Packet --- the implementation SHOULD? invalidate the entire key that the Signature signs, at least if it's a brand-new key --- the implementation SHOULD NOT? continue to use the key, at least if it's new. --- the implementation SHOULD invoke error-handling - If the Signature Packet is an INVALID Self-Signature, the implementation MUST discard the signature but PROBABLY SHOULD NOT? invalidate the key, unless it's a brand-new key. 5.2.2.2 Signature Subpacket Types (it'd be nice to number these, especially since you've got numbers :-) I've already discussed Y2038 problems above, so assume they apply here as well. - - Signature Creation Time - MANDATORY? Or MAY this be optional, at least for environments like smartcards that may really not know what time it is. - - Preferred {sym,hash,comp} - array of one-octet values The syntax for an array needs to be specified! Is it "Some counter field and COUNT octets"? Or "Null-terminated bunch of octets"? - - Exportability - needs a definition of export/import. - - Trust Signature - this invokes a bunch of complex semantics, which aren't explained very deeply in the one paragraph. If they're defined stably enough to really belong in this document, they should either be described here, or (better) in an appendix, or There should be a pointer to some document elsewhere that explains what all this "meta-introducer" stuff is about and why it's different from simply being one signature higher up the food chain. - - Additional Recipient Request - the community seems to have stabilized on the view that this should be Reserved For Use. - - Notation Data - I'm unclear on the flag syntax. Is it - First Octet - ALWAYS 0x80 or RESERVED 2nd-4th Octets - 0x00, Reserved, MUST ignore - or - First Octet - 0x00 or 0x80 or implementation-defined 2nd-4th Octets - implementation-defined I'd prefer the latter. Also, since this is an obvious extension mechanism for software, we ought to define some way to specify that the Notation is intended for implementation-defined software use. Perhaps 0x00 - Something special 0x80 - Human-readable, non-software 0x01-0x7f - Reserved for future OpenPGP use 0x81-0xff - user-defined - - Preferred Key Server - Currently self-signature only - I suggest we also permit this for non-self-signatures, so signers can indicate where they serve their keys and maybe even where they store revocation certificates. - - Key Server Preferences - I'm guessing a more functional definition would be something like - No-Modify - Key Server SHOULD NOT change any data in the key server records for a key that sets this field. - - [Unclear context:] Implementations SHOULD implement a "preference" and MAY implement a "request." ? It's not clear to me what this statement is referring to. The "preferences" indicated above were the hash/symmetric/public algorithms and the key servers; the only "request" I saw was the "Additional Recipient Request". It's also not clear what it means - does it mean that implementations SHOULD implement the ability to accept input packets containing preferences (perhaps obeying them), and MAY implement the ability to generate output packets containing the preferences? - - JDCC Note - specifying negative preferences - Is specifying only Triple-DES good enough? Or should we do something hokey like making algorithm numbers 128-255 (or -1 - -128) indicate that you really don't want alg&0x80 (or -alg)? I lean towards the former, especially since there are MUST defaults available, though it would be nice to say CAST5,IDEA,-3DES so that the sender whose preferences are 3DES,Blowfish,DSASubliminal,CAST5 will know to pick CAST5 even though she likes 3DES better. That's too subtle, though. Perhaps the negotiation rule should be Sender SHOULD pick the algorithm supported by both sender and receiver that the receiver prefers, but MAY selfishly pick any algorithm supported by both sender and receiver. - - JDCC Note - revoking user name / user data - there isn't enough context at this point in the document to indicate that - we've only had hints and allegations that there really are user data packets that are signed :-) So it needs to be later in the document. - - JDCC Note - PGP3 other subpacket types - did it go as far as specifying the subpacket numbers or subpacket names? Should we reserve those numbers now? e.g. 42 - answer subpacket - reserved for later - - 5.2.3 Signature Types - - - JDCC Note - What should we do about defined-but-not-implemented types? These types 0x11-0x13 follow the "UserID Identifies A Body" model, rather than the more general "Key Asserts Some Attribute" model that folks like Carl Ellison have advocated (which I prefer.) (See comments on 5.11 suggesting calling it "User Data".) I'd recommend that we do one of two things: 1) Junk them now, stick to generic certifications, and use either notations subpackets or other as-yet undefined subpacket types to indicate special attributes of signatures. We've got enough syntactical hooks already. 2) Define more syntactical hooks :-) Keep them, and also reserve 0x14-0x1f for signature types: implementations SHOULD/MAY accept Signature types 0x10-0x1f as signatures on keys, MAY handle them specially, and MAY output them (if there's a good reason.) Alternatively (now that I've ranted against the critical bit :-), SHOULD accept 0x10-0x17, SHOULD reject unrecognized 0x18-0x1f, or maybe keep 0x10-0x1f for signatures you SHOULD accept and 0x80-0xff for user-defined signature types which should be rejected if unrecognized. - - JDCC Note - Timestamp Signatures? - Reserve for future use? I'm not sure how a timestamp signature is different from any other document signature, since there's already a timestamp in the signature field. Sounds like a better job for a notation? But somebody may make a good argument to the contrary. Also, it's a bit odd that compressed data fields don't have timestamps in them but literal data fields do. - - JDCC Note - Key-only signature that doesn't cover user name - I'm not sure what the semantics of this are, except perhaps they're useful for self-signatures or binding notation-based attributes to the key. You could just as well sign a key with the user name and ignore the user name when using the key? On the other hand, if you want the feature, it probably needs to be a separate signature type so you know not to include the hash of the user name. - - 5.3 Conventionally Encrypted Session Key (Tag 3) It's a bit disappointing that this uses an all-zero IV, but it's presumably already implemented. The problem is that it gives an octet of relatively-well-known plaintext in the encrypted session key - the algorithm ID. It's not much use for a Bad Guy, but it's there. - - 5.5 Key Material Packet Some good BNF descriptions would really help here. - - 5.5.2 - Public Key Packet Formats Implementations SHOULD accept V3 public key packets and MUST accept V4 public key packets? Another minor weakness with V3 keys is that the validity period is limited to 64k days (assuming unsigned short?), and some applications may find 200 years a bit limiting :-) More importantly, it doesn't allow defining keys with very short expiration times, e.g. 1 hour or 30 seconds. V4 keys - The Y2038 problem is here too... - Is this a good place to specify that implementations MUST support DSA and El-Gamal, and SHOULD support RSA? - - 5.5.3 - Secret Key Packet Formats - Does this belong in the standard? Is the Secret Key Packet ever transmitted outside the implementation? Or is it really an implementation detail that doesn't need to be part of a standard? I agree that it's convenient to read your PGP Version N secret keyring with PGP Version N+1, but to me that only rates a SHOULD and not a MUST. In particular, there may be environments in which the applications don't store their secret keys in files, and don't transmit them to anyone, especially for transient communications applications, and there are applications that want more security than the standard PGP implementation uses for storing its secret keys (e.g. the UserName is visible in the secret key ring.) Also, there may be applications that only need to verify signatures, or only need to public-key encrypt data, or maybe even only need to symmetric-key encrypt data, but don't need to public-key decrypt or sign data, and it would be nice for them to say they're OpenPGP compliant. - Does "CFB" refer to standard CFB, or PGP-hacked CFB-variant? - - 5.6 - Compressed Data Packet (Tag 8) According to section 7.2, a Compressed Data Packet should be decompressible into a valid OpenPGP message, while this section only specifies that it contain an RFC1951 DEFLATE block containing "some set of packets". The spec should state at this point that the contents of the DEFLATE block must be a valid OpenPGP message, or more precisely, that an OpenPGP program writing a Compressed Data Packet MUST use a valid OpenPGP message as the contents, and that an OpenPGP program reading a Compressed Data Packet SHOULD assume that the decompressed contents are valid and attempt to interpret them. - - 5.7 - Symmetrically Encrypted Data Packet (Tag 9) Will this packet _always_ contain either a literal or compressed? Or will it at least always contain some PGP packets? (For instance, you might use it to encrypt secret keys....) Should OP be _required_ to always interpret any PGP packets in it? - - 5.8 - Should this now say "NA" or "OP" or "McAfee" :-) - - 5.9 - Literal Data Packet (Tag 11) - Is it "__CONSOLE" or "_CONSOLE" (I assume one _, but it's easy for underscores to get kerned together.) - Perhaps the example should mention displaying on a CRT as well as not saving it on a disk? - Y2038 time problems again. - The semantics are arbitrary and the syntax doesn't indicate which choice was the sender made here - if anyone cares. - Implements SHOULD NOT believe what they read :-) - - 5.10 - Trust Packet (Tag 12) Since these packets aren't exported and shouldn't be imported, it's not clear this belongs in the standard. The trust packet and the trust signature subpacket in 5.2.2.2 both have complex semantics that aren't very well documented. At least these are internal-use only, though, so who cares? I agree that they should be implementation-dependent. I also agree that the trust packet should be signed by the user - but the standards document has not yet told us where the trust packet is syntactically - is it attached to one key, in which case there's a key to self-sign with? Is it free-floating in the public key file (more likely)? (In which case there's no "self" to self-sign them...). It's even worse than it appears - other people's public keys are used in a context where you're either encrypting to them, or checking the validity of their signatures, so there's no need to use anybody's private keys to be able to check against, and the instance of PGP may not even have any private key at all. An implementation might require a private key to unlock a secret key ring without too much annoyance, but doing so to unlock the pubkey file seems a bit paranoid. - - 5.11 - UserID / UserName / User Data I'd suggest the term "User Data". Unlike "User ID" or "User Name", it doesn't imply the "True Name" or "One Key, One Body" model of how public keys are used - but it does imply that the data is picked by the user, which is not only a less authoritarian model, but more reflective of reality than some of the other terms. It also makes it potentially less clear what the certifier is certifying, but that also reflects reality. Requiring UTF-8 is probably not bad - we need to be sure the field always gets protected if it's being transmitted across non-8-bit-safe media, which gets back to the armor-vs-mime wars. We should at least require that a conforming implementation MUST NOT munge the string except in automatically reversible ways (such as MIME-Quoted-Printable or armoring the whole thing), and should do any key-related transactions in full-8-bit. There is one security-related problem of permitting arbitrary characters - users can put newlines in their key strings, or backspaces, or ANSI terminal-control escape sequences, or other things that can encourage the user interface to lie to the unsuspecting recipient. Banning those might be good. - - 6.1 - Public-Key Algorithm Constants Elliptic Curve - Yeah, they probably deserve some numbers. Perhaps reserve 20-29 for future Elliptic Curve. Leaving ElGamal signatures unmentioned is probably good, but if you want to use them, anybody seeing the "16" for ElGamal in a signature context ought to get the idea. ElGamal signatures and DSA signatures both have subliminal channel problems; perhaps we should allocate some symmetric-key algorithm identifiers for those :-) - - 6.2 - Symmetric-Key Algorithm Identifiers By the way, how DOES PGP generate 3-key 3DES keys, since 168 bits of key is just bigger than a 160-bit hash? Or does it use 2-key only? S2K is limited to the hash length. - - 7 - Packet Composition My preference is to have this section up front. - - 7.1 - Transferable Public Keys The BNF needs to be beefed up. In particular, if each Subkey can be followed by one or more revocation sigs as well as one or more normal signatures. Also, are the signatures on the Subkeys required? Are they required to be self-signed by the preceding public key? Again, my recommendation of the term "User Data" for "UserID". JDCC's note near the end of section 5.2.2.2 on revocable User Data is in scope at this point. The syntax looks very clearly like a revocation signature immediately following the user data would apply to that data, rather than to the whole key, and it calls for zero or more packets so there's clearly room. The catch is making sure the implementation doesn't choke when seeing a revocation instead of either a signature or a subkey. I would definitely recommend that if a implementation sees a revocation sig immediately following a User Data field, that it MAY/SHOULD revoke that User Data, though the meaning of "revoke" may not be precisely defined. :-) On the other hand, it's probably too early to generate such (certainly needs testing with popular implementations first.) On the other hand, there's the operational queston of what revoking a User Data means. It probably means that PGP should notify the user before trying to use that key with that name. But signatures are signed by keys, not by names, so rejecting signatures by that key when there are other User Data fields active is a mistake. And PGP 5.0 doesn't always tell you who signed some key anyway. If a Key/UserData pair is signed by a certifier's key, and you receive a revocation for that UserData signed by the certifier's key, you SHOULD discard or ignore the certification. - - 7.2 - BNF should go a layer or two deeper. - - 8 Key Formats - This appears to overlap substantially with 7.1. Why both? Also, 7.1 permits zero or more subkeys, while 8 V4 requires one. Can the number be zero? Or more than one? - - 8.2 KeyIDs and Fingerprints Probably should also repeat the V3 fingerprint format here. It's also worth noting that the KeyID and fingerprint are both calculated rather than stored in the data; implementations may choose to cache this information for internal use, though there's no mechanism for export/import, and keyservers would definitely want to. - - 9 - Security Considerations Traffic analysis should be mentioned here, since PGP does little to stop it and doesn't have stealth built in. Talking about the fingerprint hacks may be useful here. =============================================================================== = -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQBVAwUBNIU6H/thU5e7emAFAQGOVAH7BWXLYorrBwaXohonVC1cg0R53nMgOrX1 PfvQ0EcmEIhjqf3GJ8Z7cL5z98oT3Gl5BN8+rR7+iN3/S+EfZezf2w== =fzBe -----END PGP SIGNATURE----- Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA02447 for ietf-open-pgp-bks; Tue, 2 Dec 1997 23:32:08 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA02443 for ; Tue, 2 Dec 1997 23:32:04 -0800 (PST) Received: from users.invweb.net (cppp21.dotstar.net [208.143.93.121]) by users.invweb.net (8.8.7/8.8.7) with SMTP id CAA15025; Wed, 3 Dec 1997 02:33:40 -0500 Message-Id: <199712030733.CAA15025@users.invweb.net> From: "William H. Geiger III" Date: Wed, 03 Dec 97 00:06:06 -0600 To: Ian Grigg In-Reply-To: <34786ED3.13100E24@systemics.com> Cc: ietf-open-pgp@imc.org Subject: Re: why MIME in the standard? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <34786ED3.13100E24@systemics.com>, on 11/23/97 at 12:58 PM, Ian Grigg said: >Adam Back wrote: >> Doesn't seem like a big deal implementation-wise -- the complexity >> saving of removing the checksum probably more than compensates for >> having to output and parse a fixed Content-Type: string. >I don't think it is a big deal implementation-wise either. It is >deployment that is my concern. Changing all those servers over, changing >all the scripts over, upgrading all pgp script copies to handle mime >because they can no longer get the AA keys from where ever they got them >from before. >All those interoperability issues can be solved in one of two ways: by >having one software source (as in pgp2.6 up to nowish) and by having a >standard that insists on interoperable feature sets. >We write standards to solve the problem of interoperability in the >absence of common source. We do not write standards to make it easier to >implement, except as a secondary opportunity. >As interoperability is the issue, IMNSHO, and everything that is out >there with the label PGP attached to it uses Armour, then Armour it is. >Add MIME to the standard if we believe this is the "way to go" by all >means. But that's in the opportunity basket, not the interoperability >basket. People like Dave Crocker are going to be possible proven "right" >by events here But this is small change compared to the cost of >breaking the current user base, no matter how "wrong" it might be. I think that there is another issue regarding Ascii-Armor that is beeing missed. That of compatability between OpenPGP implementations. While most of the debate has centered around providing backward compatablity with the current user base I have some concers regarding future implementations. What is going to happen when OpenPGP from vendor A sends a rfc822 clearsigned message to OpenPGP from vendor B who has not implemented the Ascii-Armor code?? You could add a large set of preferance codes to the public key outlining the capabilities of the various implementations but this restricts portability of keys between implementations. Also it only is vaible in a one->one communications. In a one->many environment (which PGP is quite frequently used) you need a core set of functions that ALL implementations support. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNIULFo9Co1n+aLhhAQLqZAQAw1raIQBNKmez9FabQ9VqXqQfUUzmtLWx za5xHMRNcER1OUY1qZVFNzcyM944lgDwvWO7cpOflGtCDUJGp2gEKRHQceq/FqaG 6I1jrQ93zTVXGchumoYqcC41+3bgs8O/yIj4E7ghfvDMPTAJjHLoEL/iIEntOdMC aSeZFsveUZI= =LmVg -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA02442 for ietf-open-pgp-bks; Tue, 2 Dec 1997 23:32:04 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA02437 for ; Tue, 2 Dec 1997 23:31:59 -0800 (PST) Received: from users.invweb.net (cppp21.dotstar.net [208.143.93.121]) by users.invweb.net (8.8.7/8.8.7) with SMTP id CAA15020; Wed, 3 Dec 1997 02:33:21 -0500 Message-Id: <199712030733.CAA15020@users.invweb.net> From: "William H. Geiger III" Date: Wed, 03 Dec 97 00:40:07 -0600 To: Ian Grigg In-Reply-To: <3479420D.27A54854@systemics.com> Cc: ietf-open-pgp@imc.org Subject: Re: PGP evolving, improving X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3479420D.27A54854@systemics.com>, on 11/24/97 at 03:59 AM, Ian Grigg said: >As I recall, the flaws are: > * create an arbitrary ID, and therefore spoof a key server > * create a key with the same fingerprint as another, under > some conditions, and thus spoof the server/key. >For more detail, check out Gary's HIP-paper on >http://www.hotlava.com/doc/fag-pgp/ I should note that PGP Inc have >stated that all but one of the issues was known and fixed. >So there are problems with the old PGP system. But, and it's an >important but, these (key) problems only effect keyservers in general. >As most people don't use key servers, this is not a tremendous problem, >and certainly not justification for dropping the old formats. It is of >course more important to PGP Inc as their products use key servers >automatically. It is also possable to create a key that spoofs *both* keyID & keyFingerprint. With the old formats the only sure way for verifying a key was to take the size, keyID, & keyFingerprint. There was another spoof that I came across (last year I think) dealing with the display of key information by PGP. The reason I bring this up as it is somthing to look out for when displaying key data to the user. I have attached a copy of the key to this message. OK I found my post to the coderpunks list: ========================================================================= Hi, While doing some analysis on the BAL server keyrings I cam across this PGP key that may be of intrest: - -- Type Bits/KeyID Date User ID pub 512/37CD5C41 1994/08/16 Big, Important Person sig 38D011C8 Trusted Introducer Key fingerprint = C4 8A BB 58 B1 A6 53 6F 21 AD 45 84 50 1D AA 6C What is intresting about the key is it has not been signed even though a signature is shown from a pgp -kvvc output! How was this done?? The clever creator of this key formated his userid in such a way that when displayed it would look like there was a valid signature for the key. The entire "sig" line is really part of the userid for the key. I have attached a copy of the key if anyone is intrested at looking at how it was created. For some of my scripts I had been parsing the output of PGP to build information on the keys in the keyring. Since then I have switched to extracting the data directly from the keyring. It was while I was testing this new code that I came across this key. Glad I switched methods :)) ========================================================================= >As to the MD5 weakness, yes, you are correct there: theoretical >weaknesses do not mean an unseemly dumping of the existing user base is >warranted. I have a patched version of PGP 2.6.x on my web site that allows it to use the SHA1 hash. I also fixed a "feature" in 2.6.x where if a message was encrypted with RSA but signed with an unknown algorithm it would fail not only the signature verification but the decryption too! The patched version will now decrypt the messages and warn of a verification failure. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- begin 666 tmp.pgp MF0!-`BY1%KT```$"`+FM2B,)5OW:<+4FOYUB!BH]G-@X6`>$N[EKT1.+*Y/\ MA?XH_K99!_=!; Tue, 2 Dec 1997 21:13:00 -0800 (PST) Received: from users.invweb.net (cppp21.dotstar.net [208.143.93.121]) by users.invweb.net (8.8.7/8.8.7) with SMTP id AAA13775 for ; Wed, 3 Dec 1997 00:14:25 -0500 Message-Id: <199712030514.AAA13775@users.invweb.net> From: "William H. Geiger III" Date: Tue, 02 Dec 97 22:57:36 -0600 To: ietf-open-pgp@imc.org Subject: What is going on?!? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hello, Well between a switch in ISP's and a rather hetic couple of weeks I fail to notice that I had not changed my address for the mail list. I am now in the process of catching up on +90 messages. I am rather disapointed to see the amount of bickering going on over non-issues. The whole ascii issue has been blown way out of proportion. It's only a couple of lines of code people spend an afternoon write the code and be done with it. Shesh!! Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his rants fill up the pgp newsgroups do we really need him here? I saw that someone sugested droping all support of current implemntations and starting from scratch. I hope this was just a bad joke. Well the IETF meeting is next week. I hope that we can get some productive work done afterwards. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNITqc49Co1n+aLhhAQLWiAP/WExnwfcGuF0azDb9V8c/0KEnuCqI/st4 QjWQyyEAcHOqklnARswyTleYslnUpU/s04dsmnkXFK5cga/aDwVxW+fUrXaHIZT8 YETHmhUb2FMLuTgwJM5Wxb3XRPQ98ScVVWFZMQ2YMuHpgsPf/hJC4c6eW8qwuDTO B3A1gFOGMX8= =BnH7 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA00928 for ietf-open-pgp-bks; Tue, 2 Dec 1997 20:38:47 -0800 (PST) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA00924 for ; Tue, 2 Dec 1997 20:38:42 -0800 (PST) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [202.232.2.201]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id NAA12977 for ; Wed, 3 Dec 1997 13:40:18 +0900 (JST) Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id NAA27822 for ietf-open-pgp@imc.org; Wed, 3 Dec 1997 13:40:19 +0900 Received: from localhost by h2np.suginami.tokyo.jp (NX5.67c/IIJ-U1.2c) id AA08543; Wed, 3 Dec 97 13:37:01 +0900 Message-Id: <9712030437.AA08543@h2np.suginami.tokyo.jp> To: ietf-open-pgp@imc.org Reply-To: hironobu@h2np.suginami.tokyo.jp Subject: new algorithm identifier of the symmetric cryptosystem. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Wed, 03 Dec 1997 13:37:01 +0900 From: Hironobu Suzuki Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I'd like to know who is control the algorithm identifier of the symmetric cryptosystem. I hacked GOST and BLOWFISH into PGP but still buggy. The algorithm identifier of GOST as FOUR(#4) and BLOWFISH as FIVE(#5) were assigned for my hacked PGP. You may get patch file for pgp50i-b8 from URL://www.pp.iij4u.or.jp/~h2np/pgp Note: THIS IS NOT FOR ANY OFFICIAL OR UNOFFICAL VERSION OF PGP. IT'S A KIND OF JOKE. DON'T BE A SERIOUS. If the algorithm identifiers which I assigned make a trouble, I remove my patch file. HAPPY HACKING! ========= PGP Message Exchange Formats 5.1.3 Secret key packet ..... The algorithm identifier of the symmetric cryptosystem is zero for unencrypted (should only occur in not pagable memory), one for IDEA, two for 3DES-EDE, or three for CAST5. ..... ========= -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.suginami.tokyo.jp URL://www.pp.iij4u.or.jp/~h2np Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA00590 for ietf-open-pgp-bks; Tue, 2 Dec 1997 20:09:41 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA00586 for ; Tue, 2 Dec 1997 20:09:37 -0800 (PST) Received: from users.invweb.net (cppp21.dotstar.net [208.143.93.121]) by users.invweb.net (8.8.7/8.8.7) with SMTP id XAA12922; Tue, 2 Dec 1997 23:10:21 -0500 Message-Id: <199712030410.XAA12922@users.invweb.net> From: "William H. Geiger III" Date: Tue, 02 Dec 97 22:08:03 -0600 To: David Sternlight , Dave Del Torto , Adam Back , Ian Grigg , Uri Blumenthal , ietf-open-pgp@imc.org In-Reply-To: <34834529.1034562@sternlight.com> Subject: Re: [LISTBIZ] A Point of Order X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- David, David, Daivd, I hope Jim is paying you well for your years of service. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNITbb49Co1n+aLhhAQJPUQQAmNj6ru54v43HcUgmX/Qob0FTAr0R6Qj2 gymlAUWLQHk8p6d0zpW05zhn0+Sbk8BzmsmVaYCwyKwDC7AuqsK+5QxI6whnlrv+ 41I2BFboWcHAHO7vRIiPwvuzGaB6LYwvG4X+VPxHBMImeIVOlL5+MN1G+rsTB6rv fM29locD/HI= =FbCh -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA20820 for ietf-open-pgp-bks; Tue, 2 Dec 1997 09:38:19 -0800 (PST) Received: from rtp1.intrex.net (rtp1.intrex.net [209.42.192.253]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA20813 for ; Tue, 2 Dec 1997 09:38:15 -0800 (PST) Received: from BOX1.none (unverified [209.42.199.167]) by rtp1.intrex.net (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 02 Dec 1997 12:39:18 -0500 Message-ID: X-Sender: jbhoward@rtp1.intrex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Release Candidate 3 Date: Tue, 02 Dec 1997 12:39:38 -0500 To: ietf-open-pgp@imc.org From: James Howard Subject: rhetoric Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Let me cut through all the rhetoric with two simple analogies. typical. "Let me finish this pointless discussion by bringing up two more pointless discussions." DAVID, GO AWAY. To paraphrase Stuart Smalley, you're not good enough, you're not smart enough, and people really don't like you. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA20661 for ietf-open-pgp-bks; Tue, 2 Dec 1997 09:30:55 -0800 (PST) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA20651; Tue, 2 Dec 1997 09:30:49 -0800 (PST) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id LAA04654; Tue, 2 Dec 1997 11:25:07 -0600 (CST) Received: from lax-ca69-32.ix.netcom.com(207.223.161.160) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma004602; Tue Dec 2 11:24:44 1997 Message-ID: <34844458.2820831F@sternlight.com> Date: Tue, 02 Dec 1997 09:24:42 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: amg@lcc.uma.es CC: ietf-smime@imc.org, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? References: <01bcfe7a$f7483120$9d07a8c0@pbaker-pc.verisign.com> <3482FCC0.46DC7756@sternlight.com> <3483ED99.5E3038C5@sol10.lcc.uma.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Antonio Mana Gomez wrote: > > You mean that we should be glad that the company that produced the > browser has saved us the effort of finding who to trust, registering, > configuring and all those tedious procedures? Let me cut through all the rhetoric with two simple analogies. They are intended to be heuristic, not syllogistic. Hopefully they will close this sub-discussion. 1. Web of trust is like trusting a friend, without which personal relations would be difficult. People aren't going to get a Visa logo on their foreheads for this. Open PGP developers should, I assert, focus on maximizing their model's efficiency and ease of use for this model and not try to move further to a mixed model. 2. Rigid hierarchical is like the major credit card certifiers, without which effective transaction systems at scale would be difficult. People aren't going to roll their own credit cards for this. S/MIME 3 developers should, I assert, focus on maximizing their model's efficiency and ease of use for this model and not try to move further to a mixed model. Each has its place. Corrupting either leads to its losing some of its unique advantages. For instructive details consult any good text on the evolution of national banking systems, or the appropriate chapters in introductory economics texts. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA18955 for ietf-open-pgp-bks; Tue, 2 Dec 1997 08:06:28 -0800 (PST) Received: from lists.Commerce.Net (lists.commerce.net [207.96.25.228]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA18869; Tue, 2 Dec 1997 08:00:38 -0800 (PST) Received: from localhost.commerce.net by lists.Commerce.Net id aa25687; 2 Dec 97 09:59 CST Reply-To: James M Galvin To: Colin Robbins cc: "ietf-open-pgp@imc.org" , "murphy@tis.com" , "ned@innosoft.com" , "ietf-ediint@imc.org" , "ietf-smime@imc.org" , "mime-msp@imc.org" , "'Steve Crocker'" Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? In-reply-to: Colin Robbins's message of Tue, 02 Dec 1997 10:30:29 GMT. <01BCFF0D.50DD9D50@crusader.nexor.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25683.881078345.1@commerce.net> Date: Tue, 02 Dec 1997 10:59:05 -0500 From: James M Galvin Message-ID: <9712020959.aa25687@lists.Commerce.Net> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 02 Dec 1997 10:30:29 GMT, Colin Robbins said (and I quote): This suggests the choice between S/MIME and MOSS is being made on the basis of what is easy to implement. This is never a good argument to use, as it loses sight of one major consideration - the users. Any choice ought to be focusing on what the users - at the end of the day our customers - will find integrates into the desktop environment in the simplest and cleanest way. My understanding is this debate suggests this is a MOSS based approach. Funny you should say this. I agree with the conclusion but not how you got there. In the debate over X.400, PEM, PGP, MOSS, MSP, or S/MIME, one observation I like to make is that the user doesn't care what you choose. Frankly, all these protocols provide the security services of the greatest interest to users. Further, all these protocols could be made to support the trust model of your choice and the algorithms of your choice. (Some may have made policy choices in these areas but those choices could be changed!) It just doesn't matter. What the user cares about is interoperability, i.e., when I send you a secure email message you can process it. This is problematic given so many choices. That is the problem! The differences in these protocols are in the implementation. Only developers care about the differences in these protocols (setting aside politics). Each of these protocols requires a different amount of effort to be integrated with various email clients and applications, as well as other applications, e.g., the web. Each of these protocols made different design choices based on different assumptions and requirements. It is these things we should be evaluating in our quest to make a choice. On the issue of deployment, it's nice that S/MIME is integrated with Netscape/Microsoft. I suspect it will get a certain market share because of this. But let us not forget there are a lot more email user agents out there than just Microsoft/Netscape. And many of them are far better than Microsoft/Netscape (although probably not for long). S/MIME is not going to just slip in to that market. Jim -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA15844 for ietf-open-pgp-bks; Tue, 2 Dec 1997 04:33:29 -0800 (PST) Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.7]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA15682; Tue, 2 Dec 1997 04:22:55 -0800 (PST) Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by nala.ctima.uma.es (8.8.5/8.8.5) with SMTP id MAA10496; Tue, 2 Dec 1997 12:16:15 +0100 (MET) Received: from proy11.lcc.uma.es by sol10.lcc.uma.es (5.x/SMI-SVR4) id AA23013; Tue, 2 Dec 1997 12:09:36 GMT Message-Id: <3483ED99.5E3038C5@sol10.lcc.uma.es> Date: Tue, 02 Dec 1997 12:14:34 +0100 From: Antonio Mana Gomez Reply-To: amg@lcc.uma.es Organization: Universidad de Málaga (SPAIN) X-Mailer: Mozilla 4.02 [en] (Win95; I) Mime-Version: 1.0 To: ietf-smime@imc.org Cc: ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? References: <01bcfe7a$f7483120$9d07a8c0@pbaker-pc.verisign.com> <3482FCC0.46DC7756@sternlight.com> Content-Type: multipart/alternative; boundary="------------E5A56DE0BBF27BFD865EEDB2" Content-Transfer-Encoding: 8bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --------------E5A56DE0BBF27BFD865EEDB2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ___________________________________________________________________ Mon, 01 Dec 1997 10:07:02 -0800 David Sternlight wrote: > Phillip M Hallam-Baker wrote: > > ... > > > > The only sense in which the built in client certs are in any > > way special is that the browser company (Microsoft/Netscape) > > has reviewed their Certification Practices Statement and > > their operations and determined that their certificates > > may generally be considered trustworthy. If you disagree > > with this assement then uncheck the box next to VeriSign, > > MCI, Thawte etc and you are entirely OK. > > This is the point, though I may have expressed it imprecisely. For > S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are > "Certification Practices Statements" and sets of hardware and software > standards for CAs. Second of all they are reviewed and only those considered > trustworthy in general are pre-installed in general-user browsers (as distinct > from some possible intranet practice). This is a distinct advantage of the > model, as implemented, for arms-length interaction between strangers. You mean that we should be glad that the company that produced the browser has saved us the effort of finding who to trust, registering, configuring and all those tedious procedures? Just like Microsoft did, saving us the effort to select, get and install a WEB browser by including Explorer in the Windows package?. Of course, you can always choose not to use those pre-installed features, but you know that the average user will use them without questioning whether there are alternatives and then the others will have to follow in order to mantain compatibility and interoperatibility. Only those users who have knowledge about computer security and do not like the kind of trust model proposed will uncheck those boxes. But those are just commercial practices (Not very ethical, by the way). Trust CAN NOT be started that way. By definition. Period. Trust MUST be originated in the real 3D world and then expressed by the tools that the technology provide. If the actual tools are not satisfactory (not easy to use, not natural, not efficient or not elegant...) then what we have to do is to develop new tools not to try to adapt the world to the tools we have. By the way, Gunther, the solution to this problem has not been here for more than ten years. We're just starting to develop it. Please do not think that the theory of information security is just a few encipherment algorithms. There are new questions and problems arising every day that need a solution. Examples? Legal communication interception that does not destroy the citizens rights, Electronic Commerce and many others. We have seen lately that the kind of marketing described above has led to the success of products that are not the best ones, based on letting everybody use them for free until the product has swep the competitors and then, without alternatives, imposing the company's rules. I wont mention any of them, but I suppose everybody has in mind at least a kind of computer and one Operating System (both of them used by me to send this message). The importance of the issue we are speaking of in this group forces us to consider different alternatives and being very careful when we choose one. The main point is that people can use the Internet for their private communications, business or whatever without loosing not even one of their rights. That's not guaranteed with the actual trust models and certification schemes. > In contrast, the web of trust model, as practiced, doesn't require such > practice statements, nor central checking, nor any particular CA > standard-sets. Instead each user creates his own trust heirarchy and rules. > This is a distinct advantage of that model, for small workgroups where > participants know each other and have an opportunity to verify fingerprints or keys > to identities directly. The advantage of this model is that trust comes from the real world but it fails when: -we have to communicate with people that are not linked by a trust (certificate) chain to us. -we have to revocate trust on somebody. -we have lost our certificates. -we have to check a certificate with a long trus chain. -etc., Some of those problems are common to the S/MIME model. > Clearly the first approach is useful in some environments, and the second in > others. It would be a mistake for users in arms-length interaction to trust > unverified signatures just as it would be a mistake to force small > self-contained work groups to adopt the overhead of CAs, trust statements, > etc. And unless the canonical models are distinct, a degree of user education > well beyond pragmatic practice is required, and the possibility is opened for > much mischief. I really believe that the simultaneous use of the two models is not a good idea, it just seems to me a proposal to close this discussion. There are too many problems involved in any of those models alone to combine them in one model with two options. > ... > To avoid misunderstanding I repeat my basic mantra--each trust model in its > pure form has its place and to combine one with the other in the base design > is a bad idea, I agree as I have just said above, in the second part, but I don't think that the coexistence of both models is an advance, maybe you just want to put them out there and let the market do its job selecting one of them. > thought providing a fail-safe multi-step escape hatch giving > users some flexibility (as you've illustrated for S/MIME in Explorer) may be > useful. Nevertheless I suggest the canonical forms are distinct, and should > remain so: In S/MIME-X509 as practiced, users are provided with high-level CA > keys which meet CPS tests; in web of trust as practiced, users must build > their own CA structure on a case by case basis but aren't limited by anyone > else's idea of CPS tests (pace Thawte). > > Frankly speaking, I have the impression this is really not a useful discussion > to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've > got two standards evolving and the commonality is likely mostly to be in the > area of envelopes. But it is not for me to try to shut off discussion on this > interesting topic, if others find it useful. I agree. It's time to close the debate of PGP vs. S/MIME but it's also time to DEVELOP some new alternatives. Please, if conforming to an old standard like X.500 or any other makes it difficult to develop those new alternatives we should try to develop those alternatives without the old standards. I want to note that we are witnessing the difficulties of the development of a standard, and the different points of view that arise in every question, so we should be aware that a standard (specially those never used before) is likely to have imperfections (small or big). That means that NOTHING should be taken as the indisputable basis of our design. I really think that the point of view of all the people that participated in this discussion has enrichted this group. Antonio. ~~~~~ ( o o ) +----------------o000-----U------000o--------------------+ ! _ , ! ! Antonio Mana-Gomez eMail: amg@lcc.uma.es ! ! ! ! http://www.lcc.uma.es/personal/mana/mana.html ! ! ! ! Departamento de Lenguajes y Ciencias de la Computacion ! ! E.T.S.I.Informatica. Desp. 1.2.B.19 ! ! Campus de Teatinos. ! ! 29071 MALAGA (SPAIN) ! ! ! ! Phone: (+34) 5 213 27 54 Fax: (+34) 5 213 13 97 ! +--------------------------------------------------------+ --------------E5A56DE0BBF27BFD865EEDB2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ___________________________________________________________________
Mon, 01 Dec 1997 10:07:02 -0800
David Sternlight wrote:
Phillip M Hallam-Baker wrote:
> ...
>
> The only sense in which the built in client certs are in any
> way special is that the browser company (Microsoft/Netscape)
> has reviewed their Certification Practices Statement and
> their operations and determined that their certificates
> may generally be considered trustworthy. If you disagree
> with this assement then uncheck the box next to VeriSign,
> MCI, Thawte etc and you are entirely OK.

This is the point, though I may have expressed it imprecisely. For
S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are
"Certification Practices Statements" and sets of hardware and software
standards for CAs. Second of all they are reviewed and only those considered
trustworthy in general are pre-installed in general-user browsers (as distinct
from some possible intranet practice). This is a distinct advantage of the
model, as implemented, for arms-length interaction between strangers.

   You mean that we should be glad that the company that produced the
browser has saved us the effort of finding who to trust, registering,
configuring and all those tedious procedures? Just like Microsoft did,
saving us the effort to select, get and install a WEB browser by
including Explorer in the Windows package?. Of course, you can always
choose not to use those pre-installed features, but you know that the
average user will use them without questioning whether there are
alternatives and then the others will have to follow in order to
mantain compatibility and interoperatibility. Only those users who have
knowledge about computer security and do not like the kind of trust
model proposed will uncheck those boxes. But those are just commercial
practices (Not very ethical, by the way). Trust CAN NOT be started that
way. By definition. Period. Trust MUST be originated in the real 3D
world and then expressed by the tools that the technology provide. If
the actual tools are not satisfactory (not easy to use, not natural, not
efficient or not elegant...) then what we have to do is to develop new
tools not to try to adapt the world to the tools we have.
   By the way, Gunther, the solution to this problem has not been here
for more than ten years. We're just starting to develop it. Please do not
think that the theory of information security is just a few encipherment
algorithms. There are new questions and problems arising every day that
need a solution. Examples? Legal communication interception that does not
destroy the citizens rights, Electronic Commerce and many others.
   We have seen lately that the kind of marketing described above has led
to the success of products that are not the best ones, based on letting
everybody use them for free until the product has swep the competitors
and then, without alternatives, imposing the company's rules. I wont
mention any of them, but I suppose everybody has in mind at least a kind
of computer and one Operating System (both of them used by me to send
this message). The importance of the issue we are speaking of in this
group forces us to consider different alternatives and being very
careful when we choose one. The main point is that people can use the
Internet for their private communications, business or whatever without
loosing not even one of their rights. That's not guaranteed with the
actual trust models and certification schemes.
 
In contrast, the web of trust model, as practiced, doesn't require such
practice statements, nor central checking, nor any particular CA
standard-sets. Instead each user creates his own trust heirarchy and rules.
This is a distinct advantage of that model, for small workgroups where
participants know each other and have an opportunity to verify fingerprints or keys to identities directly.
The advantage of this model is that trust comes from the real world but it
fails when:
-we have to communicate with people that are not linked by a trust
 (certificate) chain to us.
-we have to revocate trust on somebody.
-we have lost our certificates.
-we have to check a certificate with a long trus chain.
-etc.,
Some of those problems are common to the S/MIME model.
Clearly the first approach is useful in some environments, and the second in
others. It would be a mistake for users in arms-length interaction to trust
unverified signatures just as it would be a mistake to force small
self-contained work groups to adopt the overhead of CAs, trust statements,
etc. And unless the canonical models are distinct, a degree of user education
well beyond pragmatic practice is required, and the possibility is opened for
much mischief.
  I really believe that the simultaneous use of the two models is not a good
idea, it just seems to me a proposal to close this discussion. There are too
many problems involved in any of those models alone to combine them in one
model with two options.
...
To avoid misunderstanding I repeat my basic mantra--each trust model in its
pure form has its place and to combine one with the other in the base design
is a bad idea,
I agree as I have just said above, in the second part, but I don't think
that the coexistence of both models is an advance, maybe you just want to
put them out there and let the market do its job selecting one of them.
thought providing a fail-safe multi-step escape hatch giving
users some flexibility (as you've illustrated for S/MIME in Explorer) may be
useful. Nevertheless I suggest the canonical forms are distinct, and should
remain so: In S/MIME-X509 as practiced, users are provided with high-level CA
keys which meet CPS tests; in web of trust as practiced, users must build
their own CA structure on a case by case basis but aren't limited by anyone
else's idea of CPS tests (pace Thawte).

Frankly speaking, I have the impression this is really not a useful discussion
to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've
got two standards evolving and the commonality is likely mostly to be in the
area of envelopes. But it is not for me to try to shut off discussion on this
interesting topic, if others find it useful.

I agree. It's time to close the debate of PGP vs. S/MIME but it's also time to DEVELOP some new alternatives. Please, if conforming to an old standard like
X.500 or any other makes it difficult to develop those new alternatives we
should try to develop those alternatives without the old standards. I want
to note that we are witnessing the difficulties of the development of a
standard, and the different points of view that arise in every question,
so we should be aware that a standard (specially those never used before)
is likely to have imperfections (small or big). That means that NOTHING
should be taken as the indisputable basis of our design.
   I really think that the point of view of all the people that
participated in this discussion has enrichted this group.
   Antonio.
                          ~~~~~
                         ( o o )
  +----------------o000-----U------000o--------------------+
  !           _   ,                                        !
  ! Antonio Mana-Gomez               eMail: amg@lcc.uma.es !
  !                                                        !
  ! http://www.lcc.uma.es/personal/mana/mana.html          !
  !                                                        !
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !        E.T.S.I.Informatica.    Desp. 1.2.B.19          !
  !                Campus de Teatinos.                     !
  !               29071 MALAGA (SPAIN)                     !
  !                                                        !
  ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
  +--------------------------------------------------------+
  --------------E5A56DE0BBF27BFD865EEDB2-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA13588 for ietf-open-pgp-bks; Tue, 2 Dec 1997 02:27:50 -0800 (PST) Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [128.243.9.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA13584; Tue, 2 Dec 1997 02:27:42 -0800 (PST) Received: from crusader.nexor.co.uk by lancaster.nexor.co.uk with SMTP (NEXOR MMTA 2.2); Tue, 2 Dec 1997 10:29:17 +0000 Received: by crusader.nexor.co.uk with Microsoft Mail id <01BCFF0D.50DD9D50@crusader.nexor.co.uk>; Tue, 2 Dec 1997 10:30:31 -0000 Message-ID: <01BCFF0D.50DD9D50@crusader.nexor.co.uk> From: Colin Robbins To: "galvin@commerce.net" , "ietf-open-pgp@imc.org" , "murphy@tis.com" , "ned@innosoft.com" , "ietf-ediint@imc.org" , "ietf-open-pgp@imc.org" To: "ietf-smime@imc.org" , "mime-msp@imc.org" , "'Steve Crocker'" Subject: RE: Why do people fight about S/MIME vs. PGP rather than use MOSS? Date: Tue, 2 Dec 1997 10:30:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On 30 November 1997 14:11, Steve Crocker[SMTP:crocker@cybercash.com] = wrote: > Meanwhile, S/MIME adherents usually take the position that MOSS cannot = be > implemented easily unless one has a complete MIME implementation = already. This suggests the choice between S/MIME and MOSS is being made on the = basis of what is easy to implement. This is never a good argument to = use, as it loses sight of one major consideration - the users. Any choice ought to be focusing on what the users - at the end of the = day our customers - will find integrates into the desktop environment in = the simplest and cleanest way. My understanding is this debate suggests = this is a MOSS based approach. Colin Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA05521 for ietf-open-pgp-bks; Mon, 1 Dec 1997 16:35:11 -0800 (PST) Received: from jehova.owl.de (jehova.owl.de [194.121.202.132]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA05505 for ; Mon, 1 Dec 1997 16:34:06 -0800 (PST) Received: from fiction.pb.owl.de (root@fiction.pb.owl.de [193.174.12.5]) by jehova.owl.de (8.8.6/8.8.6) with SMTP id BAA13096 for ; Tue, 2 Dec 1997 01:35:26 +0100 (MET) Received: from squirrel.owl.de by fiction.pb.owl.de with bsmtp id m0xcgIk-00000MC; Tue, 2 Dec 97 01:34 MET Received: (qmail 9467 invoked by uid 200); 1 Dec 1997 23:32:35 -0000 Date: 1 Dec 1997 23:32:34 -0000 Message-ID: <772a14e6d2933c3c554b311db1502166@squirrel> From: Secret Squirrel Comments: Please report problems with this automated remailing service to . The message sender's identity is unknown, unlogged, and not replyable. Subject: Sternlight To: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Sternlight wrote Frankly speaking, I have the impression this is really not a useful discussion to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've got two standards evolving and the commonality is likely mostly to be in the area of envelopes. But it is not for me to try to shut off discussion on this interesting topic, if others find it useful. David ------- David, please depart this group. Your input and focus should be more relevant there, and your absence from the open pgp list will help us get work done rather than casting us into the polemics of insult and Zimmerman-hate that you take everywhere you post. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA04643 for ietf-open-pgp-bks; Mon, 1 Dec 1997 15:17:15 -0800 (PST) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA04639 for ; Mon, 1 Dec 1997 15:17:11 -0800 (PST) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id RAA11527; Mon, 1 Dec 1997 17:16:33 -0600 (CST) Received: from lax-ca69-05.ix.netcom.com(207.223.161.133) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma011473; Mon Dec 1 17:15:58 1997 Message-ID: <34834529.1034562@sternlight.com> Date: Mon, 01 Dec 1997 15:15:59 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: Dave Del Torto CC: Adam Back , Ian Grigg , Uri Blumenthal , ietf-open-pgp@imc.org Subject: Re: [LISTBIZ] A Point of Order References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Dave Del Torto wrote: > > > At 3:15 pm -0800 11/24/97, David Sternlight wrote: > [material removed] > >>Of course, Security Area folks don't have the depth of knowledge tat > >>David has been exhibiting on the Net for quite a while (:-). > > > >Your gratuitous slam comes with ill grace from someone who apparently > >doesn't understand the meaning of "for all the new standards". We were > >talking about PGP's pulling RSA key generation from free PGP 5.0, and > >pulling RSA entirely from free PGP 5.5.2, neither of which is a new IETF > >standard or even a standard in work.. What is more, they didn't pull it > >from pay PGP 5.0 at the same time, so your argument fails doubly. > > [snip] > > Gentlemen, > > Regardless of whether I agree with anything any of you has posted on this > topic, or with the manner, lack of manners, or even the *imagined* lack of > manners (as the case may be) with which it has been said, the fact remains > that this particular thread (playing haruspex over PGP Inc's business plans > and development decisions), does not belong on the IETF's OpenPGP list. > > Please pause to re-familiarize yourselves with the Charter (see: > ). This list is > dedicated to the definition, under IETF guidelines, of an *open* PGP > messaging standard, neither designed nor controlled by PGP Inc -- which > company is absent from mention in the Charter (which also, in a fit of > neutrality, lacks any mention of RSADSI or its products). Thus, whether you > like them or abhor them, use them or prefer to ignore them posting your > opinions about PGP Inc's products and/or practices on this particular > working list is conspicuously inappropriate. It may also be counter- > productive to this standards effort (readers: draw your own conclusions). > > I believe I can safely assume that the four of you are intelligent enough to > at least agree on one thing: that the Internet badly needs a real-world, > workable standard for interoperable messaging with strong encryption. I also > assume that, as interested/concerned technical participants, it is not your > intention to impede the work of this (or any other) Working Group. If so, > please do us the courtesy of moving this thread to another forum where you > can pursue it at your convenience. I agree completely with the sentiments of the writer. > > Since it was Mr. Sternlight who first saw fit to insert his opinions here > (without regard for netiquette, or first familiarizing himself with the WG's > Charter), perhaps it would be appropriate to move this thread to > . Those who are so inclined may spelunk > deeply into his opinions there without further involving the members of this > Working Group (some of whom I suspect might still wish to move the OpenPGP > standard forward, unencumbered by irrelevancies such as debates over why PGP > Inc's freeware doesn't contain this cipher or that hash). It is regrettable that Del Torto spoiled a statement of high principle with an archly personal slam. Those comments are at least subject to misinterpretation. I had not been a subscriber to the list, and one such subscriber e-mailed me several previous posts to the list which I thought in fairness needed a response, which I made. That response triggered off personal attacks from certain others with which I have tried not to engage since I, too, felt them inappropriate. On reflection I think the e-mailed copies were a provocation and It may be that the attempt to drag me into the discussion should have been ignored. Be that as it may, I support Del Torto's sentiments and do not plan further to pursue any matter which he refers to as "irrelevancies" on this list. I hope those holding different views from mine on such matters will behave in a similar fashion. As for Del Torto's redirect pointer, I do not participate directly in that group despite its name. In any case a more useful place for further exercise of righteous indignation at, or ringing defense of the actions of PGP Inc. might be the bit bucket. For those consumed by this issue whose mailers don't provide such a redirect option, news:comp.security.pgp.discuss might be a viable alternative. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA04275 for ietf-open-pgp-bks; Mon, 1 Dec 1997 14:51:26 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA04268 for ; Mon, 1 Dec 1997 14:51:21 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA17037 for ; Mon, 1 Dec 1997 17:56:51 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA17033 for ; Mon, 1 Dec 1997 17:56:50 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id RAA21278 for ; Mon, 1 Dec 1997 17:49:44 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id RAA04214; Mon, 1 Dec 1997 17:51:05 -0500 Date: Mon, 1 Dec 1997 17:51:05 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199712012251.RAA04214@argon.ncsc.mil> To: ietf-open-pgp@imc.org Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk [ massive cross-post stripped down to just ietf-open-pgp ] > From: Gunther Schadow > > I have a strong personal distaste with S/MIME, as the PKCS specs > require ASN.1, X500 and other OSI stuff that does not merge very well > with the rest of the Internet infrastructure. No one can argue with personal taste. But my personal experience is contrary to those who believe that "ASN.1, X.500, and other OSI stuff" is difficult to use, difficult to program, and inevitably results in slow, bloated code. Is your distaste the result of having actually written an S/MIME user agent or X.509 certificate library, or is it just a fear of the unknown? In an effort to teach myself X.509, I wrote a certificate parser from scratch, rather than reuse code available from my employer, or the excellent software from Eric Young, Consensus, SECUDE, and elsewhere. Going in to that exercise, I regarded ASN.1 as a regrettable but necessary evil. Coming out, I have a new-found respect for ASN.1 as a protocol documentation language and for BER as a universal, application-independent serialization/marshalling mechanism. Precisely what do you mean by "the rest of the Internet infrastructure"? * The bits-in-boxes diagrams that document the TCP/IP stack? Those are easy to understand, but not quite flexible enough for use in describing application-layer protocols. * Various BNF/EBNF notations? * Protocol-specific notations such as the one defined by a whole chapter in the TLS specification? * XDR (as used by ONC-RPC)? * S-expressions, or hybrid ASCII-binary encodings (as used by SPKI)? * SGML/HTML/XML? * other private/domain-specific notations I know nothing about or am not even aware of (DCE-RPC, CORBA, ...)? All of these arguably have their place, but the sheer number of them suggests that there is no "Internet infrastructure" to which all of them belong but from which ASN.1 is, for some reason, excluded. To the contrary, I believe that there is significant benefit in using a common protocol description language across multiple protocols - it enables the community's investment in knowledge, tools, code samples, and most importantly, lessons learned, to be amortized over diverse application domains. To cite just one example, the ASN.1 OBJECT IDENTIFIER is a powerful mechanism for achieving global registration of almost anything (data structures, algorithms, protocols, policies, etc.) that requires agreement between implementors, guaranteed uniqueness, and support for both standardized and local object definitions. How many different defined constants or GUIDs does the world need to refer to the MD5 hash algorithm? And to be more practical and less philosophical, I believe that ASN.1 can more than hold it's own from a code size, memory usage, and runtime perspective against the alternatives. It would be interesting to see (no, Jon, I'm not volunteering to write them! :-) benchmarks of the kilobytes and microseconds required to parse PGP, SPKI, and X.509 certs, or of ASN.1 vs. "native" representations for both PGP and SPKI certs. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA04213 for ietf-open-pgp-bks; Mon, 1 Dec 1997 14:48:17 -0800 (PST) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA04209 for ; Mon, 1 Dec 1997 14:48:13 -0800 (PST) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id QAA27223; Mon, 1 Dec 1997 16:49:08 -0600 (CST) Received: from lax-ca69-05.ix.netcom.com(207.223.161.133) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma027146; Mon Dec 1 16:48:54 1997 Message-ID: <34833ED2.5FE35D60@sternlight.com> Date: Mon, 01 Dec 1997 14:48:54 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: James Howard CC: ietf-open-pgp@imc.org Subject: Re: David, are you listening? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This brief note for the record is to indicate that there is little reason to take the list's time up with a make-wrong contest, as Howard seems determined repeatedly to do. David James Howard wrote: Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA03375 for ietf-open-pgp-bks; Mon, 1 Dec 1997 14:10:13 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA03371 for ; Mon, 1 Dec 1997 14:10:08 -0800 (PST) Received: from [205.180.136.85] (pgp85.pgp.com [205.180.136.85]) by fusebox.pgp.com (8.8.7/8.8.5) with ESMTP id OAA23508; Mon, 1 Dec 1997 14:06:05 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: Pretty Good Privacy, Inc. X-PGP-RSAfprint: 30d81f3484e6a83f 6ec8d7f0cab3d265 X-PGP-RSAkey: http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x4AAF00E5 X-PGP-DHfprint: 9b29031d70def566e076 b108904dfea328c029af X-PGP-DHkey: http://keys.pgp.com:11371/pks/lookup?op=index&search=0x28C029AF Date: Mon, 1 Dec 1997 13:58:25 -0800 To: David Sternlight From: Dave Del Torto Subject: [LISTBIZ] A Point of Order Cc: Adam Back , Ian Grigg , Uri Blumenthal , ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 3:15 pm -0800 11/24/97, David Sternlight wrote: [material removed] >>Of course, Security Area folks don't have the depth of knowledge tat >>David has been exhibiting on the Net for quite a while (:-). > >Your gratuitous slam comes with ill grace from someone who apparently >doesn't understand the meaning of "for all the new standards". We were >talking about PGP's pulling RSA key generation from free PGP 5.0, and >pulling RSA entirely from free PGP 5.5.2, neither of which is a new IETF >standard or even a standard in work.. What is more, they didn't pull it >from pay PGP 5.0 at the same time, so your argument fails doubly. > [snip] Gentlemen, Regardless of whether I agree with anything any of you has posted on this topic, or with the manner, lack of manners, or even the *imagined* lack of manners (as the case may be) with which it has been said, the fact remains that this particular thread (playing haruspex over PGP Inc's business plans and development decisions), does not belong on the IETF's OpenPGP list. Please pause to re-familiarize yourselves with the Charter (see: ). This list is dedicated to the definition, under IETF guidelines, of an *open* PGP messaging standard, neither designed nor controlled by PGP Inc -- which company is absent from mention in the Charter (which also, in a fit of neutrality, lacks any mention of RSADSI or its products). Thus, whether you like them or abhor them, use them or prefer to ignore them posting your opinions about PGP Inc's products and/or practices on this particular working list is conspicuously inappropriate. It may also be counter- productive to this standards effort (readers: draw your own conclusions). I believe I can safely assume that the four of you are intelligent enough to at least agree on one thing: that the Internet badly needs a real-world, workable standard for interoperable messaging with strong encryption. I also assume that, as interested/concerned technical participants, it is not your intention to impede the work of this (or any other) Working Group. If so, please do us the courtesy of moving this thread to another forum where you can pursue it at your convenience. Since it was Mr. Sternlight who first saw fit to insert his opinions here (without regard for netiquette, or first familiarizing himself with the WG's Charter), perhaps it would be appropriate to move this thread to . Those who are so inclined may spelunk deeply into his opinions there without further involving the members of this Working Group (some of whom I suspect might still wish to move the OpenPGP standard forward, unencumbered by irrelevancies such as debates over why PGP Inc's freeware doesn't contain this cipher or that hash). I thank you sincerely for your consideration in this regard, dave ____________________________________________________________________________ Quotations by Famous People Who Never Used PGP [#112] "Secrecy is the first essential in the affairs of the State." --Cardinal Armand Jean du Plessis, Duc de Richelieu (1585-1642). As Chief Minister to Louis XIII, Cardinal Richelieu was notorious as a French Monarchist, spymaster, sexual deviant, professional eavesdropper and torturer. He was also among the first in history to never use PGP. -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 Comment: It's email, so press hard - you're making lots of copies! iQCVAwUBNHoxUaHBOF9KrwDlAQHqSgP9GcTey28h1uHjn9gIQz/rMpj4Q46k0sy8 uCbOQzlz3vRXEKR71mn6bYpvoIuF6RdLUTn5YpT2IkSRgbYR93VTrNLcvV6KfonA pBqTJPPBbq2thrPjd+QURqkuSHVYS/sUW7MgWwCrbBV1ciRcw+GT2P431gCWCNpx LAKfG7OONM0= =1rjP -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA02735 for ietf-open-pgp-bks; Mon, 1 Dec 1997 13:33:32 -0800 (PST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA02698; Mon, 1 Dec 1997 13:33:06 -0800 (PST) Received: by relay.hq.tis.com; id QAA00946; Mon, 1 Dec 1997 16:33:48 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma000890; Mon, 1 Dec 97 16:32:56 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id QAA03349; Mon, 1 Dec 1997 16:30:15 -0500 (EST) Date: Mon, 1 Dec 1997 16:30:15 -0500 (EST) From: Sandy Murphy Message-Id: <199712012130.QAA03349@clipper.hq.tis.com> To: zahm@sophia.sema.fr Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Cc: crocker@cybercash.com, galvin@tis.com, gunther@gusw.dialup.fu-berlin.de, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, mime-msp@imc.org, murphy@tis.com, ned@innosoft.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >As far as I remember, MOSS is a MIMEisation of PEM. >PEM is based on X.509 and X.500. PEM imposed a centric view of the securi= >ty >world (1 IPCA) > >So MOSS imply X.509 and then ASN.1 as S/MIME does. Wrong. MOSS supports lots of different ways of identifying the participants, X.509, user/mail name, key,... with different trust models. You might want to read the specs - see rfc1848, section 4. --Sandy Murphy Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA02077 for ietf-open-pgp-bks; Mon, 1 Dec 1997 12:48:25 -0800 (PST) Received: from rtp1.intrex.net (rtp1.intrex.net [209.42.192.253]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA02069 for ; Mon, 1 Dec 1997 12:48:20 -0800 (PST) Received: from BOX1.none (unverified [209.42.199.168]) by rtp1.intrex.net (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 01 Dec 1997 15:49:11 -0500 Message-ID: X-Sender: jbhoward@rtp1.intrex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Release Candidate 3 Date: Mon, 01 Dec 1997 15:49:34 -0500 To: ietf-open-pgp@imc.org From: James Howard Subject: David, are you listening? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk FUDlight wrote: >It would also mean, under a >single-standard view and the reality of the mountains, that the IETF PGP group >is largely wasting its time. Note that I do not hold that view. Close, but not quite. _You_ are wasting _our_ time. It seems like the last half dozen of your rambling posts to this list have been finished with "I know this is off topic, but I dont want to stifle conversation, so I'll continue in a few minutes with another 10 page treatise" You've repeated the argument about 1000 times that you think Open-PGP and S/MIME should both exist, and that you think S/MIME should be used for all commercial activity and Open-PGP should be used only for hobbyists. Everyone actively working in this group disagrees with you. You will not convince a single person, no matter how loud you raise your voice or how many times you send massively crossposted messages through anonymous remailers to defeat our sternlight filters. David, take it to email, or just go away. You contribute absolutely nothing to this group except wasted energy in deleting your messages. How direct do we have to be to get this through your skull? -james Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA01731 for ietf-open-pgp-bks; Mon, 1 Dec 1997 12:29:58 -0800 (PST) Received: from sema.fr (mailrelay.sema.fr [193.106.58.161]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA01690; Mon, 1 Dec 1997 12:29:00 -0800 (PST) Received: from jeanlain.sophia.sema.fr (sophia.sema.fr [10.1.1.1]) by sema.fr (8.8.4/8.8.4) with SMTP id VAA09240; Mon, 1 Dec 1997 21:21:46 +0100 (MET) Message-Id: <199712012021.VAA09240@sema.fr> Received: from BACON [10.1.1.34] by jeanlain.sophia.sema.fr (AltaVista Mail V2.0/2.0 BL23 listener) id 0000_0137_3483_1894_a1b8; Mon, 01 Dec 1997 21:05:40 +0100 From: "Alain Zahm" To: "Gunther Schadow" , , , , Cc: , , , , Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Date: Mon, 1 Dec 1997 20:59:07 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk As far as I remember, MOSS is a MIMEisation of PEM. PEM is based on X.509 and X.500. PEM imposed a centric view of the security world (1 IPCA) So MOSS imply X.509 and then ASN.1 as S/MIME does. ---------- > De : Gunther Schadow > A : crocker@cybercash.com; galvin@tis.com; murphy@tis.com; ned@innosoft.com > Cc : ietf-ediint@imc.org; ietf-open-pgp@imc.org; ietf-pgp-mime@imc.org; ietf-smime@imc.org; mime-msp@imc.org > Objet : Why do people fight about S/MIME vs. PGP rather than use MOSS? > Date : dimanche 30 novembre 1997 14:39 > > TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY. > > I am a member of a EDI standards organization currently preparing a > recommendation for their members on applying Internet E-Mail > standards. Of course, security is a major issue here. Our observation > is that the field is everything else than clear while PGP and S/MIME > camps are fighting each other. Unfortunately, marketing interests > seem to play the major role in that fight. As much as I am confident > in the IETF to stick to its former policy propagating open, freely > available, simple and effective standards, I am nevertheless concerned > that industry is on the edge to do a lot of harm in that field. It > seems already that the "Internet Mail Consortium" will have a strong > impact in IETF standardization, and as the IMC is an industry > consortium, is not committed to the IETF policy. > > I have a strong personal distaste with S/MIME, as the PKCS specs > require ASN.1, X500 and other OSI stuff that does not merge very well > with the rest of the Internet infrastructure. Of course the use of > patent encumbered algorithms is a deleterious "feature" of S/MIME -- > this also shows whose only real interest it is to have S/MIME. It is > not common sense, it is the profit of one company: RSA Data Security, > Inc. The other industry that present itself as deciples of RSA D.S. > Inc. is there to serve as distributors of patent license royalties. > This is a very similar marketing strategy as we all know far too much > from Bill Gates. Do you really want such attitudes to influence the > Internet? > > On the other hand PGP is doing a definite cut in its tradition in > order to move away from patent encumbered algorithms. However, PGP > uses an ad-hoc binary format as well. Even though it is simpler than > ASN.1/DER, it is still unnecessarily obscure, when applied in the > world of MIME. > > Unfortunately, the MOSS specification RFC1848 seems to have been > forgotten. MOSS beats both S/MIME and PGP in terms of being open and > straight forward. It fits very well into the MIME world and does not > require any other technology than MIME. And most important, it is not > engaged in any way to a certain set of algorithms. MOSS can be > translated from and to S/MIME as well as traditional or Open PGP. It > transcends the specifics of any of these technology. > > I really much like to see MOSS having a future in the Internet > community. I would myself write a concise implementation of a flexible > multi-algorithm MOSS that would be freely available. And I think, > others would do so as well. > > Anyway, what I refuse to accept is that the two camps (PGP and S/MIME) > do not try to collaborate. Why don't they sit together, listing their > features in an abstract manner, independent from any format like ASN.1 > or PGP's or any technology like X509? These feature-lists could be > merged, in order to come up with an abstract security specification > that includes both approaches. This abstract specification could then > be mapped to concrete technologies, whether MIME (=> MOSS), ASN.1 (=> > PKCS) or the PGP-style. Conversion software could be used as gateways > between these protocols. > > If this where done, the IMC or any other involved party could show, > whether their work in the IETF is for the sake of the community or > just for their own market share. Get back to common sense, now! Get > the Internet back into people's hands! > > regards > -Gunther > > Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany > Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin. > gusw@zedat.fu-berlin.de http://userpage.fu-berlin.de/~gusw > ----------------------------------#include ----------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA29311 for ietf-open-pgp-bks; Mon, 1 Dec 1997 10:11:01 -0800 (PST) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA29263; Mon, 1 Dec 1997 10:10:05 -0800 (PST) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id MAA27598; Mon, 1 Dec 1997 12:07:29 -0600 (CST) Received: from lax-ca69-56.ix.netcom.com(207.223.161.184) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma027579; Mon Dec 1 12:07:03 1997 Message-ID: <3482FCC0.46DC7756@sternlight.com> Date: Mon, 01 Dec 1997 10:07:02 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: Phillip M Hallam-Baker CC: Gunther Schadow , crocker@cybercash.com, galvin@tis.com, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, murphy@tis.com, ned@innosoft.com Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? References: <01bcfe7a$f7483120$9d07a8c0@pbaker-pc.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Phillip M Hallam-Baker wrote: > > >> 3. Either has "unique" advantages > >> > >> see above. If they had, why not listing them and join all advantages > >> into one standard? > > > >Perhaps I should have said "unique and mutually exclusive" to drive the > point > >home, though I thought I had done that with my examples. For instance it is > >mutually exclusive to allow anyone to be a signer and to allow only those > >meeting certain standards to be signers. > > With respect David this is simply not true. It is logically true. There are ways around it, as you show with respect to S/MIME. > > The only sense in which the built in client certs are in any > way special is that the browser company (Microsoft/Netscape) > has reviewed their Certification Practices Statement and > their operations and determined that their certificates > may generally be considered trustworthy. If you disagree > with this assement then uncheck the box next to VeriSign, > MCI, Thawte etc and you are entirely OK. This is the point, though I may have expressed it imprecisely. For S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are "Certification Practices Statements" and sets of hardware and software standards for CAs. Second of all they are reviewed and only those considered trustworthy in general are pre-installed in general-user browsers (as distinct from some possible intranet practice). This is a distinct advantage of the model, as implemented, for arms-length interaction between strangers. In contrast, the web of trust model, as practiced, doesn't require such practice statements, nor central checking, nor any particular CA standard-sets. Instead each user creates his own trust heirarchy and rules. This is a distinct advantage of that model, for small workgroups where participants know each other and have an opportunity to verify fingerprints or keys to identities directly. Clearly the first approach is useful in some environments, and the second in others. It would be a mistake for users in arms-length interaction to trust unverified signatures just as it would be a mistake to force small self-contained work groups to adopt the overhead of CAs, trust statements, etc. And unless the canonical models are distinct, a degree of user education well beyond pragmatic practice is required, and the possibility is opened for much mischief. In your own prior message you speak about the mountains having decided how it's going to be. This is another such example. One may argue (and such arguments may be interesting and even useful during design of some new standard if the mountains will go along) that in theory it could be different. But the proof of the pudding is in the eating and the current menu on offer involves Certification Practices Statements on the one hand, and roll your own on the other. Thus I continue to disagree that there ought to be a single standard in its base form, but rather two. PGP fans who believe your earlier sketch about Phil's unmoving view vs. the "mountains" ought to take delight in that position. The alternative--under your sketch--is for PGP to go away except as a niche application and S/MIME to continue to be the de facto standard and eventually become the de jure standard. It would also mean, under a single-standard view and the reality of the mountains, that the IETF PGP group is largely wasting its time. Note that I do not hold that view. To avoid misunderstanding I repeat my basic mantra--each trust model in its pure form has its place and to combine one with the other in the base design is a bad idea, thought providing a fail-safe multi-step escape hatch giving users some flexibility (as you've illustrated for S/MIME in Explorer) may be useful. Nevertheless I suggest the canonical forms are distinct, and should remain so: In S/MIME-X509 as practiced, users are provided with high-level CA keys which meet CPS tests; in web of trust as practiced, users must build their own CA structure on a case by case basis but aren't limited by anyone else's idea of CPS tests (pace Thawte). Frankly speaking, I have the impression this is really not a useful discussion to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've got two standards evolving and the commonality is likely mostly to be in the area of envelopes. But it is not for me to try to shut off discussion on this interesting topic, if others find it useful. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA28001 for ietf-open-pgp-bks; Mon, 1 Dec 1997 08:52:38 -0800 (PST) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA27977; Mon, 1 Dec 1997 08:51:41 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id IAA27323; Mon, 1 Dec 1997 08:52:37 -0800 (PST) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA10744; Mon, 1 Dec 1997 08:52:30 -0800 (PST) From: "Phillip M Hallam-Baker" To: , "Gunther Schadow" Cc: , , , , , , , Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Date: Mon, 1 Dec 1997 12:02:54 -0500 Message-ID: <01bcfe7a$f7483120$9d07a8c0@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> 3. Either has "unique" advantages >> >> see above. If they had, why not listing them and join all advantages >> into one standard? > >Perhaps I should have said "unique and mutually exclusive" to drive the point >home, though I thought I had done that with my examples. For instance it is >mutually exclusive to allow anyone to be a signer and to allow only those >meeting certain standards to be signers. With respect David this is simply not true. An S/MIME client can be used in precisely the PGP web of trust mode. I will take Outlook Express as an example but the same holds for other S/MIME clients such as Navigator only the process is slightly different. If someone sends me a certificate that is either self signed or signed by a root not trusted by the browser I simply click a few buttons to add the sender to my address book then go to 'properties->digital ids' I select the untrusted cert and select 'explicitly trust this certificate'. If I want to trust the key as a signing key I click 'inherit trust from this cert.'. The only sense in which the built in client certs are in any way special is that the browser company (Microsoft/Netscape) has reviewed their Certification Practices Statement and their operations and determined that their certificates may generally be considered trustworthy. If you disagree with this assement then uncheck the box next to VeriSign, MCI, Thawte etc and you are entirely OK. This is precisely what many people using VeriSign private label (aka OnSite) certificates do. There is no reason to force them to recognize the public certs on an Intranet. There is a rather nice poster put out by PGP which shows all the various options for arranging certificate issue. As the poster shows PGP can be used in hierarchical fashion if desired. Unfortunately it overlooks the fact that X.509v3 certificates are equally flexible. Please don't start the tiresome flames about personal interest. Its not as if PGP Inc.had no vested interest. I happen to believe that the more ways certificates can be used the larger the market for them will become. It is certainly not in our interest to be dogmatic. Let us all stop being dogmatic about all this then. If there was indeed a problem with the certificate structure of S/MIME that would not make its transport formats invalid. There would be no need to obsolete 25 million clients simply to introduce a different trust model. Evolve the certificate spec to a new level, either in ISO or if need be in the IETF. This is starting to look like one of those programming language/ editor/ Operating System wars*. Ho hum... Phill * BTW the answers are occam, LSE and VMS or Java, does not matter, NT. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA27224 for ietf-open-pgp-bks; Mon, 1 Dec 1997 08:04:24 -0800 (PST) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA27181; Mon, 1 Dec 1997 08:02:43 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id IAA26478; Mon, 1 Dec 1997 08:03:35 -0800 (PST) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA08382; Mon, 1 Dec 1997 08:03:22 -0800 (PST) From: "Phillip M Hallam-Baker" To: "Gunther Schadow" , Cc: , , , , , , , Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Date: Mon, 1 Dec 1997 11:13:46 -0500 Message-ID: <01bcfe74$19cc1d80$9d07a8c0@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >But back to the internet. Tell me, who invented it? Industry >was in fact not really interested in it before some Physicists at CERN >(again a governmentally founded research organization) invented the >WWW. The industry discovered the WWW as a perfect marketing tool, and >helped spread the HTTP/TCP/IP as the most important informational >revolution since the Television. But did they add any technological >benefit to these protocols? Tell me? As one of the longtime membersof that CERN team I can assure you that Marc Andressen, the founder of Netscape had more than a minor role in helping develop the technology. Just because a Netscape PR flack may occasionally give the impression that he invented everything all by himself does not mean his contribution should be ignored. I am also thinking of people such as Ari Luotenen (inventor of the Web proxy), Rob Mcool (co invented CGI with Ari along with much else) and Eric Binna (whose contibutions to HTML are extensive). Throughout the entire time that Dave Raggett has worked on HTML he has been paid by HP. The other reason the 'government funded the Web' meme is simply inaccurate is that CERN never authorized the project. To my knowledge the limit of CERN's support was to provide two student interns for a year (Henrick and Ari), thats not to say they were not incredible interns but from the reports one would imagine that there was a team of twenty people. Everyone else who worked on the Web did so by diverting resources from some other project. I was meant to be working on C++, instead I became the security 'team'. There is absolutely no way that the resources that CERN provided could have allowed the Web to come a tenth of the way it has. Support from industry was absolutely essential. Without it there would not have been the money to fund the Web consortium after our CERN contracts expired and folk asked about the stuff we had been 'supposed' to do. Industry has always had a major role in setting IETF standards. Anyone who thinks that an IPV6 protocol that was not supported by CISCO, 3COM et al could survive does not understand the process. >First of all it was not RSADSI. It was Rivest, Shamir and Adleman, who >worked at MIT founded by governmental grants (a fact that -- in your >voice -- should discredit the innovative nature of the RSA >algorithm). As much as five (5!) years later, the patent was >claimed. This is not true. It was issued five years later but the application date was six months after it was published. RSADSI was formed by the patentees to exploit their invention. Ron Rivest was Chairman until the SDI buyout and still plays an active role. >This is rubbish, and you know it. There is not much to be >theoretically developed in security today, all knowledge is there for >more than ten years. That is simply not true Micali's certificate revocation technique and the Pedderson phone tick modulus appeared in the past three years. You may be unaware of developments but that does not mean that they are not happening. Bruce's book only contains developments that happened before it went to press, funny that. >1. The "userbase" > >The userbase that you cite comes easily by having Netscape and >Microsoft select S/MIME. But don't ask how many S/MIME installations >do exist, but how many of them are actually *used*. I'd be interested >in a good statistics that compares actual *users* not posessors of >S/MIME vs. PGP software. That is not the appropriate measure. What does it take for a user to abandon a built in facility to use another one? If I wish to sign an email I know that almost every recipient will have S/MIME and only a very small number will have gone to the trouble of downloading PGP. If I wish to allow people to send me encrypted mail the same argument means that an X.509 cert wins over a PGP key. The IETF has been talking about encrypted and signed mail for the past ten years. The main reason it has not taken off is that security enhanced mail clients have only ever reached a fraction of the userbase. As a direct result of SSL every browser already has a complete RSA suite and X.509v3 certificate suite. It is no accident that they are interested in a solution that is compatible with that base. Look at the penetration of plug in applications for browsers. Shockwave, Vivo, RealAudio etc appear on only a small fraction of sites despite the ready avaliability of plug ins and the growing trend for them to be made available at the same time the browser is. I can't debug other companies business plans. Hey maybe Phil Z. is right and he can win this battle. Just don't imagine that because it is logical to have a common standard and Phil Z. is determined not to budge that the mountains are going to move to him. The mountains seem to have figured out their idea of what the common standard is and be quite happy where they are. Phill Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA20657 for ietf-open-pgp-bks; Mon, 1 Dec 1997 02:42:41 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA20653 for ; Mon, 1 Dec 1997 02:42:37 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 Dec 1997 10:43:40 +0000 Message-ID: <34829432.7E272362@cs.ucl.ac.uk> Date: Mon, 01 Dec 1997 10:40:50 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Hal Finney CC: ietf-open-pgp@imc.org Subject: Re: expedience, consensus and editing References: <199711302132.NAA02181@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney wrote: > I wonder if it wouldn't make more sense though to define a general > MIME type for a base64 encoded PGP object. This would ***NOT*** be > an alternative or replacement for PGP/MIME. That protocol is used to > protect MIME body parts, and would still be the protocol of choice for > email and similar appliations. > > This proposal would simply be a transport layer for a binary PGP message. > It would be an alternative/replacement for PGP's existing ascii armor. > We'd add a couple of parameters to encode the small amount of data we > currently have in the ascii armor headers and header line. This is an *excellent* idea. It seems similar to S/MIME's 'envelope'. Let's do it! > (Including "PUBLIC KEY BLOCK" would mean that this would subsume the > application/pgp-keys content type from RFC2015.) Just one reservation. If you had separate apps for crypto and key management (like PGPtray and PGPkeys) you would then have to have at least a stub application which looked at the parameter and launched the appropriate application. If we kept application/pgp-keys, that type could be explicitly associated with a key management program, and application/pgp kept for the crypto itself. Ian :D