- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Fri, 7 Nov 2008 14:59:02 -0500
- To: ext Scott Cantor <cantor.2@osu.edu>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "'John Wray'" <John_Wray@notesdev.ibm.com>, ""'Magnus Nyström <magnus'"" <magnus@rsa.com>, "'Konrad Lanz'" <Konrad.Lanz@iaik.tugraz.at>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>, <public-xmlsec-request@w3.org>
Would now be a good time for a concrete proposal for language or should we wait for more discussion first? regards, Frederick Frederick Hirsch Nokia On Nov 7, 2008, at 2:39 PM, ext Scott Cantor wrote: > >> 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 20:00:55 UTC