public_key and ssl question
Locked
 
|
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? 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. Andreas -- Dipl. Inform. Andreas Schultz email: [hidden email] 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: [hidden email] GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- |
signature.asc (205 bytes)
|
|
|
Hi,
On Mon, 2011-02-28 at 11:16 +0100, Ingela Andin wrote: > Hi! > > 2011/2/28 Andreas Schultz <[hidden email]>: > > 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) 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). 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: [hidden email] 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: [hidden email] GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- |
|
|
|
|
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 <[hidden email]>: > > Hi, > > > > On Mon, 2011-02-28 at 11:16 +0100, Ingela Andin wrote: > >> Hi! > >> > >> 2011/2/28 Andreas Schultz <[hidden email]>: > >> > 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: [hidden email] > > 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: [hidden email] > > 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: [hidden email] 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: [hidden email] GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- |
Loading...
| Powered by Nabble | Edit this page |