W3C home > Mailing lists > Public > public-xmlsec@w3.org > November 2008

Re: Certificate = DER ?

From: John Wray <John_Wray@notesdev.ibm.com>
Date: Fri, 7 Nov 2008 08:38:26 -0500
Cc: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>,XMLSec WG Public List <public-xmlsec@w3.org>,public-xmlsec-request@w3.org
Message-ID: <OFBBFB36BE.9D7B6673-ON852574FA.00496819-852574FA.004AEB74@LocalDomain>
To: "Magnus Nyström <magnus" <magnus@rsa.com>
The point that certificates are usually obtained from a third party CA, 
and are not created by either party participating in the manipulation of 
the XML signature is, I think, crucial to the discussion.  If we were to 
mandate DER encoding, we would be saying that some CA certificates that 
happen to use BER cannot be used with XML Signature, unless the signer 
were to parse the certificate he got from his chosen CA and re-encode it 
in DER before attaching it to the signature.  And I don't think that 
anyone is proposing that...

I think that every ASN.1 parser that I've ever used (or written) will 
accept BER-encoded data transparently to the invoking application, so I 
don't think that encountering a BER-encoded certificate is a big deal in 
practice.  We shouldn't forget that DER is just a special-case of BER - 
one that uses the definite length encoding option, and has one or two 
other restrictions, so it's not as if BER is a different format to DER - 
it just allows the encoder more options.

John




Magnus Nyström <magnus@rsa.com> 
Sent by: public-xmlsec-request@w3.org
11/07/2008 07:39 AM

To
Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
cc
XMLSec WG Public List <public-xmlsec@w3.org>
Subject
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 13:39:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:55 GMT