<div dir="ltr">Hi,<div><br></div><div>tested the fix and it works. Thanks again for the great help!</div><div><br></div><div>BR,</div><div>Totti</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 4:26 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>
> Ok, but would the fallback from asn.1 to plain string then make sense?<br>
<br>
The idea is good, but...<br>
<br>
>         id = identification_create_from_encoding(ID_DER_ASN1_DN, data);<br>
<br>
This constructor does not do any parsing or verifying.  The (assumed)<br>
ASN.1 encoding is just copied.  The data will only get parsed as DN once<br>
the identity is compared or printed.  But I guess we could add an<br>
additional verification step to the from_data() constructor.  I pushed a<br>
possible fix to the dn-from-data branch [1].<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1]<br>
<a href="https://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/dn-from-data" rel="noreferrer" target="_blank">https://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/dn-from-data</a><br>
</blockquote></div>