[erlang-questions] public_key and ssl question

[Ingela Andin]

Hi again,

I can not really answer this from the top of my head ( at home taking
care of sick kids today),
I will check the specs when I get back, if we are indeed missing
something which ofcourse
is possible, we would be interested in your patch suggestion.

Regards Ingela Erlang/OTP team - Ericsson AB


2011/2/28 Andreas Schultz <aschultz@REDACTED>:
> Hi,
>
> On Mon, 2011-02-28 at 11:16 +0100, Ingela Andin wrote:
>> Hi!
>>
>> 2011/2/28 Andreas Schultz <aschultz@REDACTED>:
>> > Hi,
>> >
>> > I have been playing with the public_key, crypto and ssl apps a bit.
>> >
>> > What struck me as odd is that X.509 certificates are only partially
>> > decoded. public_key:pkix_decode_cert/2 will return many of the fields
>> > undecoded. This leads to my first question:
>> >
>> >  Is the partial decoding on purpose (maybe to simplify things or safe
>> >  memory/cpu cycle) or just not completed yet?
>>
>> There are two ways of decoding a cert, plain and otp. Plain uses the
>> standard ASN1-spec and only decodes the top level (Default Asn1
>> application behaviour).  You may use public_key:der_decode/2 to look
>> at parts.  If you use otp-decoding much more will be decoded, but
>> there still might be non standard extensions that will not be decoded.
>> (Then you may need your own ASN1-spec)
>
> Yeah, i have seen the difference between otp and plain decoding and i
> was actually referring to the otp decoding. Many to the standard PKCS1
> parts of a certificate are not decoded. For example most (if not all)
> parts of a typical subject and decode only as printableString. The
> subject from a valid Thawte certificate will look like this:
>
>            subject =
>                {rdnSequence,
>                    [[#'AttributeTypeAndValue'{
>                          type = {2,5,4,10},
>                          value = {teletexString,"www.example.com"}}],
>                     [#'AttributeTypeAndValue'{
>                          type = {2,5,4,11},
>                          value =
>                              {printableString,
>                                  "Go to
> https://www.thawte.com/repository/index.html"}}],
>                     [#'AttributeTypeAndValue'{
>                          type = {2,5,4,11},
>                          value = {printableString,"Thawte SSL123
> certificate"}}],
>                     [#'AttributeTypeAndValue'{
>                          type = {2,5,4,11},
>                          value = {printableString,"Domain
> Validated"}}],
>                     [#'AttributeTypeAndValue'{
>                          type = {2,5,4,3},
>                          value = {teletexString,"www.example.com"}}]]},
>
> Most the subject parts will never be used. But at least the common name
> would be interesting. Yet, i believe that if the subject had an
> alternateEmail attribute, that would be decoded....
>
> Anyway, the real question is, would it be worthwhile to add the missing
> bits to the OTP ASN.1 module and submit a patch?
>
>> > And second:
>> >
>> >  Since the common name (CN) of a certificate is not decoded, how will
>> >  a SSL client verify the identity of a SSL server?
>> >
>> > Looking through the SSL code i can see that the certificate chain itself
>> > will be verified (the verify_peer result), but the common name is not
>> > check as far as i can tell.
>> >
>>
>> Ssl uses the otp-decoding and the public_key application to do a
>> path-validation according to RFC-5280. ( We have not yet  finished the
>> implementation of CRL handling, but except for those all mandantory
>> parts should be in place).
>
> The path-validation yes, but the most basic validation if the
> certificate even belongs to the host we think we are talking to seems to
> be missing. Or am i missing something?
>
> Regards
> Andreas
>
>>
>> Regards Ingela Erlang/OTP team - Ericsson AB
>
> --
> Dipl. Inform.
> Andreas Schultz
>
> email: as@REDACTED
> phone: +49-391-819099-224
> mobil: +49-170-2226073
>
> ------------------ managed broadband access ------------------
>
> Travelping GmbH               phone:           +49-391-8190990
> Roentgenstr. 13               fax:           +49-391-819099299
> D-39108 Magdeburg             email:       info@REDACTED
> GERMANY                       web:   http://www.travelping.com
>
> Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
> --------------------------------------------------------------
>