http://blog.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 different set of possible values. Thus we use a single global set in the update to 5272 for the definition of Cmc-Control-Set. I would say that if you expect this to be used in a different document then using a parameter makes sense. Otherwise I would use a fixed object set in this location. Jim _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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 for this draft is: https://datatracker.ietf.org/doc/draft-turner-ct-keypackage-receipt-n-error-algs There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-algs-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-turner-ct-keypackage-receipt-n-error-algs-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-ct-keypackage-receipt-n-error-algs There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-algs-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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 not need to understand the key package identifier 3 - say that you ignore things you do not understand and process the package but do not return a receipt. I'll security That's fine - I thought it might be something like that. The explanations are just fine. I merely find the names odd. I would have expected something more along the lines of errorOnPackage - name of package errorReportedBy - That is longer more descriptive names. But as I said - I don't really care that much. Ok - that is what is reflected. one. single Ok - I can see this as being reasonable. Ok - may not be correct behavior in all cases, but that can be application specific and that is the rule you are using in this application. presumes. types It also allows for a list of authorized contents to be associated with a signer certificate as well I thought. If so then this description would seem to not allow for that case. That is the current signing certificate can be more restrictive than the TA is. attribute. Good Good Yes that deals with the issue. there I was thinking in terms of something similar to the attacks that exist for the RSA v1.5/OAEP differences. There may be something that may leak information to an attacker that could be useful. However I think that the comment on 29 probably addresses this issue as well. algorithm I might prefer s/used by the content signer/used in the signature algorithm/ However this was a double check so the current text is probably sufficient. applies Ok - I can see this this Good Ok Yes - I had forgotten that type. Again - that covers the issue attribute. legal. Yes that works Yes that deals with the issue That is fine with me, I was just making sure that you had considered the issue. Looks good information. Yes that addresses the issues that I was looking at that Ok - no big deal. Welcome - jim _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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 Signed-data content type described in Section 5 of [RFC5652]. Authenticated attributes are carried in the CMS Authenticated-data content type described in Section 9 of [RFC5652] or in the CMS Authenticated-enveloped-data content type described in Section 2 of [RFC5083]. Content attributes are carried in the Content-with-attributes content type described in Section 3 of [RFC4073]. Even though the ATTRIBUTE syntax is defined as a SET OF AttributeValue, a key-package-identifier-and-receipt-request attribute MUST have a single attribute value; zero or multiple instances of AttributeValue are not permitted. I'd rather not rehash this discussion, Instead, I'd like to follow the convention used in CMS. Yes, the reader is warned that this definition is different. This is also a reason not to import the definition: </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 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. _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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 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. review Receipt http://datatracker.ietf.org/doc/draft-housley-ct-keypackage- _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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-00) -------------------------------------- Title : Advanced Encryption Standard (AES) Key Wrap Algorithm Publication Date : September 2002 Author(s) : J. Schaad, R. Housley Category : INFORMATIONAL Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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-aes-keywrap-00) -------------------------------------- Title : Advanced Encryption Standard (AES) Key Wrap Algorithm Publication Date : September 2002 Author(s) : J. Schaad, R. Housley Category : INFORMATIONAL Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/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 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. -------------------------------------- RFC5911 (draft-ietf-smime-new-asn1-07) -------------------------------------- Title : New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME Publication Date : June 2010 Author(s) : P. Hoffman, J. Schaad Category : INFORMATIONAL Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ smime mailing list smime&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/smime </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