Hi Matt,
I found the initial definition is my best try to model the ANS1 structure as
probably described In the rfc2743
Problem is that the bytes of the innerContextToken is completely depended upon
the value of the OID from the mech. As long I understand the bytes of the
innerContextToken must not be in DER encoded format.
In my case it hust happens to be a DER encoded structure because the OID
Value is the OID of the spnego mechanism.
The encoded structure to realize is “just” the following if the OID (<mech>) is known
and the corresponding bytes for the innerContextToken (mechToken)
0x0a <sizeof DER encoded mech plus number bytes of mechToknen> 0x06 0x06 <mech> <mechToken>
I hope that’s understandable. I thought it would be nice to use the functionality offered
By openssl to encode this data 8the next step would even be to decode such a structure),
but I think it isn’t a real DER encoded ANS1 structure, but somehow only relates to that.
Thus I think I have to “manually” encode the OID and innerContextToken.
Best regards
Max
From:
openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of Matt Caswell <matt@xxxxxxxxxxx>
Date: Friday, 5. November 2021 at 11:41
To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx>
Subject: Re: ASN1 <-> DER encoding with application tag
On 04/11/2021 17:39, Max Larsson wrote:
> But now I’m wondering how I can “cascade” using this method to influence
> the encoding
>
> to avoid the writing of the additional bytes after the OID gest encoded
> and before
>
> the innerToken is encoded:
>
> *….. *0x05 0x05 0x02 *0x04 0x76* 0xa0 0x74….(here are a lot of bytes
> omitted)
I think this is an entirely different problem.
0x04 corresponds to the universal tag for an OCTET STRING, and 0x76 is
the length of that OCTET STRING.
I assume what you want to see is 0xa0, which means a context specific
constructed type with tag 0, followed by data of length 0x74.
So, basically, it looks to me like your initial definition of the
GSSAPI_CONTEXTTOKEN object is wrong:
typedef struct ContextToken_st {
ASN1_OBJECT *mech;
ASN1_OCTET_STRING *innerContextToken;
} GSSAPI_CONTEXTTOKEN;
Since this clearly shows that the thing after the OID is an OCTET
STRING. So you really need to understand what the actual type is for
innerContextToken in order to correctly encode/decode it.
Matt
>
> Best regards
>
> Max
>
> *From: *openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of
> Matt Caswell <matt@xxxxxxxxxxx>
> *Date: *Thursday, 4. November 2021 at 17:14
> *To: *openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx>
> *Subject: *Re: ASN1 <-> DER encoding with application tag
>
>
>
> On 04/11/2021 13:58, Max Larsson wrote:
> > i2d_GSSAPI_CONTEXTTOKEN( negToken,&p );
> >
>
> You can tell i2d to encode using "application" tagging like this:
>
> ASN1_item_ex_i2d((const ASN1_VALUE **)&negToken, &p,
> ASN1_ITEM_rptr(GSSAPI_CONTEXTTOKEN), 0,
> ASN1_TFLG_APPLICATION);
>
> Matt
>
>
>
>
> > for( intlen = 0;len < bufferSize;len++ ) {
> >
> > if( ( len % 8) == 0)
> >
> > printf( " ");
> >
> > if( ( len % 16) == 0)
> >
> > printf( "\n\t\t");
> >
> > printf( " 0x%02x",(short)buffer[ len ] );
> >
> > }
> >
> > printf( "\n");
> >
> > . . .
> >
> > The code above output the following DER encoded structure (the
> > difference marled in bold):
> >
> > *0**x**3**0**0**x**81 0x80*0x060x060x2b0x060x010x050x050x02*0x04
> > 0x76*0xa00x74
> >
> > The google result, which I found seems to point into the direction to
> > use application tags to encode.
> >
> > But I haven’t found any example or how to how to achieve this with
> > openssl, can anyone give me sone hints?
> >
> > Best regards
> >
> > Max Larsson
> >
> > Mit freundlichen Grüßen
> > Best regards
> >
> > Dipl.-Inform. Max Larsson
> > Geschäftsleitung
> >
> > ------------------------------------------------------------------------
> >
> > phone: +49(0)6151/62908-75
> > fax:
> > email: max.larsson@xxxxxxxxxxxxxxxx
> <mailto:max.larsson@xxxxxxxxxxxxxxxx <mailto:max.larsson@xxxxxxxxxxxxxxxx>>
> > web: http://facilityboss.biz <http://facilityboss.biz>
> <http://facilityboss.biz <http://facilityboss.biz>>
> >
> >
> >
> > *facilityboss <http://facilityboss.biz <http://facilityboss.biz>>*
> > Bad Nauheimer Str. 4
> > 64289 Darmstadt
> > Germany
> >
> > Sitz der Gesellschaft: Darmstadt
> > Registergericht: Amtsgericht Darmstadt, HRB 86193
> > Geschäftsführer: Dipl.-Inform Max Lars Robert Larsson
> >
> > ------------------------------------------------------------------------
> >
> > Diese E-Mail enthält unter Umständen vertrauliche und/oder rechtlich
> > geschützte Informationen, die allein für den Adressaten bestimmt sind.
> > Wenn Sie nicht der zutreffende Adressat sind oder diese E-Mail
> > irrtümlich erhalten haben, ist jede Verwendung, Verbreitung, Kopie oder
> > Bezugnahme auf den Inhalt dieser E-Mail verboten. Bitte informieren Sie
> > uns über einen eventuellen Irrtum per Telefon, per Telefax oder E-Mail.
> >
> > This e-mail may contain confidential and/or privileged information. If
> > you are not the intended recipient, any disclosure, copying,
> > distribution or reference on the contents of this e-mail is strictly
> > prohibited. If you have received this e-mail in error please notify us
> > by e-mail, facsimile or phone call.
> >
>
