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

From: Blake Ramsdell <[email-masked]>
Date: Tue, 07 Aug 2007 17:20:52 -0700

Russ Housley wrote:
> Draft -04 of this document came out, but many of my concerns were not 
> addressed.

Authors, where are we on this?

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: "Luther Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 17:32:58 -0700

Another version will be in later this week. 

> -----Original Message-----
> From: Blake Ramsdell [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2007 5:21 PM
> To: Luther Martin; Mark Schertler
> Cc: Russ Housley; [email-masked]; [email-masked]
> Subject: Re: Late WG Last Call Comments:
draft-ietf-smime-bfibecms-03.txt

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Aug 2007 15:16:33 -0400

Draft -05 was just posted.

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

I wish others would speak up on this point.  I think this is an 
important topic, and I expect the decision that we make here to set a 
precedent for other decisions.  I'll start another thread in case 
this subject line is being ignored by people that might be interested 
in this topic.

>>2) There is a line-wrap problem in the ASN.1 module, which makes 
>>the indenting inconsistent:
>>
>>         IBECMS-module { joint-iso-itu-t(2) country(16) us(840)
>>         organization(1)
>>           identicrypt(114334) ibcs(1) cms(4) module(5) version(1)
>>         }
>
>The fix to this one introduced another error.  Please insert the 
>missing space:
>s/organization(1)identicrypt(114334)/organization(1) identicrypt(114334)/

This problem has been fixed.

>>3) There are errors in the ASN.1.  It does not compile!  The 
>>following are corrected:
>>
>>         IBERecipientInfo ::= SEQUENCE {
>>           cmsVersion         INTEGER { v3(3) },
>>           keyFetchMethod     OBJECT IDENTIFIER,
>>           recipientIdentity  IBEIdentityInfo,
>>           serverInfo         SEQUENCE SIZE (1..MAX) OF 
>> OIDValuePairs OPTIONAL,
>>           encryptedKey       EncryptedKey
>>         }
>>
>>       EncryptedKey ::= OCTET STRING
>>
>>If you prefer, the EncryptedKey definition could be imported from CMS.
>
>The EncryptedKey definition was added, but one of the problems in 
>the IBERecipientInfo structure was not corrected.  The "SIZE" key 
>word is still missing, which causes the compile to fail.

The ASN.1 module now comples.  Thanks.

Russ