RE: Comments on best practices revision

> 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