ietf-smime
[Top] [All Lists]

Re: AuthEnvelopedData Attributes

2007-01-22 19:15:05

Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:

Peter suggesting putting the attributes in a SEQUENCE instead of a SET.
  attributes SEQUENCE OF Attribute

I wish we had done this in 1999.  I feel that we missed the opportunity.  It
was not done at that time because people wanted to preserve backward
compatibility.  The pressure to keep the current encoding will be even
stronger today.

I can understand this for existing content-types, but since AuthEnvelopedData
is a new content type for which there's no backwards compatibility, it'd be an
quick and easy fix.

I wonder if people have put all of the attribute handling in a common library
routine.  If so, then making this change would be a real pain rather than a
help.  Please let me know.

Since I started this I'll give my $0.02 worth: My code does have a common
routine to do this, but it's something like:

  write:
    pre-encode attributes to get their sort order;
    sort the attributes;
    write the attributes;

(this hides a lot of detail, there's a significant amount of code to handle
the first two steps, while the last one is just a loop to write each one).  So
moving to a SEQUENCE would allow removing a large chunk of code.  Atually what
I'd probably do is change a function pointer to a write loop for new content
types and leave it pointing to the mass of code for existing content types.

(Two other notes, as the above text mentions I wasn't necessarily advocating
changing existing content-types, merely switching new ones where there's
nothing to be backwards-compatible with.  In addition this doesn't just affect
implementations, it affects interoperability because it's painful to get it
right.  In a number of cases implementors don't do it, or don't even know they
have to do it.  I know there are a number of implementations that don't
enforce the DER rules for SET OF (since there's no real point in doing it),
which leads to nasty surprises the first time they run into one that does.
Making it a plain SEQUENCE would solve all of these problems in one go).

Peter.

<Prev in Thread] Current Thread [Next in Thread>