- From: Scott Cantor <cantor.2@osu.edu>
- Date: Tue, 2 Sep 2008 18:49:55 -0400
- To: "'Pratik Datta'" <pratik.datta@oracle.com>
- Cc: <public-xmlsec@w3.org>
> So although PKIX processing may not be a requirement for the spec, it is > something that any implementation has to do to verify signatures. I'd claim it's orthogonal, and it's usually a mistake to even attempt it *inside* a signature library. Whenever this is attempted, it's done uniformly badly. It should be left to other libraries. But that aside, it's simply not a requirement of the specification. The use of the X509Certificate data structure does not imply PKIX processing by the relying party. Stating or implying that it does (such as in this document) is a concern for me, because when I fight the use of PKIX in contexts where it does not belong, I have to constantly fight against interpretations of the existing specification that aren't correct. I'm not asking for help with that, I'm just asking not to be undermined by official WG output. I'm just asking for this to be rephrased more generically. > In my experience users who are new to XML Signatures get so caught up with the > details of xml signature spec, that they forget basic things like > certificate chain validation, so we need to remind them of it. I'm not arguing against that. I'm only arguing against being overly specific. (If I wanted to get pedantic about it, I would probably argue that using PKIX as a baseline is a good way to ensure it won't be done correctly, so it isn't where I would start with my advice.) > We had a similar issue of whether Cross Site Scripting attacks are in > scope for the Best Practices document, and we decided to keep it, > because it does affect XML signature implementations even though it is > nothing to do with the spec. That's fine, as long as its correctly identified as being outside the scope, or one among many approaches. > My understanding was that a RetrievalMethod needs to point to a child of > KeyInfo, i.e. to a KeyName, KeyValue, X509Data etc, because > RetrievalMethod has a Type attribute, which has to be one of X509Data, > DSAKeyValue, RSAKeyValue etc. Yes. When I originally read/implemented, I just assumed that, because only KeyInfo carried an ID, that in fact it was meant to point there. I have since learned otherwise. > But I understand your comment that the child elements do not allow IDs, > so it is not possible for a RetrievalMethod to point to child element of > KeyInfo. I think this needs more explanation - do we really a transform > in the retrieval method? What is the purpose of the Type attribute in > that case? Transforms in the RetrievalMethod are dangerous, we can't > recommend it. I agree, and I believe the schema needs to be changed. Alternatively, we could change the processing rules so that RetrievalMethod points to the parent element, but that probably breaks existing implementations anyway. I don't have a strong position on how to fix it at this point, it depends on the requirements we have for compatibility. I'm just identifying a problem with the existing advice. -- Scott
Received on Tuesday, 2 September 2008 22:50:50 UTC