On Tue, 30 Jun 1998, Pete Cordell wrote:
I admit that I am only just hanging in there with this debate, but I think I have a possible solution 5 to throw in as a contender.
Looking at the problem a bit laterally, we have RasMessage in UDP packets that we want to sign, and H323-UserInformation in the UUIE that we want to sign. Currently these are the only chunks of ASN.1 in these fields.
We could add a second piece of ASN.1 into these fields (UDP packet and UUIE) that contains the signatures, such as:
H323Extra ::= CHOICE { icv ICV, ... }
This would be a separate ASN.1 tree. Therefore in a RAS UDP packet you would get:
RasMessage chunk of ASN.1 H323Extra chunk of ASN.1 typically containing signatureSimilarly in the UUIE, you would have
H323-UserInformation chunk of ASN.1 H323Extra chunk of ASN.1Note that all the key ids and time stamps etc., would remain in the RasMessage and H323-UserInformation parts (so they get signed).
I agree this is not beautiful, but it does not require multiple ASN.1 encodings, and doesn't radically change the format of the message depending on whether you want to sign it or not (as solution 4 seems to).
This crossed my mind a couple days ago, but it is not clear how this would be backward compatible. That is, how would an older version handle this added information that comes after the H323-UserInformation? I like the general idea, but if I am not mistaken it is not backward compatible.
I have an idea as to how to do as you suggest in a backward compatible manner, but before I go down that path I need to know the answer to the question: Are the most recent implementations that know of H.323 required to transmit an ICV with each RasMessage or H323-UserInformation?
-------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos@oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636