Re: Certificate = DER ?

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

I'm not aware of any.

I think I'm ok with this but I don't think we should be any more 
specific, such as stating the DER encoded certificate MUST be 100% 
compliant with PKIX/RFC 5280. (I don't think this is what you are 
suggesting, but I think it is worth mentioning just in case). As has 
been pointed out by some people on the PKIX list, there are real "buggy" 
X.509 certificates out there, that, even though they are (or appear to 
be) DER encoded, aren't always 100% compliant with the X.509 ASN.1 
structure. The reality is that most certificate parsing implementations 
must be flexible enough to work around these "encoding bugs"

--Sean

Received on Monday, 10 November 2008 20:27:20 UTC