Internet-Drafts | 3 Jul 19:15 2007
Picon

I-D ACTION:draft-ietf-smime-bfibecms-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the
Cryptographic Message Syntax (CMS)
	Author(s)	: L. Martin, M. Schertler
	Filename	: draft-ietf-smime-bfibecms-04.txt
	Pages		: 15
	Date		: 2007-7-3
	
This document describes the conventions for using the Boneh-Franklin 
        (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in 
        the Cryptographic Message Syntax (CMS) to encrypt content-encryption 
        keys. Object identifiers and the convention for encoding a 
        recipient's identity are also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-bfibecms-04.txt".
(Continue reading)

Internet-Drafts | 5 Jul 20:15 2007
Picon

I-D ACTION:draft-ietf-smime-ibearch-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Identity-based Encryption Architecture
	Author(s)	: M. Schertler, et al.
	Filename	: draft-ietf-smime-ibearch-04.txt
	Pages		: 24
	Date		: 2007-7-5
	
This document describes the security architecture required to 
     implement identity-based encryption, a public-key encryption 
     technology that uses a user's identity to generate their public 
     key.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-ibearch-04.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Picon

RE: CAdES implementation. The algorithm to hash attributes


Hello, all!

I'm glad that members of this list still have some interest in CAdES standard. Thanks for all your answers.

See my comments inline.

Pavel V. Smirnov
CryptoPro
Tel: +7 495 933-1168
WWW: http://www.CryptoPro.ru

> -----Original Message-----
> From: Pope, Nick [mailto:Nick.Pope <at> thales-esecurity.com]
> Sent: Monday, June 11, 2007 12:59 PM
> To: Смирнов Павел Владимирович; 'ietf-smime <at> imc.org'
> Subject: Re: CAdES implementation. The algorithm to hash attributes
> 
> 
> 
> Pavel,
> 
> Sincere apologies for missing your email from a number of months ago.
> Your
> input is welcomed although the response was very late.
> 
> This identifies what I believe to be three issues:
> 
> 1) What encoding is used?  I suggest the answer should be the
> equivalent to the note as for archive time-stamp.
(Continue reading)

Pope, Nick | 6 Jul 18:11 2007

RE: CAdES implementation. The algorithm to hash attributes


Pavel,

In response to your question:

> 	This would be great. But why do we not add a requirement for these
> attributes to be transmitted in DER form like it was done in CMS for
> signed and authenticated attributes?

In the case of the Archive Time-stamp, which may be added by the recipient,
the data being time-stamped will include unsigned attributes and content
which may not be encoded in DER when transmitted.  Also, in the cases of
ES-C timestamps the data being time-stamped is also unsigned.  It might be
feasible to re-encode the ES-C attributes in DER when applying a time-stamp,
but it could be a major burden re-encoding data for a archive time-stamp.

Nick

> -----Original Message-----
> From: spv <at> cryptopro.ru [mailto:spv <at> cryptopro.ru]
> Sent: 06 July 2007 13:50
> To: Pope, Nick; ietf-smime <at> imc.org
> Subject: RE: CAdES implementation. The algorithm to hash attributes
> 
> 
> Hello, all!
> 
> I'm glad that members of this list still have some interest in CAdES
> standard. Thanks for all your answers.
> 
(Continue reading)

Pope, Nick | 6 Jul 18:14 2007

RE: CAdES implementation. The algorithm to hash attributes


Pavel,

Apologies - I missed off the second point regarding including the notes in
the standard, I will discuss doing this with my colleagues at an ETSI
meeting week after next.

Nick

> -----Original Message-----
> From: Pope, Nick
> Sent: 06 July 2007 17:11
> To: '??????? ????? ????????????'; ietf-smime <at> imc.org
> Subject: RE: CAdES implementation. The algorithm to hash attributes
> 
> Pavel,
> 
> In response to your question:
> 
> > 	This would be great. But why do we not add a requirement for these
> > attributes to be transmitted in DER form like it was done in CMS for
> > signed and authenticated attributes?
> 
> In the case of the Archive Time-stamp, which may be added by the
> recipient, the data being time-stamped will include unsigned attributes
> and content which may not be encoded in DER when transmitted.  Also, in
> the cases of ES-C timestamps the data being time-stamped is also unsigned.
> It might be feasible to re-encode the ES-C attributes in DER when applying
> a time-stamp, but it could be a major burden re-encoding data for a
> archive time-stamp.
(Continue reading)

Pavel V. Smirnov | 10 Jul 15:46 2007
Picon

RE: CAdES implementation. The algorithm to hash attributes


Nick,

> > 	This would be great. But why do we not add a requirement for
> these
> > attributes to be transmitted in DER form like it was done in CMS for
> > signed and authenticated attributes?
> 
> In the case of the Archive Time-stamp, which may be added by the
> recipient,
> the data being time-stamped will include unsigned attributes and
> content
> which may not be encoded in DER when transmitted.  Also, in the cases
> of
> ES-C timestamps the data being time-stamped is also unsigned.  It might
> be
> feasible to re-encode the ES-C attributes in DER when applying a time-
> stamp,
> but it could be a major burden re-encoding data for a archive time-
> stamp.

	So this is what I suggested. I certainly had not have in mind an
Archive Time-stamp attribute. Let's add another note (may be just
recommended, not required) for ES-C timestamps to reencode data being
time-stamped in DER before calculating a hash.

Pavel Smirnov
Crypto-Pro
Tel./Fax: +7 495 933-1168
WWW: http://www.CryptoPro.ru
(Continue reading)

Russ Housley | 20 Jul 01:11 2007

Re: Late WG Last Call Comments: draft-ietf-smime-ibearch-03.txt


The recently posted -04 version of this document resolves the 
concerns that I posted about the -03 version.

Russ

Russ Housley | 20 Jul 01:27 2007

Re: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt


Draft -04 of this document came out, but many of my concerns were not 
addressed.

At 12:17 PM 6/25/2007, Russ Housley wrote:
>I was not able to review this document before WG Last Call 
>ended.  However, I do have some comments.  Please treat them as late 
>WG Last Call comment or early IETF Last Call comments.
>
> > http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
>
>1) Section 2 defines EmailIdentitySchema as a UTF8String.  The text says:
>
>       E-mail addresses that contain non-ASCII
>       characters MUST be encoded using punycode [RFC3492].
>
>Therefore, the result of the encoding should always be ASCII.  Why 
>is an UTF8 String needed?

I understand that the authors are receiving conflicting advice from 
Jim Schaad and myself.  I have sent email to Jim to try and 
understand his point of view, but Jim has not responded.  The text 
was updated to use UTF8, without requiring punycode.  I think this 
was the wrong way to resolve this one.  I would prefer to retain the 
use of punycode and carry the email address in an IA5 string.  The 
reason that I prefer this solution is that traditional character 
comparison routines can be used.

Since Jim is not engaging in the conversation, I would like to know 
what others think.
(Continue reading)

Turner, Sean P. | 22 Jul 22:24 2007

RE: WG Last Call: draft-ietf-smime-cms-aes-ccm-and-gcm-02.txt


The WG LC review period has long passed. This ID will be forwarded to the AD
for review.

spt

-----Original Message-----
From: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-smime <at> mail.imc.org]
On Behalf Of Turner, Sean P.
Sent: Monday, June 18, 2007 5:46 AM
To: ietf-smime <at> imc.org
Subject: WG Last Call: draft-ietf-smime-cms-aes-ccm-and-gcm-02.txt

This message initiates an SMIME Working Group Last Call on the document: 

 Title     : Using AES-CCM and AES-GCM Authenticated Encryption in
             the Cryptographic Message Syntax (CMS)
 Author(s) : R. Housley
 Filename  : draft-ietf-smime-cms-aes-ccm-and-gcm-02.txt
 Pages     : 11
 Date      : 2007-5-2
	
This document specifies the conventions for using the AES-CCM and the
AES-GCM authenticated encryption algorithms with the Cryptographic Message
Syntax (CMS) authenticated-enveloped-data content type.

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-aes-ccm-and-gcm-02.
txt

(Continue reading)

Turner, Sean P. | 22 Jul 22:24 2007

RE: WG Last Call: draft-ietf-smime-cms-auth-enveloped-04.txt

The WG LC review period has long passed. This ID will be forwarded to the AD for review.

spt


From: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Turner, Sean P.
Sent: Monday, June 18, 2007 5:49 AM
To: ietf-smime <at> imc.org
Subject: WG Last Call: draft-ietf-smime-cms-auth-enveloped-04.txt

This message initiates an SMIME Working Group Last Call on the document:

 Title     : Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data
             Content Type
 Author(s) : R. Housley
 Filename  : draft-ietf-smime-cms-auth-enveloped-04.txt
 Pages     : 11
 Date      : 2007-4-26
       
This document describes an additional content type for the Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-04.txt

The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Standard Track RFC.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may be sent to the document editor.

****NOTE****

There has been much discussion on the ordering of the authAttrs field and the number of authAttrs field(s). Pay special attention to this issue during the review.

****NOTE****

The Last Call period will end on Monday, July 2, 2007.

Upon completion of the last call, the WG chairs will take action based upon the consensus of the WG. Possible actions include:

    1) recommending to the IETF Security Area Directors
       that the document, after possible editorial or
       other minor changes, be considered by the IESG
       for publication as a Standards Track RFC
       (which generally involves an IETF-wide Last Call); or

    2) requiring that outstanding issues be adequately
       addressed prior to further action (including,
       possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process.  So, please read and comment!

spt


Gmane