RE: Certificate = DER ?

On Mon, 10 Nov 2008, Scott Cantor wrote:

>> As I wrote last week, I guess my concern with this would be that the 
>> sender may not know whether his certificate (chain) is DER, BER, (or 
>> anything else) encoded.
>
> Then neither does the verifier, right? I think the rule of thumb is to 
> make more work for the signer, not the verifier.

Another good rule of thumb is "be flexible in what you accept, be strict 
in what you send." The problem here is that the sender would not normally 
have a choice; they got their certificate chain from a third party. But 
the recipient can still be flexible.

In fact, some implementations handle non-BER/DER too - simply because they 
do memcpy() and then validate, without decoding...

It just seems to me we could end up in a strange situation if certificates 
that work perfectly well for signing email or to encrypt using S/MIME 
cannot be used for XML signatures or encryption because of strict, but 
compliant XML Sec implementations. That's why I'd prefer not to change 
things in this regard.

Best,
-- Magnus

>> And furthermore he may not be in a position to modify it, should it 
>> turn out that it is BER and XML Sec requires DER.
>
> This pushes the responsibility onto the receiever to handle any possible 
> encoding.
>
> I don't think it's a viable answer to force everybody else to profile this,
> because in the web services space, there are too many different specs that
> will come into play, some of which aren't really open right now for changes
> like this.
>
> If the concern here is that some certificates are being issued as BER, then
> my suggestion (based on my impression of what these libraries seem to
> handle) is that DER and BER be combined and that at least we can provide
> guidance that anything *else* would be carried in a different element. I
> don't see much evidence that existing implementations would handle
> non-BER/DER encodings. Does anybody have evidence to that effect?

Received on Monday, 10 November 2008 22:00:26 UTC