1. Here is the structures for SIGNED,ENCRYPTED and HASHED present in
H235v2 on security issues for H323:
SIGNED { ToBeSigned } ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmOID OBJECT IDENTIFIER,
paramS Params, -- any "runtime" parameters
signature BIT STRING -- could be an RSA or an ASN.1 coded ECGDSASignature
} ( CONSTRAINED BY { -- Verify or Sign Certificate --
} )
Our doubts:
Our ASN generator is not accepting { }. So we are not able to
generate ASN file for SIGNED with parameter ToBeSigned. But we
generated ASN file for SIGNED by omitting { }. In SIGNED structure we
have field toBeSigned of type ToBeSigned which is passed parameter.
We generated files for SIGNED with three different datatypes for the
parameter toBeSigned as in H.235. But, we have more than three
datatypes in H.225. So we have to write two more instances SIGNED
and not able generalize the parameter ToBeSigned
. So wht should we do to generalize the parameter ToBeSigned? if not
possible then can we manually write different structure for the
different datatypes ?
2. EncodedGeneralToken ::= TYPE-IDENTIFIER.&Type (ClearToken --
general usage token -- )
For the TYPE_IDENTIFIER, we are still not clear about its datatype.
But as found in OpenH323, OpenType is being used for TYPE_IDENTIFIER
and its structure contains:
typedef struct { /* generic open type data structure */
ASN1UINT numocts;
const ASN1OCTET* data;
} ASN1OpenType;
It means that it is just an octet string. So., we have decided either
to directly assign EncodedGeneralToken as OCTET_STRING or to use the
above structure.
Is our understanding right?
3. IMPORTS
SIGNED{},
ENCRYPTED{},
HASHED{},
ChallengeString,
TimeStamp,
RandomVal,
Password,
EncodedPwdCertToken,
ClearToken,
CryptoToken,
AuthenticationMechanism
FROM H235SECURITYMESSAGES
In H.225 we have the above variables as imported from H.235. But in
our ASN generator, separate files are being created for each Structure
with dummy fields. For eg., For TimeStamp structure a separate file
H225TimeStamp.h is being created instead of importing that file from
H.235. So we are not able to import from H.235 folder.
So., we think that all the ASN files should be regenerated to include
H.235 structures in H.225.
Is that correct?
With Regards,
Shridhar & Naveen.
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/
