RE: Certificate = DER ?

> Another good rule of thumb is "be flexible in what you accept, be strict
> in what you send."

That doesn't justify not informing the recipient what was sent, but
regardless, for this approach to hold, what we're really saying is that such
profiling is inappropriate to do in most general specs layered on this one.
That means that implementations have to handle all the possible encodings to
be safe, and I haven't seen any sign that they do so.

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

Whatever's doing the validating still has to decode it, or I'm not
understanding this. That's the code I'm referring to.

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

I don't see how we're not in that situation now. The implementation I use
certainly is, and if, say, Java in fact only supports DER (I think somebody
indicated that might be true on the pkix list), then most/all of those
implementations are also.

This is the whole point. If using non-DER/BER is going to break things, then
it's pretty appropriate IMHO to say something about it and/or fix it.

-- Scott

Received on Tuesday, 11 November 2008 00:07:36 UTC