Certificate = DER ?

FYI,

http://www.imc.org/ietf-pkix/mail-archive/threads.html#04947

my reading of the relevant specs is that the "to be signed" and "to be
verified" parts can be encoded in whatever encoding, but MUST be recoded
to DER for the actual signing or actual verifying of the certificate.

This is expensive however and I'm not sure whether there are compelling
arguments for anything, but using DER (and maybe XER).

So my preference for XMLDSig 1.1 would be to say the following ...

 ... certificates SHOULD be DER encoded ... and implementations MAY
issue an error if an encoding other than DER is encountered ...

So with the exemption of implementations that have really good reasons
not to DER encode certificates, we should assume they will be DER encoded.

I have been told that BER might have advantages for streaming processing
on signing, because of indefinite-length encoding, that does not require
to know the length of some data before it's written. It is unclear
however if this is of relevance given the small size of certificates.

Do certificate extensions play a role here, can they be large, they are
small usually aren't they?


BR
Konrad

P.S.: Our reference wrt. X509v3 seems to be outdated ...

http://www.w3.org/TR/xmldsig-core/#ref-X509v3
http://www.itu.int/rec/T-REC-X.509-199708-S/en

any thoughts about referencing the RFC instead?
http://tools.ietf.org/html/rfc5280

Overview of ITU X509 Documents:
http://www.itu.int/rec/T-REC-X.509/en

Some more things to think about in this context follow ...

I have not checked if they are all true, still true (written in 2000),
or really apply, but I think they might be valuable for the discussion ...

http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt :
> The encoding of the Certificate may follow the BER rather than the DER.  At
> least one implementation uses the indefinite-length encoding form for the
> SEQUENCE.
[...]
> DAP
> 
> X.500 directories using DAP return BER-encoded certificates since the
> DAP PDU's are BER encoded.  This leads to many certificates failing
> their signature check when they are re-encoded using the DER because
> they use incorrect or unexpected encodings.  This problem generally
> requires hacking the directory software to kludge the encoding,
> since many certificates can't survive the re-encoding process.
[...]
> Something identified as 'V3.0c' encodes the outer certificate using 
> the BER instead of the DER (which is unusual but legal), however it 
> also omits the final end-of-contents octets (which isn't).  Some of 
> the inner components are also encoded using the BER (which isn't 
> allowed).  This has been fixed in the 4.0 release.
[...]
> Some Verisign certificates mix DER and BER inside the signed portion
> of the certificate.  Only DER-encoded data is allowed in this part
> of the certificate.



-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
http://www.iaik.tugraz.at/content/about_iaik/people/lanz_konrad/
http://jce.iaik.tugraz.at

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm