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:
Now I get lost? What is then the strong poll for, isn't this proposed section choice A?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
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature