http://permalink.gmane.org/gmane.ietf.smime hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.smime/6892 <pre> No. I think this is going to need a F2F conversation to resolve. _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Jim Schaad 2013-05-17T17:48:33 http://permalink.gmane.org/gmane.ietf.smime/6891 <pre>The use of things such as CONTENT-TYPE are already pushing you to the point of needing an '88 ASN.1 module in the event that is a requirement. The addition of the SIR-ENTITY-NAME class does not change anything from the current world. As such I do not believe that this is a change that would affect a decision on providing an '88 module. One would use a parameterized class definition if one believe that the class would be used in multiple locations with different sets of parameters. Thus it makes sense in the case of CMS to define a single class and type for signed attributes, unsigned attributes, authenticated attributes, unauthenticated attributes as a parameterized set. The same basic type structure is used in each of these locations but with a different set of possible values that can go into each location. One would use a global/fixed name set in the event that something is used in exactly one location and there is no reason to expect that it would be imported into a different module and used with a</pre> Jim Schaad 2013-05-17T17:45:56 http://permalink.gmane.org/gmane.ietf.smime/6890 <pre>Jim: Does this text resolve you concern? * badUnsignedAttrs is used to indicate that the unsignedAttrs within SignerInfo contains one or more attributes. Since unrecognized attributes are ignored, this error code is used when the object identifier for the attribute is recognized, but the value is malformed or internally inconsistent. In addition, this error code can be used when policy prohibits an implementation from supporting unsigned attributes. Russ _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Russ Housley 2013-05-17T13:36:48 http://permalink.gmane.org/gmane.ietf.smime/6889 <pre>Jim: I have not made this change yet. It seems I would need a '88 and an '02 module. I'd appreciate advice on the fixed name set vs. the parameter. Russ _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Russ Housley 2013-05-17T13:34:27 http://permalink.gmane.org/gmane.ietf.smime/6888 <pre>I received some off-list comments that I incorporated. spt -------- Original Message -------- Subject: I-D Action: draft-turner-ct-keypackage-receipt-n-error-algs-01.txt Date: Thu, 09 May 2013 02:56:43 -0700 From: internet-drafts&lt; at &gt;ietf.org Reply-To: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types Author(s) : Sean Turner Filename : draft-turner-ct-keypackage-receipt-n-error-algs-01.txt Pages : 6 Date : 2013-05-09 Abstract: This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. The IETF datatracker status page f</pre> Sean Turner 2013-05-09T09:58:22 http://permalink.gmane.org/gmane.ietf.smime/6887 <pre>For draft-housley-ct-keypackage-receipt-n-error-00 there's a companion algorithm draft. spt -------- Original Message -------- Subject: I-D Action: draft-turner-ct-keypackage-receipt-n-error-algs-00.txt Date: Thu, 18 Apr 2013 10:24:39 -0700 From: internet-drafts&lt; at &gt;ietf.org Reply-To: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types Author(s) : Sean Turner Filename : draft-turner-ct-keypackage-receipt-n-error-algs-00.txt Pages : 6 Date : 2013-04-18 Abstract: This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. </pre> Sean Turner 2013-05-03T01:46:37 http://permalink.gmane.org/gmane.ietf.smime/6886 <pre> Good the Good right. SIR-ENTITY-NAME.&amp;SIRNameValue({SIRNameSet}{&lt; at &gt;sirNameType})) Yes that looks correct. You could use a fixed name set if you wanted to rather than having it be a parameter. This would depend on how you are planning to use it. attribute. described CMS the Good Good any convention I don't need to rehash the discussion either. I will just always raise it. KeyPkgVersion. a reason I agree that is probably more than sufficient. sure I don't think that this is an acceptable solution ore response at this point. If I send you Key package id and receipt request ::= { pkgID = { random OID you never heard of, binary value } receiptReq = { encryptReceipt FALSE, receiptsFrom - absent receiptsTo = {Me} }} You have three options: 1 - say that the signed attribute is bad because you do not understand a piece if it and neither process nor receipt the package 2 - say that you don't care that the signed attribute is bad and process it and return a receipt because you do </pre> Jim Schaad 2013-05-02T20:04:41 http://permalink.gmane.org/gmane.ietf.smime/6885 <pre>The -01 version addresses most, but not all, of the comments submitted by Jim Schaad. Russ _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Russ Housley 2013-05-02T14:12:52 http://permalink.gmane.org/gmane.ietf.smime/6884 <pre>Jim: Thank you for the review. Source Intermediary Recipient (SIR) entity name The nameValue is an OCTET STRING, which allows the canonical form of any name to be carried. Two names of the same type are considered equal if the octet strings are the same length and contain the same string of octets. I am not totally sure what you are suggesting. Let me know if I got it right. SIR-ENTITY-NAME ::= CLASS { &amp;SIRNameType OBJECT IDENTIFIER UNIQUE, &amp;SIRNameValue } WITH SYNTAX { SYNTAX &amp;SIRNameValue IDENTIFIED BY &amp;SIRNameType } SIRNames{SIR-ENTITY-NAME:SIRNameSet} ::= SEQUENCE SIZE (1..MAX) OF SIRName{{SIRNameSet}} SIRName{SIR-ENTITY-NAME:SIRNameSet} ::= SEQUENCE { sirNameType SIR-ENTITY-NAME.&amp;SIRNameType({SIRNameSet}), sirNameValue OCTET STRING (CONTAINING SIR-ENTITY-NAME.&amp;SIRNameValue({SIRNameSet}{&lt; at &gt;sirNameType})) This attribute can appear as a signed, authenticated, and content attribute. Signed attributes are carried in the CMS </pre> Russ Housley 2013-05-02T14:07:51 http://permalink.gmane.org/gmane.ietf.smime/6883 <pre>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 t</pre> hammondjohnson< at >hushmail.com 2013-04-27T17:49:23 http://permalink.gmane.org/gmane.ietf.smime/6882 <pre>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</pre> Jim Schaad 2013-04-20T00:50:05 http://permalink.gmane.org/gmane.ietf.smime/6881 <pre>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 _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Russ Housley 2013-04-19T16:21:16 http://permalink.gmane.org/gmane.ietf.smime/6880 <pre>I am ok with this errata, I think that Russ should make an opinion as well. Jim "Reply is edit Algorithm _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Jim Schaad 2012-09-20T19:44:35 http://permalink.gmane.org/gmane.ietf.smime/6879 <pre> The following errata report has been submitted for RFC3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3394&amp;eid=3361 -------------------------------------- Type: Editorial Reported by: Dwayne Litzenberger &lt;dlitz&lt; at &gt;dlitz.net&gt; Section: 2.2.1 Original Text ------------- 3) Output the results. Set C[0] = A[t] For i = 1 to n C[i] = R[t][i] Corrected Text -------------- 3) Output the results. Set C[0] = A[s] For i = 1 to n C[i] = R[s][i] Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3394 (draft-ietf-smime-aes-keywrap-</pre> RFC Errata System 2012-09-20T16:50:13 http://permalink.gmane.org/gmane.ietf.smime/6878 <pre>Oh, good catch. I saw R[t] but missed A[t]. Sorry about that. On Wed, Sep 19, 2012 at 08:29:47PM -0700, Jim Schaad wrote: </pre> Dwayne Litzenberger 2012-09-20T06:25:45 http://permalink.gmane.org/gmane.ietf.smime/6877 <pre>I would make it Corrected Text -------------- 3) Output the results. Set C[0] = A[s] For i = 1 to n C[i] = R[s][i] _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Jim Schaad 2012-09-20T03:29:47 http://permalink.gmane.org/gmane.ietf.smime/6876 <pre> So, you have an alternate errata to propose? --Paul Hoffman _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Paul Hoffman 2012-09-19T18:10:49 http://permalink.gmane.org/gmane.ietf.smime/6875 <pre>As it stands I would say that this errata needs to be rejected. I accept the basic premise of the errata, that when you start step 3 the value of t might not be well defined, however 1. the value of s is well defined and therefore does not need to be redefined, and 2. the value of t needs to be replaced with s in both locations that it occurs. Jim Algorithm _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Jim Schaad 2012-09-19T15:41:31 http://permalink.gmane.org/gmane.ietf.smime/6874 <pre> The following errata report has been submitted for RFC3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3394&amp;eid=3358 -------------------------------------- Type: Editorial Reported by: Dwayne Litzenberger &lt;dlitz&lt; at &gt;dlitz.net&gt; Section: 2.2.1 Original Text ------------- 3) Output the results. Set C[0] = A[t] For i = 1 to n C[i] = R[t][i] Corrected Text -------------- 3) Output the results. Set C[0] = A[t] For i = 1 to n C[i] = R[s][i], where s = 6n Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3394 (draft-ietf-smime-</pre> RFC Errata System 2012-09-18T03:24:27 http://permalink.gmane.org/gmane.ietf.smime/6873 <pre> The following errata report has been submitted for RFC5911, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5911&amp;eid=3128 -------------------------------------- Type: Technical Reported by: Russ Housley &lt;housley&lt; at &gt;vigilsec.com&gt; Section: 8 Original Text ------------- ContentInfo FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } ; Corrected Text -------------- ContentInfo FROM CryptographicMessageSyntaxAlgorithms-2009 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }; Notes ----- ContentInfo out to be imported from the module that is defined elsewhere in RFC 5911. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please u</pre> RFC Errata System 2012-02-18T19:59:46 http://permalink.gmane.org/gmane.ietf.smime/6872 <pre>People may be interested in the following draft. It places a security label into an email message as a rfc5322 (rfc822, rfc2822) header record. http://tools.ietf.org/html/draft-zeilenga-email-seclabel-01.html _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </pre> Jim Schaad 2011-08-09T20:32:30 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.smime