<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-DE" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="DE" style="mso-fareast-language:EN-US">Hi Matt,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I found the initial definition is my best try to model the ANS1 structure as
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">probably described In the rfc2743<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Problem is that the bytes of the innerContextToken is completely depended upon<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">the value of the OID from the mech. As long I understand the bytes of the
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">innerContextToken must not be in DER encoded format.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">In my case it hust happens to be a DER encoded structure because the OID<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Value is the OID of the spnego mechanism.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">The encoded structure to realize is “just” the following if the OID (<mech>) is known<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">and the corresponding bytes for the innerContextToken (mechToken)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">0x0a <sizeof DER encoded mech plus number bytes of mechToknen> 0x06 0x06 <mech> <mechToken><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I hope that’s understandable. I thought it would be nice to use the functionality offered<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">By openssl to encode this data 8the next step would even be to decode such a structure),<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">but I think it isn’t a real DER encoded ANS1 structure, but somehow only relates to that.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Thus I think I have to “manually” encode the OID and innerContextToken.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Best regards<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Max <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openssl-users <openssl-users-bounces@openssl.org> on behalf of Matt Caswell <matt@openssl.org><br>
<b>Date: </b>Friday, 5. November 2021 at 11:41<br>
<b>To: </b>openssl-users@openssl.org <openssl-users@openssl.org><br>
<b>Subject: </b>Re: ASN1 <-> DER encoding with application tag<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
On 04/11/2021 17:39, Max Larsson wrote:<br>
> But now I’m wondering how I can “cascade” using this method to influence <br>
> the encoding<br>
> <br>
> to avoid the writing of the additional bytes after the OID gest encoded <br>
> and before<br>
> <br>
> the innerToken is encoded:<br>
> <br>
> *….. *0x05 0x05 0x02 *0x04 0x76* 0xa0 0x74….(here are a lot of bytes <br>
> omitted)<br>
<br>
I think this is an entirely different problem.<br>
<br>
0x04 corresponds to the universal tag for an OCTET STRING, and 0x76 is <br>
the length of that OCTET STRING.<br>
<br>
I assume what you want to see is 0xa0, which means a context specific <br>
constructed type with tag 0, followed by data of length 0x74.<br>
<br>
So, basically, it looks to me like your initial definition of the <br>
GSSAPI_CONTEXTTOKEN object is wrong:<br>
<br>
typedef struct ContextToken_st {<br>
ASN1_OBJECT *mech;<br>
ASN1_OCTET_STRING *innerContextToken;<br>
} GSSAPI_CONTEXTTOKEN;<br>
<br>
Since this clearly shows that the thing after the OID is an OCTET <br>
STRING. So you really need to understand what the actual type is for <br>
innerContextToken in order to correctly encode/decode it.<br>
<br>
Matt<br>
<br>
<br>
> <br>
> Best regards<br>
> <br>
> Max<br>
> <br>
> *From: *openssl-users <openssl-users-bounces@openssl.org> on behalf of <br>
> Matt Caswell <matt@openssl.org><br>
> *Date: *Thursday, 4. November 2021 at 17:14<br>
> *To: *openssl-users@openssl.org <openssl-users@openssl.org><br>
> *Subject: *Re: ASN1 <-> DER encoding with application tag<br>
> <br>
> <br>
> <br>
> On 04/11/2021 13:58, Max Larsson wrote:<br>
> > i2d_GSSAPI_CONTEXTTOKEN( negToken,&p );<br>
> ><br>
> <br>
> You can tell i2d to encode using "application" tagging like this:<br>
> <br>
> ASN1_item_ex_i2d((const ASN1_VALUE **)&negToken, &p,<br>
> ASN1_ITEM_rptr(GSSAPI_CONTEXTTOKEN), 0,<br>
> ASN1_TFLG_APPLICATION);<br>
> <br>
> Matt<br>
> <br>
> <br>
> <br>
> <br>
> > for( intlen = 0;len < bufferSize;len++ ) {<br>
> ><br>
> > if( ( len % 8) == 0)<br>
> ><br>
> > printf( " ");<br>
> ><br>
> > if( ( len % 16) == 0)<br>
> ><br>
> > printf( "\n\t\t");<br>
> ><br>
> > printf( " 0x%02x",(short)buffer[ len ] );<br>
> ><br>
> > }<br>
> ><br>
> > printf( "\n");<br>
> ><br>
> > . . .<br>
> ><br>
> > The code above output the following DER encoded structure (the<br>
> > difference marled in bold):<br>
> ><br>
> > *0**x**3**0**0**x**81 0x80*0x060x060x2b0x060x010x050x050x02*0x04<br>
> > 0x76*0xa00x74<br>
> ><br>
> > The google result, which I found seems to point into the direction to<br>
> > use application tags to encode.<br>
> ><br>
> > But I haven’t found any example or how to how to achieve this with<br>
> > openssl, can anyone give me sone hints?<br>
> ><br>
> > Best regards<br>
> ><br>
> > Max Larsson<br>
> ><br>
> > Mit freundlichen Grüßen<br>
> > Best regards<br>
> ><br>
> > Dipl.-Inform. Max Larsson<br>
> > Geschäftsleitung<br>
> ><br>
> > ------------------------------------------------------------------------<br>
> ><br>
> > phone: +49(0)6151/62908-75<br>
> > fax:<br>
> > email: max.larsson@facilityboss.biz <br>
> <mailto:max.larsson@facilityboss.biz <<a href="mailto:max.larsson@facilityboss.biz">mailto:max.larsson@facilityboss.biz</a>>><br>
> > web: <a href="http://facilityboss.biz">http://facilityboss.biz</a> <<a href="http://facilityboss.biz">http://facilityboss.biz</a>>
<br>
> <http://facilityboss.biz <<a href="http://facilityboss.biz">http://facilityboss.biz</a>>><br>
> ><br>
> ><br>
> ><br>
> > *facilityboss <http://facilityboss.biz <<a href="http://facilityboss.biz">http://facilityboss.biz</a>>>*<br>
> > Bad Nauheimer Str. 4<br>
> > 64289 Darmstadt<br>
> > Germany<br>
> ><br>
> > Sitz der Gesellschaft: Darmstadt<br>
> > Registergericht: Amtsgericht Darmstadt, HRB 86193<br>
> > Geschäftsführer: Dipl.-Inform Max Lars Robert Larsson<br>
> ><br>
> > ------------------------------------------------------------------------<br>
> ><br>
> > Diese E-Mail enthält unter Umständen vertrauliche und/oder rechtlich<br>
> > geschützte Informationen, die allein für den Adressaten bestimmt sind.<br>
> > Wenn Sie nicht der zutreffende Adressat sind oder diese E-Mail<br>
> > irrtümlich erhalten haben, ist jede Verwendung, Verbreitung, Kopie oder<br>
> > Bezugnahme auf den Inhalt dieser E-Mail verboten. Bitte informieren Sie<br>
> > uns über einen eventuellen Irrtum per Telefon, per Telefax oder E-Mail.<br>
> ><br>
> > This e-mail may contain confidential and/or privileged information. If<br>
> > you are not the intended recipient, any disclosure, copying,<br>
> > distribution or reference on the contents of this e-mail is strictly<br>
> > prohibited. If you have received this e-mail in error please notify us<br>
> > by e-mail, facsimile or phone call.<br>
> ><br>
> <o:p></o:p></p>
</div>
</div>
</body>
</html>