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@intel.com mailto:james.toga@itu.ch *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************