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(_at_)augustcellars(_dot_)com> 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.
smime.p7s
Description: S/MIME Cryptographic Signature