Dear All,
I'm implementing some of the H.235 stuff and have a few concerns.
RandomVal is defined as INTEGER only. This is not a particularly helpful definition as in theory this could be a million bit + integer if needed. Not many computers support such types! In fact, a well known ASN.1 compiler maps this to an int which is a signed 32-bit value on our platform. Is this sufficient? Without further discussion about the range of this value I feel there is a potential for interoperability problems.
Perhaps we can say that RandomVal will never be more than 32 bits long, and then add a type like RandomSeq as an OCTET STRING for cases when we need a longer random value.
There are also a few other issues, for example:
nonStandardParameter in H.235 is defined differently to that in H.225. Why is that?
Similarly tokenID only takes an OID. Again, why such a limited format?
Regards,
Pete
============================================= Pete Cordell pete@tech-know-ware.com =============================================
On Wed, 8 Sep 1999, Pete Cordell wrote:
I'm implementing some of the H.235 stuff and have a few concerns.
RandomVal is defined as INTEGER only. This is not a particularly helpful definition as in theory this could be a million bit + integer if needed. Not many computers support such types! In fact, a well known ASN.1 compiler maps this to an int which is a signed 32-bit value on our platform. Is this sufficient? Without further discussion about the range of this value I feel there is a potential for interoperability problems.
Perhaps we can say that RandomVal will never be more than 32 bits long, and then add a type like RandomSeq as an OCTET STRING for cases when we need a longer random value.
I disagree. That would be a limitation of the tool and should be corrected by the tool vendor.
Note that if the ASN.1 compiler that you are using supports the industry-standard compiler directives then you can say:
--<ASN1.HugeInteger H235-SECURITY-MESSAGES.RandomVal>--
which instructs the ASN.1 compiler to represent RandomVal locally in a format suitable for holding extremely large integer values of the kind you have in mind. The encoding of such values are as specified by the encoding rules, independent of the local representation.
Such directives were made an industry standard two or three years ago by a consortium of companies including Sun, IBM, OSS Nokalva, Hewlett Packard, Ericsson and others, and you can expect up to date compilers to support them.
-------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-609-987-9073 baos@oss.com Tech Support :1-732-302-9669 http://www.oss.com Fax :1-732-302-0023
Pete,
Bancroft is correct in criticizing tools that don't handle indefinite-precision integers; however, in practice, I totally agree with you. Sad to say, but it is very likely that quite a few (most?) implementations will fail when confronted with, for example, a 33-bit integer. On previous occasions, limitations of ASN.1 tools have been taken into consideration when choosing a particular syntax, so it's not unprecedented to do this again.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, September 08, 1999 2:26 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Issues with H.235
Dear All,
I'm implementing some of the H.235 stuff and have a few concerns.
RandomVal is defined as INTEGER only. This is not a particularly helpful definition as in theory this could be a million bit + integer if needed. Not many computers support such types! In fact, a well known ASN.1 compiler maps this to an int which is a signed 32-bit value on our platform. Is this sufficient? Without further discussion about the range of this value I feel there is a potential for interoperability problems.
Perhaps we can say that RandomVal will never be more than 32 bits long, and then add a type like RandomSeq as an OCTET STRING for cases when we need a longer random value.
There are also a few other issues, for example:
nonStandardParameter in H.235 is defined differently to that in H.225. Why is that?
Similarly tokenID only takes an OID. Again, why such a limited format?
Regards,
Pete
============================================= Pete Cordell pete@tech-know-ware.com =============================================
participants (3)
-
Bancroft Scott -
Paul Long -
Pete Cordell