- From: Scott Cantor <cantor.2@osu.edu>
- Date: Fri, 7 Nov 2008 14:39:20 -0500
- To: "'John Wray'" <John_Wray@notesdev.ibm.com>, "'Magnus Nyström <magnus'" <magnus@rsa.com>
- Cc: "'Konrad Lanz'" <Konrad.Lanz@iaik.tugraz.at>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>, <public-xmlsec-request@w3.org>
> 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. I'm not convinced that it's true, but I could be convinced. And again, the issue is not ASN.1 parsing, it's certificate parsing. People don't use general ASN.1 code to load certificates. They use code that uses ASN.1 code internally. (I do believe, upon looking closer, that OpenSSL claims to handle BER in its DER-oriented certificate functions, which would be consistent with this claim.) But what about non-BER/DER encodings? Regardless of the outcome of the discussion, it's my strong opinion that V2.0 of this schema needs to fix this. If we want to support multiple encodings, that's fine by me, but not signaling the encoding in the XML is pushing the burden for interop on other specs. -- Scott
Received on Friday, 7 November 2008 19:40:35 UTC