- From: Hirsch Frederick (Nokia-OCTO/Boston) <frederick.hirsch@nokia.com>
- Date: Fri, 19 Sep 2008 11:14:20 -0400
- To: XMLSec WG Public List <public-xmlsec@w3.org>
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