From housley@vigilsec.com Fri Apr 19 09:21:23 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B8121F9609 for ; Fri, 19 Apr 2013 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-0DKjaXFEn9 for ; Fri, 19 Apr 2013 09:21:18 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5D71321F9608 for ; Fri, 19 Apr 2013 09:21:18 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E2654F24078 for ; Fri, 19 Apr 2013 12:21:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id oUBducwaPxCW for ; Fri, 19 Apr 2013 12:21:13 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id ED9EFF2406E for ; Fri, 19 Apr 2013 12:21:21 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Apr 2013 12:21:16 -0400 References: <20130418151254.13949.52367.idtracker@ietfa.amsl.com> To: IETF SMIME Message-Id: <50816A63-E208-449A-977A-9F31544C9222@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [smime] draft-housley-ct-keypackage-receipt-n-error-00 X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 16:21:23 -0000 Since people that know about CMS hang out on this list, I am asking for = review and comment of this Internet-Draft here. Thanks, Russ > From: internet-drafts@ietf.org > Date: April 18, 2013 11:12:54 AM EDT > To: housley@vigilsec.com > Subject: New Version Notification for = draft-housley-ct-keypackage-receipt-n-error-00.txt >=20 >=20 > A new version of I-D, = draft-housley-ct-keypackage-receipt-n-error-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Filename: draft-housley-ct-keypackage-receipt-n-error > Revision: 00 > Title: Cryptographic Message Syntax (CMS) Key Package = Receipt and Error Content Types > Creation date: 2013-04-17 > Group: Individual Submission > Number of pages: 23 > URL: = http://www.ietf.org/internet-drafts/draft-housley-ct-keypackage-receipt-n-= error-00.txt > Status: = http://datatracker.ietf.org/doc/draft-housley-ct-keypackage-receipt-n-erro= r > Htmlized: = http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error-00 >=20 >=20 > Abstract: > This document defines the syntax for two Cryptographic Message Syntax > (CMS) content types, one for key package receipts, and another for > key package errors. The key package receipt content type is used to > confirm receipt of an identified key package or collection of key > packages. The key package error content type is used to indicate an > error occurred during the processing of a key package. CMS can be > used to digitally sign, digest, authenticate, or encrypt these > content types. From ietf@augustcellars.com Fri Apr 19 17:50:51 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8567721F91AB for ; Fri, 19 Apr 2013 17:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEY7xwbsLfkx for ; Fri, 19 Apr 2013 17:50:50 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB9B21F919A for ; Fri, 19 Apr 2013 17:50:50 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9550B38F00; Fri, 19 Apr 2013 17:50:49 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" , "'IETF SMIME'" References: <20130418151254.13949.52367.idtracker@ietfa.amsl.com> <50816A63-E208-449A-977A-9F31544C9222@vigilsec.com> In-Reply-To: <50816A63-E208-449A-977A-9F31544C9222@vigilsec.com> Date: Fri, 19 Apr 2013 17:50:05 -0700 Message-ID: <00fc01ce3d61$0055ad20$01010760$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJXqOTs93H7Sx2qVjApye56zgIYjwLwaxZ6l7Opq1A= Content-Language: en-us Subject: Re: [smime] draft-housley-ct-keypackage-receipt-n-error-00 X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 00:50:51 -0000 Russ, Here you go. 1. What is SIR - not defined 2. Is it your expectation that name types which do not have ASN.1 values are going to be created? If not then why is there an OCTET STRING wrapper for nameValue. This choice should be justified in the document. 3. Should you define a relationship for relating nameType and nameValue information? Automated packages would find it useful, it also makes the fact that you are use Name rather than possibly GeneralName explicit in the module. 4. You should probably give a reference to where signed, authenticated and content attributes are found. I am familiar with the first two since I do a lot of CMS work, however the last one really needs to be tied to an RFC and a specific content type. 5. Can the key package identifier and receipt request attribute have multiple values or is a single value attribute? 6. We can rehash this discussion. First I don't see any reason for incrementing the version number unless you are going to re-assign the same OID for the new structure as you did for the old one. If a new OID is used there is more than enough information to distinguish between the two different structures. Second, I am not a fan of assigning version numbers to these structures because they do not help any encoding/decoding systems. The structure will be encoded or decoded based on the ASN and not on the version number. 7. What is the purpose of the (1..MAX) on the definition of KeyPkgVersion. Are you just trying to say that it cannot be a negative value? It would be more helpful if you used a smaller version such as 2^32-1 so that a compiler would know that it fit into an int32 value. I would also note that this is a change from the old definition of the field in RFC 6031 8. Is there a requirement that systems should accept KeyPkgIdentifier.attribute values that they do not understand as it can be reflected in the receipt without having to decode it? 9. Why is there a requirement that the content types have to be encoded using the DER rules? This is not a general requirement imposed by CMS and therefore needs some justification text. 10. I find the field names errorOf and errorBy to be obtuse - but that is not a strong reason to change them if they have a meaning that is not documented. 11. does badContentInfo apply to embedded content types (i.e. eContent) as well as the ContentInfo structure? 12. Why should there be a problem with having more than one entry in the digestAlgorithms field? I can potentially understand complaining if there is one that is not understood but not if there is more than one. 13. I must have missed the rule that says that there is a problem if you have a signed attribute that is unknown and not ignored. Is that part of the badSignedAttrs field or is this only an issue with the ASN.1 encoding? 14. notAuthroized - this description seems off for this content type. Is the issue that the TA is not authorized or the TA does not root the authorization. It would not be the signer itself in this case one presumes. 15. put in a reference for the content-decryption-key-identifier attribute. 16. Is there a reason for the badKeyTransportRecipientInfo item being absent? 17. Do you want to distinguish between a decryptFailre and a failure processing a key management item? This is the basis of some online attacks to get a key when dealing with RSA v1.5 and RSA OEAP. This merits a security consideration notice all by itself. 18. Are there any security attacks that occur by differentiating between decryptFailure and invalidMAC for AuthEnvelopedData? 19. For mismatchedDigestAlg - are you comparing with the signature algorithm or with the content digest algorithm? 20. You need some text to distinguish missingCertificate and noTrustAnchor if keep the "using a trust anchor" text. 21. tooManySigners - where is this restriction imposed? 22. can the missingSignedAttributes be used if there are attributes that are required to be present but are absent - even if there are some attibutes present? 23. I don't understand the reason for the missingContentHints. This attribute would be an encrypted structure not a signed structure. Why would a content hint make any difference in terms of the processing? 24. Are there any security attacks that are uncovered by the use of the badMessageDigest error code rather than just saying that the signature failed to validate? 25. badAttributes should be modified to say that this is an error only if the attribute is defined to say that it is not legal for that attribute. For some attributes having multiple attributes or multiple values is legal. 26. The description of unsupportedAsymmetricKeyPackage does not make sense - There is a difference between not prepared and unsupported 27. Should I be able to return more than one errorCode if I find more than one error during processing? 28. Given the number of times that AuthenticatedData was mentioned in the text, is there a reason it is omitted from section 6? 29. Security consideration on the cost benefits of using a generic vs a specific error code. Some specific codes might leak security information. 30. Do you really want to make the KeyPkgVersion revised or is it a totally independent thing? As currently setup it will be a different thing since it is in a different module. If you want it to be a change on what is in the original module then you need to re-publish that module as well. > -----Original Message----- > From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf > Of Russ Housley > Sent: Friday, April 19, 2013 9:21 AM > To: IETF SMIME > Subject: [smime] draft-housley-ct-keypackage-receipt-n-error-00 > > Since people that know about CMS hang out on this list, I am asking for review > and comment of this Internet-Draft here. > > Thanks, > Russ > > > > > From: internet-drafts@ietf.org > > Date: April 18, 2013 11:12:54 AM EDT > > To: housley@vigilsec.com > > Subject: New Version Notification for > > draft-housley-ct-keypackage-receipt-n-error-00.txt > > > > > > A new version of I-D, > > draft-housley-ct-keypackage-receipt-n-error-00.txt > > has been successfully submitted by Russ Housley and posted to the IETF > > repository. > > > > Filename: draft-housley-ct-keypackage-receipt-n-error > > Revision: 00 > > Title: Cryptographic Message Syntax (CMS) Key Package Receipt > and Error Content Types > > Creation date: 2013-04-17 > > Group: Individual Submission > > Number of pages: 23 > > URL: http://www.ietf.org/internet-drafts/draft-housley-ct- > keypackage-receipt-n-error-00.txt > > Status: http://datatracker.ietf.org/doc/draft-housley-ct-keypackage- > receipt-n-error > > Htmlized: http://tools.ietf.org/html/draft-housley-ct-keypackage- > receipt-n-error-00 > > > > > > Abstract: > > This document defines the syntax for two Cryptographic Message Syntax > > (CMS) content types, one for key package receipts, and another for > > key package errors. The key package receipt content type is used to > > confirm receipt of an identified key package or collection of key > > packages. The key package error content type is used to indicate an > > error occurred during the processing of a key package. CMS can be > > used to digitally sign, digest, authenticate, or encrypt these > > content types. > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From hammondjohnson@hushmail.com Sat Apr 27 14:57:05 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5130521F990D for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jln8MOqBeCMu for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5D321F9904 for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 82136580B4 for ; Sat, 27 Apr 2013 17:49:23 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:49:23 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 49D7CE6739; Sat, 27 Apr 2013 17:49:23 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:49:23 -0400 To: smime@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174923.49D7CE6739@smtp.hushmail.com> Subject: [smime] Biggest Fake Conference in Computer Science X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:57:05 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.