ICV caluculation (was ASN.1 accross revs)

[Jim Toga]

I just wanted to point out a couple of things.

As Bancroft correctly points out, it is tough to do crypto on un-encoded
ASN.1.  SET and H.235 solve this by defining the open types (SIGNED,
ENCRYPTED etc...) to accomplish this.  H.323 systems shouldn't have any
issues in this area other than the ICV mechanism described wholy within
H.225.0

The ICV was dropped in kind of late in the schedule of security work for
H.323.  One of the intended goals was to make it 'light weight' in that
clients would not have to have any dynamic call back after the ASN.1 was
encoded  (this appears to be a fools paradise... ;-(  )

I would vote for adding a new 'open type' as is done from H.235 to
encompass RAS messages - essentially what Pekka had proposed for #4 in his
message.  The main issue is that it were're saying that the current ICV is
inoperable and irrelevant.  If we can get agreement on this quickly we can
incorpate it in the v2 Implementers Guide and bring it forward for v3.

Comments?
jimt.

*****************************************************
***  +1-503-264-8816(voice)              Intel - Hillsboro, OR.
    ***
***  mailto:jim.toga at intel.com         mailto:james.toga at itu.ch         ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***
*****************************************************