ISSUE-53: Add short summary for each best practice

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.
---