You wrote two messages
Russ Housley wrote:
I'd like to add one point. Please look at section 9 of RFC 3852. The
authenticated attributes in AuthenticatedData follow choice B).
I think that authenticated attributes in AuthenticatedData also follows A.
The question is badly presented anyway: Do you ask whether the input of
the hash function used to
calculate the hash of the authenticated attributes is not identical with
the transmitted encoding
as with AuthenticatedData and SignedData (choice A) or whether it is
identical? (B)?
Russ
At 01:34 PM 3/27/2007, Turner, Sean P. wrote:
At IETF 68, Russ Housley presented an summary of the
Authenticated-Enveloped-Data content type (the slides can be found at
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68
<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68>
). There was one open issue (the last slide) that dealt with the
encoding of authenticated attributes. It was discussed at the
meeting; however, responses from a wider audience (i.e., this list)
is necessary. Please indicate your preference on whether:
A) The encoding of the authenticated attributes should be done
exactly the same as in SignedData.
B) The encoding of the authenticated attributes should use the
encoding that will be transmitted.
We are soliciting feed until 10 April 2007.
spt
Russ Housley wrote:
The encoding issue raised by Peter and Peter needs to be very clear.
The current document really handles this by reference, which is
probably not the best.
I suggest the re-write of the 3rd paragraph of section 2.2 to handle
this directly instead of by reference:
If optional authenticated attributes are present, then they are DER
encoded. A separate encoding of the authAttrs field is performed to
construct the authenticated associated data (AAD) input to the
authenticated encryption algorithm. The IMPLICIT [1] tag in the
authAttrs field is not used for the DER encoding, rather an EXPLICIT
SET OF tag is used. That is, the DER encoding of the SET OF tag,
rather than of the IMPLICIT [1] tag, is to be included in the
construction of the AAD along with the length and content octets of
the authAttrs value. If the authenticated encryption algorithm
requires the AAD to be padded to a multiple of some block size, then
the padding MUST be added as described in Section 6.3 of [CMS]. This
padding method is well defined if and only if number of octets in the
block size is less than 256.
Russ
Now I get lost? What is then the strong poll for, isn't this proposed
section choice A?
Anyway, the other problem of 'one pass' has not been addressed. What is
necessary: I think it would be helpful to have a like like:
- some information concerning each recipient available before the data
- some information concerning the sealing parties available after the data
- some global information (like helpful messagedigest etc).
regards
peter
smime.p7s
Description: S/MIME Cryptographic Signature