On Sat, Dec 25, 2010 at 7:37 PM, Mads Kiilerich <[email protected]> wrote:
> Marc-André Moreau wrote, On 12/12/2010 08:56 PM:
>
>> Hi FreeRDP Developers,
>>
>> I am currently working on network level authentication, and I was
>> considering the addition of the X.509 ASN.1 module in the asn1c-generated
>> code. In NLA, the last packet of the authentication sequence sent by the
>> client is bundled with the encrypted public key from the original
>> certificate sent by the server. However, the public key isn't really "just"
>> the public key, it's the public key encapsulated into some other ASN.1 data
>> structure. I looked at the patch submitted to rdesktop that uses libsamba,
>> and the code "manually" adds the required encoding to the public key. I
>> could hack something quickly to get a similar result, but I was thinking
>> that having the X.509 module would be helpful for easier certificate
>> parsing, such as in tls_verify. OpenSSL does parse the certificate for us,
>> but being dependent on OpenSSL makes it harder to try to switch to another
>> cryptographic library in the future.
>>
>> The ASN.1 module is readily available here:
>> http://www.itu.int/ITU-T/formal-language/itu-t/x/x509/2008/AuthenticationFramework.asn
>> X.509 has more than one module:
>> http://www.itu.int/ITU-T/recommendations/fl.aspx?lang=1&rec=509&module=&oid=<
>> http://www.itu.int/ITU-T/recommendations/fl.aspx?lang=1&rec=509&module=&oid=
>> >
>>
>> The X.509 specification can be found here:
>> http://www.itu.int/rec/T-REC-X.509-200508-I/en
>>
>> What do you think? Should we add the X.509 module, or should I manually do
>> the encoding?
>>
>>
> A late comment:
>
> We already use asn1c and should thus be able to build our own x509 parser
> without much trouble or security issues. We will however probably face some
> issues because neither MS nor CAs are fully x509 compliant, so we might have
> to add some tweaks.
>
Using a generated ASN.1 parser for X.509 may become problematic then if we
need to tweak it. I think I figured out a way of getting the actual X.509
structure for the public key using the OpenSSL API, otherwise we may just do
the encoding manually for the few additional bytes required. Unless there is
more need than that I think we'll be fine without the generated code for
this part.
>
> We already have a hard dependency to OpenSSL for TLS. It is my plan to make
> the crypto backend for it configurable as it is for non-tls. I have been
> holding back because I guess it is simpler to develop and stabilize the code
> with as few abstraction layers as possible. I will also wait for NLA.
>
Yes, this is understandable. We can wait for NLA to be done to port the code
to non-OpenSSL libraries. I have some unit tests for NLA code which will
help in porting NLA to other libraries.
>
> I suggest that you do whatever is simplest for you. Relying on OpenSSL
> would be fine.
>
> When we know what is required and have a stable reference implementation we
> can consider porting to other crypto/asn1 implementations.
>
> /Mads
>
>
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Freerdp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
