Re: Certificate = DER ?

Certificate extensions are always DER encoded, this is one of the few 
places where DER is required (from X.509:

   Extension ::= SEQUENCE {
     extnId EXTENSION.&id ({ExtensionSet}),
     critical BOOLEAN DEFAULT FALSE,
     extnValue OCTET STRING
     -- contains a DER encoding of a value of type &ExtnType
     -- for the extension object identified by extnId -- }

So they are not an issue.

It turns out that there are actually some CA certificates around that are 
not DER encoded. Implementations handle them anyway either because they do 
de/encode or they just memcpy() before validating the signature.

Another aspect is that I, as a sender of a signed document cannot really 
choose - I have been given a certificate by a CA and it was either DER 
encoded or not. Any change here would then require _senders_ to either 
re-encode before sending or ask for DER encoded certs from their CAs (or 
communication would fail).

So, my preference here would be no change at all. This is not an issue 
elsewhere, e.g. TLS, and I feel we should not introduce language which may 
cause compliant implementations to reject certificates that actually are 
valid X.509 certificates and which are usable in other contexts.

If this is unacceptable to the group then my next choice would be for a 
textual description similar to what you're suggesting below.

Best,
-- Magnus

On Fri, 7 Nov 2008, Konrad Lanz wrote:

> 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.
>
>
>
>

Received on Friday, 7 November 2008 12:39:00 UTC