[erlang-questions] public_key and ssl question

[Andreas Schultz]

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
--------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110228/4d6d95ba/attachment.bin>