Jim:
9. Section 9.2: Was there a reason for removing the "rather than the
implcit [0] .." phrase. This exists in the process for signed data and I
think should be here as well.
For authenticated-data, digests are only computed on the content. They are
never computed on the attributes. The IMPLICIT [0] stuff was about the
attribute encoding.
I don't follow your response. What I am looking at is the text relating to
the creation of the authenticatedAttributes blob over which the MAC will be
computed. This is yet another location where the ASN which is encoded and
sent is not the same as the ASN which is acutally MAC-ed. I think this
should be very explicit like in the other cases.
The text was reworded do to the introduction of the authAttributesInfo
structure. Due to your previous comments regarding one pass processing, that
structure has been split up. Now, text desling with IMPLICIT [2] will be
added.
Proposed text:
If authenctiatedAttributes field is present, the content-type attribute (as
described in Section 11.1) and the message-digest attribute (as described in
section 11.2) must be included, and the input to the MAC calculation process is
the DER encoding of authenticatedAttributes. A separate encoding of the
authenticatedAttributes field is performed for message digest calculation. The
IMPLICIT [2] tag in the authenticatedAttributes 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 [2] tag, is to be included in the
message digest calculation along with the length and content octets of the
authenticatedAttributes value.
14. Section 12.3.3 Last paragarph. What is this paragraph doing here? It
is talking about key agreement in the symetric key-encryption section.
The output of a key agreement algorithm is a key-encryption key, and this
key-encryption key is used to encrypt the content-encryption key. The last
paragraph is a backward pointer telling folks that the same techniques are
used
regardless of the source of the key-encryption key. I will add an sentence
to
the front of this paragraph that hopefully makes this more clear.
I don't understand this even with your explination.
The last paragraph tells the implementor that the key wrapping algorithm will
also appear as a parameter to the key agreement algorithm identifier.
15. Section 12.6.2 - You have not modified the key wrap algorithm to allow
for arbitrary length RC2 key sources.
Are you suggesting an explicit length field or something else?
We need to either put in an explicit length field or use a known padding
algorithm. I have no perference on which is used but something along this
lines is absolutely required.
Please provide text. I still am not sure what change you want. Maybe you
should coordinate with with Eric (ekr(_at_)rtfm(_dot_)com) to ensure
consistency with the
X9.42 document.
Russ