I would like to clarify something when I questioned the placement of authenticated attributes and when I suggested two sets: First, IMO whatever is called authenticated attributes should follow the same logic as in other formats, i.e. the come after the data and have exactly the same usage. Otherwise this seems to me a source of possible confusion, and, furthermore, it would no longer be possible to define new attributes independantly from the usage. Second, if something new (and this is the case here) is needed that must be placed before the data, then call it differently and use explicitely a different set of values. Peter Peter Gutmann wrote:
"Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx> writes:If this was in the original days of how an RFC worked, I would suggest that what happens is that two different structures be created. One with the attrs first, one with the attrs last. We could then spend some time (at least 6 months) doing implementations and playing and then adopt one when the RFC progressed along the standards track.That may not be such a bad idea. The problem at the moment is that we have no actual implementation experience with this, so people's arguments are based on hypothesised usage cases. I've been working on an implementation (to resolve a different issue, which has now been sorted out), if anyone else has implemented this I'd be interested in doing some interop testing. Peter.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature