The draft-ietf-smime-rfc2630bis-00.txt was posted last month, but it has
not generated much discussion. I am a bit surprised, as I thought there
were a few things in it that would cause some discussion. I even marked
all of the stuff that is different that RFC 2630 to make review easy.
Well, let me start the debate.
Should we add Peter Gutmann's password-based alternative into this
document? If we believe that it will receive wide spread acceptance, then
adding to the CMS specification is not a bad idea. If we think that it is
serving a small niche, then we can simply add the top-level definition to
the CHOICE to make people aware of it's existence. At a minimum, this will
help avoid ASN.1 decode errors.
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo }
Are there other forms of RecipientInfo that need to be supported? I am
aware of one activity in ANSI X9F3 that might need one. Adding new
elements to this CHOICE will make it difficult for developers. Most ASN.1
compilers expect to know the whole set of possibilities within the
CHOICE. Of course, ticks can be played using ANY, but a more
straightforward approach that permits one pass decode of the well-known
alternatives seems like a better solution.
Perhaps adding an "other" entry is the best way to accommodate additions.
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
other [4] OtherRecipientInfo }
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
Thoughts? Comments? Flames?
Russ