[erlang-questions] public_key and ssl question
Andreas Schultz
aschultz@REDACTED
Mon Feb 28 17:20:42 CET 2011
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
--------------------------------------------------------------
-------------- 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/20c231cc/attachment.bin>
More information about the erlang-questions
mailing list