- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Wed, 24 Sep 2008 20:14:30 -0400
- To: XMLSec WG Public List <public-xmlsec@w3.org>
I have updated ISSUE-53 with proposed changes, to add a synopsis to each best practice, to remove a duplicate best practice, reword best practices and two add two best practices which appear to be implicit in the text. This should close ACTION-72. The proposed changes are below. regards, Frederick Frederick Hirsch Nokia ISSUE-53 http://www.w3.org/2008/xmlsec/track/issues/53 ACTION-72 http://www.w3.org/2008/xmlsec/track/actions/72 Proposed changes: Each best practice box has room for both the title and synopsis. The following are proposed synopses for each practice, written after the title for clarity. I have updated the draft to correctly number the items and use this numbering here. Note that Best Practices 2 and 6 appear to be duplicates. I suggest removing #6 - we already have an action to merge the sections. I also have some notes marked [Note...] for additional suggested changes. --- Best Practice 1: Mitigate denial of service attacks by executing potentially dangerous operations only after authenticating the signature Validate the ds:Reference elements for a signature only after establishing trust, for example by verifying the key and validating ds:SignedInfo first. --- Best Practice 2: Take care when processing RetrievalMethod. If ds:RetrievalMethod is necessary to obtain a verification key, determine in advance the risk allowed in processing ds:KeyInfo and limit ds:RetrievalMethod correspondingly, perhaps limiting processing of transforms within ds:RetrievalMethod. --- Best Practice 3: Establish trust in the verification/validation key Establish appropriate trust in a key, validating X.509 certificates, certificate chains and revocation status, for example. --- Best Practice 4: Consider avoiding XSLT Transforms Arbitrary XSLT processing might lead to denial of service or other risks, so either do not allow XSLT transforms, only enable them for trusted sources, or consider mitigation of the risks. --- Best Practice 5: Try to avoid or limit XPath transforms Complex XPath expressions (or those constructed together with content to produce expensive processing) might lead to a denial of service risk, so either do not allow XPath transforms or take steps to mitigate the risk of denial of service. --- Best Practice 6: Try to avoid or limit RetrievalMethod support with KeyInfo RetrievalMethod can cause security risks due to transforms, so consider limiting support for it. --- Best Practice 7: Control External References To reduce risks associated with ds:Reference URIs that access non local content, it is recommended to be mitigate risks associated with query parameters, unknown URI schemes, or attempts to access inappropriate content. [Note: is access to content more of an access control issue with that content, e.g. in the /etc/passwd example? Is web bug realistic threat, since in ds:Reference retrieval not all associated content will be retrieved by default, will it?] --- Best Practice 8: Limit Number of Transforms Allowed. Too many transforms in a processing chain for a ds:Reference can produce a denial of service effect, consider limiting the number of transforms allowed in a transformation chain. [Note: Change practice title to "Limit Number of ds:Reference transforms allowed." ] --- Best Practice 9: Check the reference URIs and transforms when verifying the signature [Note: I think this should be changed to : Enable verifier to automnate "see what is signed" functionality.] Enable the application to verify that what is signed is what was expected to be signed, by providing access to id and transform information. --- Best Practice 10: When checking a reference URI, don't just check the name of the element To mitigate attacks where the content that is present in the document is not what was actually signed due to various transformations, verifiers should check both the name and position of an element as part of signature verification. ---- Best Practice: Unnumbered, in section 2.3 [Note suggest adding in 2.3.2] BestPractice ??: Offer interfaces for application to learn what was signed. Returning pre-digested data and pre-C14N data may help an application determine what was signed correctly. --- Best Practice 11: Unless impractical, sign all parts of the document Signing all parts of a document helps prevent substitution and wrapping attacks. --- Best Practice 12: Long lived signatures should include a xsd:dateTime field to indicate the time of signing just as a handwritten signature does. The time of signing is an important consideration for use of long-lived signatures and should be included. --- Best Practice 13: Use a nonce in combination with signing time. A nonce enables detection of duplicate signed items. --- Best Practice 14: Do not rely on application logic since application may change. [Note: suggest changing to Best Practice 14: Do not rely on application logic to prevent replay attacks since applications may change. ] Supporting replay detection at the security processing layer removes a requirement for application designers to be concerned about this security issue and may prevent a risk if support for replay detection is removed from the application processing for various other reasons. --- Best Practice 15: Nonce and signing time must be signature protected A signature must include the nonce and signing time in the signature calculation for them to be effective, since otherwise an attacker could change them without detection. --- [Note: Add best practice for section 2.5: Best Practice ??: When creating an enveloping signature over XML without namespace information, take steps to avoid having that content inherit the XML Signature namespace. Avoid enveloped content from inheriting the XML Signature namespace by eiterh inserting an empty default namespace declaration or by defining a namespace prefix for the Signature Namespace usage. ---
Received on Thursday, 25 September 2008 00:15:19 UTC