Russ Housley wrote:
Peter:
Your argument about SEQUENCE vs SET sounds wrong to me: If you have
an implicit tagging that
replaces sequence or set, then coding or decoding becomes essentially
the same except that you
won't need to sort the attributes before coding, but it wouldn't hurt
if you do. On the other
hand, if you really verify the order when decoding, then sequence
hurts, but there are several
implementations which ignore the encoded order as far as I know and
others which fail to
sort etc.
Such implementations would not be considered compliant with RFC 3852
or any of its predecessors, including PKCS#7 v1.5. I do not think we
should penalize implementors that followed the specification.
Right. But that was not the point. no matter IMO anyway.
I'm pleased to listen to implementors on this point. So far, two have
spoken. One suggesting the move to SEQUENCE and one preferring to use
their existing attribute handling routines. Both said, that it was
not a really big deal either way. Given that input, I went with
consistency with AuthenticatedData.
What do you mean with consistency with AuthenticatedData? Isn't it the
same as with SignedData?
Having them before is not what I would call consistant. I think you may
consider two sets.
Russ
smime.p7s
Description: S/MIME Cryptographic Signature