[rfc-dist] RFC 3369 and 3370 on Cryptographic Message Syntax (CMS)(fwd)
For those not subscribed to RFC-Distribution or the IETF list, two new RFC's (Proposed Standards) on 'Cryptographic Message Syntax'. Both of the announcements are pasted in this message. -- Forwarded message -- Date: Thu, 05 Sep 2002 09:51:07 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [rfc-dist] RFC 3369 on Cryptographic Message Syntax (CMS) A new Request for Comments is now available in online RFC libraries. RFC 3369 Title: Cryptographic Message Syntax (CMS) Author(s): R. Housley Status: Standards Track Date: August 2002 Mailbox:[EMAIL PROTECTED] Pages: 52 Characters: 113975 Obsoletes: 2630, 3211 I-D Tag:draft-ietf-smime-rfc2630bis-08.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3369.txt This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protcol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - Date: 05 Sep 2002 13:53:58 -0400 From: [EMAIL PROTECTED] Subject: [rfc-dist] RFC 3370 on Cryptographic Message Syntax (CMS) Algorithms A new Request for Comments is now available in online RFC libraries. RFC 3370 Title: Cryptographic Message Syntax (CMS) Algorithms Author(s): R. Housley Status: Standards Track Date: August 2002 Mailbox:[EMAIL PROTECTED] Pages: 24 Characters: 51001 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-smime-cmsalg-08.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3370.txt This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS). The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences
Bush to call for Federal Network Operations Center
news item from eweek.com: August 26, 2002 --- Bush to Call for Fed NOC By Caron Carlson and Dennis Fisher The Bush administration has plans to create a centralized facility for collecting and examining security-related e-mail and data traffic and will push private network operators to expand their data-gathering initiatives, according to an unreleased draft of the plan. The proposed cyber-security Network Operations Center is included in a draft of the National Strategy to Secure Cyberspace, which was developed by the President's Critical Infrastructure Protection Board and is due for release Sept. 18. The call for expanded data collection and analysis results from administration concerns that efforts to secure cyberspace are hampered by the lack of a single data-collection point to detect cyber-security incidents and issue warnings, according to a draft of the plan, which was obtained by eWeek. . . . . article continues at: http://www.eweek.com/article2/0,3959,484669,00.asp - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
new RFCs
as noticed on RFC distribution list: RFC 3278 on Use of ECC Algorithms in CMS RFC 3279 on Algorithms and Identifiers RFC 3280 on Internet X.509 Public Key Infrastructure RFC 3281 on An Internet Attribute Certificate replace N's below with RFC number to fetch: ftp://ftp.rfc-editor.org/in-notes/rfc.txt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
On Sat, 26 Jan 2002, [EMAIL PROTECTED] wrote: At 05:46 PM 1/26/02 -0500, P.J. Ponder wrote: . . . . Without think about it some more, I don't know whether to place the entire notion of security controls based on biometric telemetry in with _pure_ bullshit like copy protection, watermarking, non-repudiation, tamper proofing, or trusted third parties. Admittedly, there is a lot of bullshit in the idea, I'm just not sure it is pure. If you think about it, it's actually a succinct way of categorizing different ways that someone can authenticate themselves. You seem to imply that the only nonbullshit way to do that is a) something you know. I'd say that's been shown to be a pretty weak authentication method when relied on solely. There isn't anything generally wrong with hardware devices or something that 'one has'. Tokens and the like can be cost effective in many applications. I'm working with some folks right now that are looking at hardware dongle-type things for a particular security application. Little hardware gizmos will probably turn out to be a good fit for what they are doing. Nothing wrong with that. People often use password systems poorly, and many password systems permit poor and sloppy use. Still passwords and passphrases can be used effectively. I think the need for maintaining control over the biometric telemetry equipment makes it suitable for a rather narrow range of applications. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
On 26 Jan 2002, Perry E. Metzger wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: . . . . C'mon, depending on is-ness is exactly the same cat-and-mouse game as authentication technologies that depend on have-ness and know-ness attributes. I have no idea what the heck you're talking about there. Perhaps you do, perhaps not. . . . . I took 'have-ness' to mean a token, smartcard, i-Button, little gizmo that gens a new number every 60 sec, dongle, whatever; the thread being some physical matter thing like a key. 'Know-ness' I ascribed to passwords, passphrases, things that are known or can be divined from one's internal resources; an epistemological sort of thing. I have heard people say that security can be based on either a) something that you know, b) something that you have, or c) something that you are; usually I have heard this 'security-divided-into-three-parts' idea in the preamble to a sales pitch for something from either b) or c). Without think about it some more, I don't know whether to place the entire notion of security controls based on biometric telemetry in with _pure_ bullshit like copy protection, watermarking, non-repudiation, tamper proofing, or trusted third parties. Admittedly, there is a lot of bullshit in the idea, I'm just not sure it is pure. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Stegdetect 0.4 released and results from USENET search available
On Fri, 21 Dec 2001, John Gilmore wrote: . . . . PS: Cypherpunks, where *are* you putting your secret messages? Give us a hint! Surely *somebody* in this crew must be leaving some bread-crumbs around for Niels and NSA to find... :-) I always assumed newsgroups, like alt.images.binary.*, but perhaps websites that allow users to upload pictures are the preferred channels. Of course there is a big distiction between (intentionally) leaving something around for Niels to find and really trying to hide something -- pj - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[SC] ePSO-N 09 (fwd)
The latest issue (Number 10) of the Electronic Payment Systems Observatory - Newsletter (ePSO-N) deals with authentication. The enclosed table of contents was mailed to the 'smartcards' mailing list. -- Forwarded message -- Date: Tue, 11 Dec 2001 16:01:27 +0100 From: Knud Bohle [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [SC] ePSO-N 09 Dear list, again we send the contents page of the ePSO-Newsletter. The focus of ePSO-N 10 is on authentication, but also other articles might be of interest. In this issue we also announce the final ePSO Conference. Regards Knud Boehle ** ELECTRONIC PAYMENT SYSTEMS OBSERVATORY-NEWSLETTER ePSO-Newsletter - No 10 - November 2001 http://epso.jrc.es/newsletter OVERVIEW of ePSO-N 10 [101] Editorial: Authentication, Privacy and Regulation Simon Lelieveldt ([EMAIL PROTECTED]), Amsterdam, The Netherlands, and Arnd Weber ([EMAIL PROTECTED]), ITAS, Karlsruhe, Germany /security/privacy/regulation This issue focuses on authentication and privacy. The development of credit card charge backs is addressed, these being a major driving force for proposals such as 3D Secure (Verified by Visa), SPA/UCAF, and pseudo card numbers. The pros and cons of these technical solutions are reviewed. Furthermore, this issue addresses the achievability of unobservable purchases and payments on networks. In addition there are comments on the demise of Flooz and Beenz, there is a review of the new Blue Book of the European Central Bank, and the ePSO Conference taking place in Brussels on February 19, 2002 is announced. http://epso.jrc.es/newsletter/vol10/1.html __ [102] Guaranteed Transactions, the Quest for the 'Holy Grail' Oliver Steeley ([EMAIL PROTECTED]), Consult Hyperion, Guildford, United Kingdom /credit cards/Internet payment systems/security In a change to their previous strategy of collaboration, Visa and MasterCard have recently announced their own separate initiatives with regards to securing Internet transactions. 3D Secure and SPA/UCAF are variations on a theme of passing the cardholder back to their card-issuer to authenticate themselves before the merchant seeks an authorisation. This is one more step in a long and arduous journey, which shows no signs of coming to a speedy conclusion. http://epso.jrc.es/newsletter/vol10/2.html __ [103] Interview: Largest German Credit Card Issuer on Massive Reduction of Charge Backs Ulrich Riehm ([EMAIL PROTECTED]) and Arnd Weber ([EMAIL PROTECTED]), ITAS, Karlsruhe, Germany, talk to Tilo Schürer ([EMAIL PROTECTED]), Bankgesellschaft Berlin, Germany /credit cards/security Tilo Schürer is responsible for product management in the field of electronic business at Bankgesellschaft Berlin, Germany's largest credit card issuer. Schürer points out that the charge back problem in the Internet business has massively lost importance during recent years. The decisive measure was not improved technology but economic penalties imposed by the credit card organisations. In the interview, there is also a discussion of the viability of new authentication measures (e.g. 3D-Secure or SPA/UCAF). Schürer subsumes that charge back figures are currently so low that the banks could theoretically announce zero liability, at least once a new user of the Internet has registered for a new authentication process. http://epso.jrc.es/newsletter/vol10/3.html __ [104] Hi-tech Payment Technologies in Russia: The Case of Paycash Victor Dostov ([EMAIL PROTECTED]), Paycash Group, St. Petersburg, Russia /electronic money/privacy/Internet payment systems/Russia Paycash is a Russian-born Internet payment system based on digital cash. With Paycash, an account can be opened pseudonymously on the Internet. The payments are untraceable, though payments of a single Paybook can be linked. In Russia, 200 shops are connected, and more than 400 transactions per day are processed. The company is expanding its business to abroad. http://epso.jrc.es/newsletter/vol10/4.html __ [105] JAP: A Cloak of Invisibility on the Internet Hannes Federrath ([EMAIL PROTECTED]), Dresden University of Technology, Germany/privacy/electronic commerce/JAP is an Internet service designed to enable the unobservable use of the world wide web. In the future, JAP could also be used for anonymous shopping or banking. Invisibility is achieved by communication not taking place directly with the web server, but by detour through a so called mix proxy cascade. http://epso.jrc.es/newsletter/vol10/5.html __ [106] Failure of Beenz and Flooz Indicates the End of Digital Web-Currencies? Hugo Godschalk ([EMAIL PROTECTED]), PaySys Consultancy, Frankfurt,
Re: Rubber hose attack
On Fri, 2 Nov 2001, Rick Smith at Secure Computing wrote: If Microsoft's system is too brittle, then they'll pay for it through fraud expenses. If people find it unreliable or untrustworthy, they'll use other mechanisms for buying things. While I would feel compassion for consumers who are hurt or inconvenienced by some huge scam that exploited a poor Microsoft security implementation, such a scenario would be entertaining to watch. Regardless of .Net's expected convenience, most people will probably still patronize non-.Net vendors when they offer better prices, regardless of the inconvenience. It's not that hard to re-enter billing information, especially when compared to driving across town to the discount store instead of using the higher-cost mini-mart down the street. I agree about the intersting to watch part - it should be a hoot. I read a statistic a few years ago about the percentage of users of Internet Explorer and Netscape browsers who had never changed the default start page for the browser. I forget what the percentage was, but it struck me at the time as being quite high, like a third or more. The percentage may be higher now, a few years later, as access to the internet permeates into a broader and less technically sophisticated demographic. There is probably a significant percentage of users who will never learn how to tweak the software tools that come with their new pcs, and they won't even make the most rudimentary changes to the software behavior that most of the users of this list would consider minimal customization. It's for reasons like this that Microsoft and OEMs battle over getting icons to come up on the screens of new pcs. The default settings will be the permanent settings for many users, and if it is easier to buy something through a .Net affiliate than to shop around, then the .Net sites will get a certain percentage of users just by 'default'. They won't get all, certainly, but they will get some just because of the path of least resistance. Same business practice with file format associations, preferred search engines, pre-installed bookmarks, pre-loaded certificates, and so forth. Passport is just part of the control/monopoly-enforcement package. Ob crypto, I had a client who had a terrible time with public users not having browsers with 128-bit crypto available to access the site - lots of complaints, help desk calls, increased support staff hours, executive management bitching about the network staff not helping the customers. That's why it is important to make sure that the minimum spec is good enough in a lot of applications, because lots of users will never learn how to turn on the optional features and they will resent having to do it, anyway. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Passport Passwords Stored in Plaintext
The original proposal for dot-net was to *centralize* all of the personal information on at one location. This part may be changing with recent capitulations regarding, of all things, interoperability. This idea of centralizing everyone's personal information is the scary part of all this to me, even recognizing how permeable and abuse-ready the company's software seems to be. on another topic - Has anyone thought about how a scheme like .Net could be aided by 'reasonable and non-discriminatory (RAND)' licensing terms creeping into W3C Recommendations? Now there is a scary thought IIS (Ignorance Is Strength) On Fri, 5 Oct 2001, Joseph Ashwood wrote: - Original Message - From: bernie [EMAIL PROTECTED] Some of the people here wants to use the .NET for critical applications. I'm sorry. How secure is the .NET? The short answer is that it isn't secure. There are two main problems with it being secure. The first is the password vulnerability that you replied to. The second is that it uses a custom blended Kerberos-esque implementation. I say Kerberos-esque because it has some significant problems. First it uses RC4, a cipher which is increasingly being considered insecure, and in using it windows doesn't take the precautions necessary to make it secure. They are the only company foolish enough to have embedded access control information in the kerberos ticket, this adds even more leaking information, and just enough of it to determine the users password. Basicly they have made nearly every effort to eliminate the security of the system while making it appear secure to a layman. For further evidence that Microsoft can't do anything secure I point to (in no particular order) IIS, pptp, pptp2, Internet Explorer, Outlook Express, Windows 95, Windows98, WindowsME, WindowsNT, Windows2000, and while I haven't verified it yet I believe also WindowsXP. Some of these probably need some explaination, IIS is the script kiddie choice it has more holes than a pound of Swiss cheese. pptp was severely broken, pptp2 was slightly less severely broken. Internet Explorer has had so many security vulnerabilities I can't even count that high. Outlook Express is a virus writers dream. Windows95 offered no security, same with 98 and ME. WindowsNT is subject to extremely basic attacks on the password system that Microsoft refused to recognise, same with 2000, and probably the same with XP. In 2000 MS introduced a secure encrypted filesystem which lacked any reasonable ability to encrypt documents securely (it put the keys in a file in plaintext, the file is easily readable). Even the cryptoAPI that Microsoft designed and offered has holes in it, allowing arbitrary code to be run in the place of what the programmer intended. I am unaware of anything microsoft has ever written that could be considered secure and there is evidence that they plan to continue this less than stellar performance with .NET. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RFC 3163 on ISO/IEC 9798-3 Authentication SASL Mechanism (fwd)
for those not on RFC-Dist or IETF mailing lists: -- Forwarded message -- Date: Fri, 24 Aug 2001 09:44:24 -0700 From: RFC Editor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RFC 3163 on ISO/IEC 9798-3 Authentication SASL Mechanism A new Request for Comments is now available in online RFC libraries. RFC 3163 Title: ISO/IEC 9798-3 Authentication SASL Mechanism Author(s): R. Zuccherato, M. Nystrom Status: Experimental Date: August 2001 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 17 Characters: 32498 Obsoletes/Updates/SeeAlso:None I-D Tag:draft-zuccherato-9798-3-sasl-03.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3163.txt This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3163.txt
Re: crypto flaw in secure mail standards
The laws I have seen are not specific enough to deal with what gets included in a digitally signed message. These laws define 'digital signature' and in some cases invoke so-called trusted third parties to issues certs, etc., but I haven't seen a law yet with the level of detail that would require date/time, subject, to, from, etc., in a mail message. Most of the laws define something as being digitally signed in general terms of public key crypto, as for example the Florida (US) law: | | (3) Digital signature means a type of electronic signature that | transforms a message using an asymmetric cryptosystem such that a person | having the initial message and the signer's public key can accurately | determine: | | (a) Whether the transformation was created using the private key that | corresponds to the signer's public key. | | (b) Whether the initial message has been altered since the | transformation was made. | (from section 668.003, Florida Statutes) As others have pointed out, 'non-repudiation' is not a legal concept. As a practical matter, if one were potentially damaged by an attack of this type, one could argue that such a message could be resent, absent the original context. This could be demonstrated, experts could testify, etc. It appears to be a problem in the protocols, but I don't see it as being a legal problem, esp. in light of the fact that there is no such thing as 'non-repudiation' in the real world. Seems like another good reason to use a time-stamper like the one at: http://www.itconsult.co.uk/stamper/ -- pjp On Sun, 24 Jun 2001, Enzo Michelangeli wrote: A question for legal experts on the list: Does all this pose legal risks within the current legal framework? In other word, do current digital signature laws assume that also the headers are assumed to be authenticated and non-repudiable if the message is digitally signed? Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
