Re: Comments on best practices revision

The best practices document is not limited in scope to the xml signature 
spec only,  it is meant as an advice to people who are using xml 
signatures, and what problems they might face with it.

So although PKIX processing may not be a requirement for the spec, it is 
something that any implementation has to do to verify signatures. 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.

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.

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.

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.

Pratik


 

Scott Cantor wrote:
> Some comments on this revision from April 14th, 2008:
>
> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/
>
> In section 2.1, I think there are a few cleanups needed, as well as
> motivation for a change to the Signature spec.
>
> There's a statement about RetrievalMethod in which it's suggested that a use
> case for it is to avoid duplicate KeyInfo structures in a document with >1
> signature, but then a follow on statement that "the implementation may
> choose to allow only very constrained RetrievalMethods - e.g. those that do
> not have any transforms, and only one level of indirection using a local
> URI."
>
> This is contradictory because the existing schema is limiting and does not
> allow for RetrievalMethod to point to a certificate without in fact using a
> Transform to get inside the referenced KeyInfo element. This is because only
> KeyInfo carries an XML ID.
>
> Secondly, the following paragraph implies that using X509Certificate in
> KeyInfo implies PKIX processing of the certificate. There is no such
> requirement in the spec. It merely identifies a certificate. What the
> relying party does with it is not dictated by the spec. (As an aside, it's
> also referencing an old PKIX RFC, I think.)
>
> -- Scott
>
>
>
>

Received on Tuesday, 2 September 2008 22:09:42 UTC