first thank you all,
>> & does the CONSTRAINED BY which is a user-defined constraint, can it
>> be ignored here?
> I think the anwser may be yes. According to the ASN.1 standard X.682, user- >
> defined constraint is
> equivalent to a special ASN.1 comment. If you are designing a general testing >
> device, ignoring
> the user-defined constraint is a good idea because the general tool can not deal >
> with it easily.
> However, if you are constructing a tool to handle the H.323 protocol suite
> > specially, you may
> need the constraint and develop a special H.323 tool to extract the constraint >
> and handle it.
Naveen-> yes iam trying to construct a tool to handle H.323 protocol
suite, so then how do i proceed?? how are the structures defined now,
if i cant ignore the CONSTRAINED BY which is a user-defined
constraint?
>Author Name: Wang Hao
> > In the ITU-T Recommendation H.235 I found the ASN.1 expression
> >
> > 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 -- } )
> >
> > this is my understanding of above structure N::= SIGNED { XYZ }
> >
> > is equalent of
> >
> > N::=SEQUENCE {
> > toBeSigned XYZ,
> > 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 -- } )
> >
> > is my understanding right?
>
>
> Yes, for the purposes of encoding. However, it probably better be
> compiled into something that facilitates computing a signature
> of XYZ. Some special structure or something. Depends on the compiler
> though.
>
> > & does the CONSTRAINED BY which is a user-defined constraint, can it
> > be ignored here?
>
>
> Only if you want do deliberately break the protocol this structure
> is defined for. An example would be if you want to display the contents
> of the bad certificate without doing any computations to Verify or
> Sign the certificate.
>
>
>
Naveen-> no i do not want to break the protocol this structure is
defined for. so hw do i proceed?
> > ENCRYPTED { ToBeEncrypted } ::= SEQUENCE {
> > algorithmOID OBJECT IDENTIFIER,
> > paramS Params, -- any "runtime" parameters
> > encryptedData OCTET STRING
> > } ( CONSTRAINED BY { -- Encrypt or Decrypt -- ToBeEncrypted } )
> >
> > HASHED { ToBeHashed } ::= SEQUENCE {
> > algorithmOID OBJECT IDENTIFIER,
> > paramS Params, -- any "runtime" parameters
> > hash BIT STRING
> > } ( CONSTRAINED BY { -- Hash -- ToBeHashed } )
> >
> > the ENCRYPTED & HASHED structures, also have same issues as SIGNED
>
>
> They are the same. These syntaxes are defined in X.683 (ISO 8824-4),
> Parametrization of ASN.1 specifications.
>
> > Thanks a lot
> >
> > Naveen Kumar B K
> > Encore Software Limited
> > _______________________________________________
> > ASN1 mailing list
> > [EMAIL PROTECTED]
> > http://lists.asn1.org/mailman/listinfo/asn1
>
> --
> Lev Walkin
> [EMAIL PROTECTED]
>
_______________________________________________
ASN1 mailing list
[EMAIL PROTECTED]
http://lists.asn1.org/mailman/listinfo/asn1
