Fwd: ACTION-56: Suggested text for best practices draft

resend to public list, please follow-up on public list.

Begin forwarded message:

> Resent-From: member-xmlsec@w3.org
> From: "ext Sean Mullan" <Sean.Mullan@Sun.COM>
> Date: September 17, 2008 10:26:13 AM EDT
> To: Scott Cantor <cantor.2@osu.edu>
> Cc: "'XMLSec WG Member List'" <member-xmlsec@w3.org>
> Subject: Re: ACTION-56: Suggested text for best practices draft
>
>
> Looks good. One comment. It is not clear what is meant by "heavily  
> profiling the transforms allowed". I think that best practice #2  
> might be more clear if it was moved a bit later in the document,  
> after discussing the malicious transforms. Then that sentence could  
> be reworded to say that the transforms should abide by the best  
> practices X-Y discussed earlier.
>
> Also, another comment not related to this action item. In the  
> introduction, there are two paragraphs which say the same thing. I  
> recommend removing the first paragraph.
>
> --Sean
>
> Scott Cantor wrote:
>> My suggested changes are to section 2.1, under Best Practice 2. I  
>> suggest
>> replacing those two paragraphs with this text:
>> ----
>> In step 1, if the verification key is not known beforehand and  
>> needs to be
>> fetched from KeyInfo, the implementation should be careful in its
>> processing. The KeyInfo can contain a RetrievalMethod child  
>> element, and
>> this could contain dangerous transforms, insecure external  
>> references and
>> infinite loops (See examples below).
>> RetrievalMethod has legitimate uses; for example when there are  
>> multiple
>> signatures in the same document, these signatures can use a  
>> RetrievalMethod
>> to avoid duplicate KeyInfo certificate entries. However,  
>> referencing a
>> certificate (or most other KeyInfo child elements) requires at  
>> least one
>> transform, because the reference URI can only refer to the KeyInfo  
>> element
>> itself (only it carries an Id attribute). An implementation that  
>> must handle
>> potentially hostile messages should constrain the RetrievalMethod  
>> elements
>> that it processes - e.g. permitting only a same-document URI  
>> reference, and
>> heavily profiling the transforms allowed.
>> Another potential security issue in step 1, is the handling of  
>> untrusted
>> public keys in KeyInfo. Just because an XML Signature validates
>> mathematically with a public key in the KeyInfo does not mean that  
>> the
>> signature should be trusted. The implementation must first validate  
>> that the
>> public key is trusted with respect to the creator of the signature.
>> For example, keys may be exchanged out of band, allowing the use of a
>> KeyValue or X509Certificate element directly. Alternatively,  
>> certificate and
>> path validation as described by RFC 5280 or some other  
>> specification can be
>> applied to information in an X509Data element to validate the key  
>> bound to a
>> certificate. This usually includes verifying information in the  
>> certificate,
>> such as  the expiration date, the purpose of the certificate,  
>> checking that
>> it is not revoked, etc.
>> Key Validation is typically more than a library implementation  
>> issue, and
>> often involves the incorporation of application specific  
>> information. While
>> there are no specific processing rules required by the XML Signature
>> specification, it is critical that applications include key  
>> validation
>> processing that is appropriate to their domain of use.
>> ---
>> Comments welcome.
>> -- Scott
>
>

Received on Friday, 19 September 2008 15:15:50 UTC