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

From: Russ Housley <[email-masked]>
Date: Thu, 19 Jul 2007 19:27:53 -0400

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.

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

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

Russ