Subject: WG Last Call: draft-ietf-smime-ibearch-03.txt

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 1 Jun 2007 14:04:29 -0400

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

 Title     : Identity-based Encryption Architecture
 Author(s) : M. Schertler, et al.
 Filename  : draft-ietf-smime-ibearch-03.txt
 Pages     : 25
 Date      : 2007-3-6
	
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-03.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 an
Informational 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.

The Last Call period will end on Friday, June 15, 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 an Informational 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

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 18 Jun 2007 05:45:08 -0400

The WG LC review period has passed.  This ID is being forwarded to the AD
for review.

spt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Turner, Sean P.
Sent: Friday, June 01, 2007 2:04 PM
To: [email-masked]
Subject: WG Last Call: draft-ietf-smime-ibearch-03.txt

	

spt

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 Jun 2007 10:54:02 -0400

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 lasy Call comment or early IETF Last Call comments.

>http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-03.txt

1) Section 2.1 says:

         Identity-based encryption (IBE) is a public-key encryption technology
         that allows a public key to be calculated from an identity and the
         corresponding private key to be calculated from the public key.

I realize that you need to start some place to explain the 
system.  However, the system is more complex than described in this 
sentence.  Without clarification, the reader gets the impression that 
anyone could compute any private key, which would be disaster.  So, 
the authors need to indicate what entity can do the described 
computation, and what prevents other entities from doing the same.

2) Section 2.3.2 says:

       PKGs MUST support TLS 1.1 [TLS] for transport of IBE private keys.

And, Section 3.1 says:

       The requesting client MUST support TLS 1.1 [TLS].

And, Section 4.2 says:

       The requesting client MUST support TLS 1.1 [TLS].

I have no problem with requiring TLS 1.1 today, but we want to 
support TLS 1.2 when it is finished, right?  I think that there is a 
way to do this without having to change this document to keep up with 
TLS protocol evolution.  Consider:

       <Entity> MUST support TLS 1.1 [TLS] or its successors, using the
       latest version supported by both parties.

3) Section 3.1 says:

       When requesting the URI the client MUST only accept the system
       parameter block if the server identity was verified successfully by
       TLS 1.1.

Please change the wording to accommodate future versions of TLS.

4) Section 3.1 include this example:

       https://ibe-0000.example.com/example.com.pem

Why "pem" for the file extension?  This file extension is used 
extensively for other uses.

5) Section 3.2 talks about the pkgURI extension.  Why use 
UTF8?  Isn't an IA5String sufficient?

6) There are errors in the ASN.1.  It does not compile!  The 
following are corrected:

         IBEIdentityInfo ::= SEQUENCE {
           district        UTF8String,
           serial          INTEGER,
           identitySchema  OBJECT IDENTIFIER,
           identityData    OCTET STRING
         }

         IBESysParams ::= SEQUENCE {
           version              INTEGER { v2(2) },
           districtName         UTF8String,
           districtSerial       INTEGER,
           validity             Validity,
           ibePublicParameters  IBEPublicParameters,
           ibeIdentitySchema    OBJECT IDENTIFIER,
           ibeParamExtensions   IBEParamExtensions
         }

       EncryptedKey ::= OCTET STRING

If you prefer, the EncryptedKey definition could be imported from CMS.

7) What MIME types are used with HTTP?  Have these types been 
discussed on the ietf-types mail list?

8) A few editorial nits:
-- s/content encryption key/content-encryption key/
-- s/UTF8STRING/UTF8String/
-- s/joint-iso-itu/joint-iso-itu-t/

Russ