sorry i had to resend cos few of them had problem with my domain
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?
& does the CONSTRAINED BY which is a user-defined constraint, can it
be ignored here?
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
Thanks a lot
Naveen Kumar B K
Encore Software Limited
_______________________________________________
ASN1 mailing list
[EMAIL PROTECTED]
http://lists.asn1.org/mailman/listinfo/asn1