Arne Jørgensen writes: > david.goldberg6@verizon.net (David S. Goldberg) writes: > >> According to this bit from smime.el: >> >> ;; Certificates on LDAP servers _should_ be in DER format, >> ;; but there are some servers out there that distributes the >> ;; certificates in PEM format (with or without >> ;; header/footer) so we try to handle them anyway. >> (if (or (string= (substring (cadaar ldapresult) 0 27) >> "-----BEGIN CERTIFICATE-----") >> (condition-case nil >> (base64-decode-string (cadaar ldapresult)) >> (error nil))) >> (setq cert >> (smime-replace-in-string >> (cadaar ldapresult) >> (concat "\\(\n\\|\r\\|-----BEGIN CERTIFICATE-----\\|" >> "-----END CERTIFICATE-----\\)") >> "" t)) >> (setq cert (base64-encode-string (cadaar ldapresult) t))) >> >> then the result of smime-cert-by-ldap should be a base64 encoded block >> surrounded by the BEGIN and END CERTIFICATE lines. > > Correct. > >> Instead, I get the DER with extra CRs inserted every 64 bytes, >> surrounded by the BEGIN and END lines. The problem is that >> base64-decode-string does not throw an error, and from what I can >> see in base64.el, it's not designed to. > > Is base64-decode-string on XEmacs different from the one in Emacs? It is. The doc string for `base64-decode-string' on XEmacs in addition says "Characters out of the base64 alphabet are ignored" and that makes XEmacs a success on string that Emacs will fail on. I still think it's quite surprising that your DER encoded certificate is able to be base64 decoded in XEmacs though. Well, one solution is to not rely on `base64-decode-string' only for detecting if the certificate is in PEM format and instead base64 encode the decode string an compare the before and after strings. That's what the first patch does. Another solution is to look for a magic string ("MII") at the beginning of the certificate. I have not been able to find any authoritative documentation stating that a certificate must begin with "MII" (in base64 encoding), but googling for "x509 certificate MII" is not against it. The second patch implements this (and is definitely more elegant). (Just for the record: the case in which the problem is when we try to detect if the retrieved certificate is in PEM format but without the "-----BEGIN CERTIFICATE-----" header). Kind regards, -- Arne Jørgensen