- From: Scott Cantor <cantor.2@osu.edu>
- Date: Mon, 10 Nov 2008 11:40:36 -0500
- To: "'Magnus Nyström'" <magnus@rsa.com>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>
- Cc: "'Frederick Hirsch'" <frederick.hirsch@nokia.com>
> 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? -- Scott
Received on Monday, 10 November 2008 16:56:21 UTC