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