draft-housley-ct-keypackage-receipt-n-error-01.txt

The -01 version addresses most, but not all, of the comments submitted by Jim Schaad.

Russ

> From: internet-drafts <at> ietf.org
> Date: May 2, 2013 10:11:28 AM EDT
> To: Russ Housley <housley <at> vigilsec.com>
> Subject: New Version Notification for draft-housley-ct-keypackage-receipt-n-error-01.txt
> 
> 
> A new version of I-D, draft-housley-ct-keypackage-receipt-n-error-01.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
> 
> Filename:	 draft-housley-ct-keypackage-receipt-n-error
> Revision:	 01
> Title:		 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types
> Creation date:	 2013-05-02
> Group:		 Individual Submission
> Number of pages: 25
> URL:             http://www.ietf.org/internet-drafts/draft-housley-ct-keypackage-receipt-n-error-01.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-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-housley-ct-keypackage-receipt-n-error-01
> 
> 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

Biggest Fake Conference in Computer Science

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

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 <at> ietf.org
> Date: April 18, 2013 11:12:54 AM EDT
> To: housley <at> 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

[Editorial Errata Reported] RFC3394 (3361)

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&eid=3361

--------------------------------------
Type: Editorial
Reported by: Dwayne Litzenberger <dlitz <at> dlitz.net>

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]

[Editorial Errata Reported] RFC3394 (3358)

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&eid=3358

--------------------------------------
Type: Editorial
Reported by: Dwayne Litzenberger <dlitz <at> dlitz.net>

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

[Technical Errata Reported] RFC5911 (3128)

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&eid=3128

--------------------------------------
Type: Technical
Reported by: Russ Housley <housley <at> vigilsec.com>

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
-----

New draft of interest

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/smime

SecureComm2011 - Call for Posters

_______________________________________________
smime mailing list
smime <at> ietf.org
https://www.ietf.org/mailman/listinfo/smime

Last Call: <draft-gutmann-cms-hmac-enc-05.txt> (Using MAC-authenticated Encryption in the Cryptographic Message Syntax (CMS)) to Proposed Standard

The IESG has received a request from an individual submitter to consider
the following document:
- 'Using MAC-authenticated Encryption in the Cryptographic Message Syntax
   (CMS)'
  <draft-gutmann-cms-hmac-enc-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2011-07-20. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies the conventions for using MAC-authenticated
   encryption with the Cryptographic Message Syntax (CMS) authenticated-
   enveloped-data content type.  This mirrors the use of a MAC combined
   with an encryption algorithm that's already employed in IPsec, SSL/
   TLS, and SSH, which is widely supported in existing crypto libraries
   and hardware, and has been extensively analysed by the crypto
   community.

DOWNREF

   This specification contains one normative references to a proposed
   standard: RFC 2898.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-gutmann-cms-hmac-enc/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-gutmann-cms-hmac-enc/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
smime mailing list
smime <at> ietf.org
https://www.ietf.org/mailman/listinfo/smime

Fwd: Document Action: 'Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)' to Informational RFC (draft-housley-rfc5008bis-01.txt)

FYI

-------- Original Message --------
Subject: Document Action: 'Suite B in Secure/Multipurpose Internet Mail 
Extensions (S/MIME)' to Informational RFC	(draft-housley-rfc5008bis-01.txt)
Date: Tue, 26 Apr 2011 11:48:57 -0700
From: The IESG <iesg-secretary <at> ietf.org>
To: IETF-Announce <ietf-announce <at> ietf.org>
CC: RFC Editor <rfc-editor <at> rfc-editor.org>

The IESG has approved the following document:
- 'Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)'
   (draft-housley-rfc5008bis-01.txt) as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-housley-rfc5008bis/

Technical Summary

   The United States Government has published guidelines for
   "NSA Suite B Cryptography", which defines cryptographic
   algorithm policy for national security applications. This
   document defines a profile of S/MIME which is conformant with
   Suite B.

Working Group Summary

   This document is not the product of any IETF working group.

Document Quality

    This document explains the requirements for as S/MIME
    implementation to be considered "Suite B conformant".
    There is strong consensus from the people that are
    defining "Suite B".

Personnel

    Russ Housley (housley <at> vigilsec.com) is the document shepherd.
    Sean Turner (turners <at> ieca.com) is the responsible Area Director.
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
smime mailing list
smime <at> ietf.org
https://www.ietf.org/mailman/listinfo/smime

New ID of possible interest

I would like to inform the SMIME working group of a newly-submitted
Internet Draft that may be of interest:

 The With-MAC key-wrapping algorithm for Cryptographic Message Syntax

  draft-herzog-withmac-keywrap-00

Abstract:

   This document describes a new key-wrapping algorithm to be used in
   the EnvelopedData, AuthenticatedData and AuthEnvelopedData structures
   of the Cryptographic Message Syntax.  Because these structures do not
   provide data-origin authentication, a recipient cannot
   cryptographically verify that the plaintext received was the
   plaintext encapsulated by the message's original sender.  The With-
   MAC key-wrapping algorithm allows an EncryptedKey value to hold both
   a wrapped symmetric key and a MAC value on the data to be
   authenticated.  When used in EnvelopedData, AuthenticatedData and
   AuthEnvelopedData structures, therefore, these structures can achieve
   data-origin authentication (in some circumstances) using only
   symmetric-key algorithms.

https://datatracker.ietf.org/doc/draft-herzog-withmac-keywrap/

A side note: this draft should probably be read in combination with our previous draft on static-static
ECDH (https://datatracker.ietf.org/doc/draft-herzog-static-ecdh/). That draft described how a
sender might use a certified ECDH key to create an EnvelopedData structure (for example). It is unclear,
however, how such a sender could also provide data-origin authentication without using digital
signatures. However, that requires a certified signature-capable key, something they may not have.
This draft provides an alternate approach-- the sender provides a MAC value for each recipient.

We welcome all comments and reviews.

Thank you.

--

-- 
Jonathan Herzog							voice:  (781) 981-2356
Technical Staff							fax:    (781) 981-7687
Cyber Systems and Technology Group		email:  jherzog <at> ll.mit.edu
MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
244 Wood Street    
Lexington, MA 02420-9185

_______________________________________________
smime mailing list
smime <at> ietf.org
https://www.ietf.org/mailman/listinfo/smime