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 Scott Cantor" <cantor.2@osu.edu>
> Date: September 16, 2008 1:23:27 PM EDT
> To: "'XMLSec WG Member List'" <member-xmlsec@w3.org>
> Subject: ACTION-56: Suggested text for best practices draft
>
>
> 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:04 UTC