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

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

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.

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

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.

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

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

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.

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

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