X.509 states that certificates use DER encoding:
calculation, the data that is to be signed is encoded using the ASN.1
distinguished encoding rules (DER)
Nominally, you could imagine that you encode the certificate data in XER, and that the DER encoding of the to-be-signed structure (
TBSCertificate) is performed dynamically for purposes of computing or verifying the signature, but nobody does that because:
It would be very hard to do, because although DER is suposedly deterministic, there are an awful lot of details which can get wrong (do you use
GeneralizedTime for the validity dates ? How do you handle milliseconds in the date representation ? For DN components, do you use
UTF8String ? Which kind of Unicode decomposition do you use for diacritics ? And so on). It would not be reliable.
XML encoding is awfully inefficient, both in space (it uses a lot of bytes, even when compared with Base64-encoded DER) and in CPU (that can be a tough issue with reduced platforms like smart cards).
Certificates are all about interoperability, and nobody supports XER-encoded certificates, so there is no added value in supporting them right now. There is no incentive either: what XML can bring (compared to DER) is automatic support of generic data transforms (XPath, XSLT... you name it), but that's the kind of thing that we do not want to do with certificates, because a certificate is signed and you cannot change a single bit of it without invalidating the signature.
If you want to play with signatures on XML data, lookup XML-DSig. It is noteworthy that when an XML-DSig object embeds a certificate (as an
X509Certificate element), it uses Base64 encoding of the binary certificate (i.e., DER-encoded certificate)(see section 4.4.4).
Summary: there is no such thing as a "standard" XER-encoded certificate and I predict that it will take some time before such a thing appears (and I pray all the gods I know that it will not happen before I retire).