<div dir="ltr">Ok, but would the fallback from asn.1 to plain string then make sense? Something like (just pseudo):<div><br></div><div>identification_t * identification_create_from_data(chunk_t data)<br>{<br>    char buf[data.len + 1];<br><br>    identification_t* id = NULL;<br>       <br>    if (is_asn1(data))<br>    {<br>        id = identification_create_from_encoding(ID_DER_ASN1_DN, data);<br>        if (id->is_empty())<br>        {<br>             id->destroy(id);<br>             id = NULL;<br>        }<br>    }<br><br>    if (id == NULL)<br>    {<br>        /* use string constructor */<br>        snprintf(buf, sizeof(buf), "%.*s", (int)data.len, data.ptr);<br>        id = identification_create_from_string(buf);<br>    }<br>}</div><div><br></div><div>BR,</div><div>Totti<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 3:15 PM Tobias Brunner <<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Totti,<br>
<br>
> There is also ID Type in the identification payload.<br>
<br>
Unfortunately, EAP-Identities are not transmitted in such payloads.<br>
They are basically arbitrary binary blobs that strongSwan tries to parse<br>
based on some heuristics to actually match them against other identities<br>
(e.g. in certificates or the configuration, which all have a type<br>
associated that must match).<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div>