[erlang-questions] public_key and ssl question
Ingela Andin
ingela@REDACTED
Tue Mar 1 09:48:51 CET 2011
Hi!
No oids are not translated into atoms, we use the asn1 generated macros
instead in the code. Ex:
#'AttributeTypeAndValue'{type=?'id-emailAddress',
value=Mail}
It would be a bad idea to translate oids to atoms as there is no
gurantee that they will be uinque.
Regards Ingela Erlang OTP team - Ericsson AB
2011/2/28 Andreas Schultz <aschultz@REDACTED>:
> Hi Ingla,
>
> I think i understand the decoding a bit better now. I guess i was mostly
> confused by getting something like:
>
> #'AttributeTypeAndValue'{type = {2,5,4,3},
> value = {teletexString,"www.example.com"}}
>
> when is was somehow expecting something more like:
>
> #'AttributeTypeAndValue'{type = 'X520OrganizationName',
> value = {teletexString,"www.example.com"}},
>
> Or in other words, i was expecting the numeric ASN.1 identifiers to be
> decoded into atom. But it seems that is not the way the ASN.1 stuff in
> Erlang works.
>
> So, this leaves on the missing commonName validation if the ssl app
> works as client.
>
> Andreas
>
> On Mon, 2011-02-28 at 12:21 +0100, Ingela Andin wrote:
>> 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
>> > --------------------------------------------------------------
>> >
>
> --
> 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
> --------------------------------------------------------------
>
More information about the erlang-questions
mailing list