Re: Proposed best practice changes to add synopsis and new practices.

I would also like to make a suggestion that the title/heading for each 
section should be the best practice, and not the example as it is currently.

--Sean

Frederick Hirsch wrote:
> 
> 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 15:12:06 UTC