Secure References (Was: XML Signature Recommendations Reference to FIPS 186-2 Now Broken)

On Monday 21 October 2002 02:39 pm, John Boyer wrote:
> If some data is important to the interpretation of a document, a copy of
> it must be included within the document to prevent these volatile URIs
> from breaking signatures unexpectedly.

Yes, folks have bounced this idea around from time-to-time under the guise 
of "secure caching/packaging." At a given point in time, I have a trusted 
authority (e.g., myself, the domain name owner, or a trusted 3rd party) 
sign {dereferenced URI, timestamp, and resulting resource of a dereference 
I'm dependent on}. I then include a reference to that statement in my 
signature. So even if the maintainer of the document changes the object 
returned, it's clear what I was using. However, this requires me to also 
tweak my application behaviour to be able to do a correspondense between 
the URI in the stuff being signed, and it's dereferenced form in the 
cache/package.

> That being said, if there were a reference-based signature over the XML
> Signature Recommendation, then the least attractive alternative (#2, Let
> it be) would be the only alternative.

Well, that gives you a 404 and signature breakage.

>  I would think that such a
> signature would be less likely to break if the errata were changed than
> if the FIPS document were reinstated with a deprecation message.  So, the
> most desirable solution (#1, Reinstate with obsolete message) is the
> worst in terms of signatures-- fate, it seems, is not without a sense of
> irony.

This depends on the revision policy of the dependency author. As I said in 
my previous email, you can't implement things that don't exist. So FIPS 
should be reinstated *as it was*. If they need to  provide an update they 
could include a new resource with the diffs and new apps can also sign 
that. (If that is unlikely to change, you can sign a specific/dated 
version. If it's still likely to change but you trust that