Russ,
I don't believe there's any advantage to having unauthenticated
ContentHints. My original receipt processing proposal said this:
"The contentHints attribute must only be used as an authenticated
message attribute."
That being the case, I suggest we change ESS-00 to reflect that
contentHints must be authenticated. However, I also like your
idea of renaming the arc -- there are other attributes that need
to be added, and they don't all allegedly need to be authenticated.
Scott
-----Original Message-----
From: Russ Housley [SMTP:housley(_at_)spyrus(_dot_)com]
Sent: Wednesday, November 26, 1997 10:58 AM
To: Scott Hollenbeck
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: ESS-00 ContentHints Attribute
What advantage is there to putting ContentHints in the unauthenticated
attributes?
If it us an issue, I can change the name of the OID Arc so that it is
attributes (authenticated and unauthenticated) without changing the numbers.
Russ
At 05:10 AM 11/26/97 PST, Scott Hollenbeck wrote:
Section 1.3.4 of the 18 November ESS-00 documents says that
a contentHints attribute has a "MUST BE authenticated" value
of "no". However, the OID registry found at
http://www.imc.org/ietf-smime/oids.html
Lists the id-aa-contentHint attribute under the authenticated
attributes arc. In my mind, this implies that the attribute
must be authenticated if present. Should the attribute
always be authenticated (thus requiring a change to ESS-00),
or should we add an arc for attributes that can be either
authenticated or not?