Re: XML Signature Recommendations Reference to FIPS 186-2 Now Broken

On Monday 21 October 2002 02:53 pm, Elaine Barker wrote:
> This is one of the problems when including a url to a specific version of
> a document. Note that NIST will also be making a new version (FIPS 186-3)
> available - hopefully next year. I'm not sure what your solution is.
> Perhaps routinely include a warning that a newer version may supercede an
> older version?

Hi Elaine,

Publishing, maintaining, and referencing dependencies is a difficult, 
nuanced, but almost tractable issue! <smile/> There's two important 
principals involved in the problem.

Author - the person who provides/registers the token, name, or 
  identifiers (i.e. NIST). The Author has an obligation to publish
  and maintain the identifiers and the policy/expectation have how
  they will be versioned.
User - the person who references and creates a dependency on
  the identifier (i.e., W3C). They too will need to determine a 
  policy of how they want to use these identifiers.

The way the W3C tries to deal with these problems as an author is to *never* 
remove something from the Web and break those who depend on you. Instead we 
try to set their expectations of what's likely to change and provide an 
easy way to find those changes. In an actual W3C Technical Report (even if 
a Working Draft) it will state what the dated specific version that 
document is (and will persist) *as well* as the URI of the "latest 
version". For example,

  XML-Signature Syntax and Processing
  W3C Recommendation 12 February 2002
   This version:
          http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
          http://www.ietf.org/rfc/rfc3275.txt
   Latest version:
          http://www.w3.org/TR/xmldsig-core/
   Previous version:
          http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/
          http://www.ietf.org/rfc/rfc3075.txt [corresponds to
          CR-xmldsig-core-20001031]

It might also contain a link to an erratum. If you wrote something that 
implements the Proposed Recommendation ".../PR-xmldsig-core-20010820/", one 
can make that statement. However, if one is tracking the latest version 
".../xmldsig-core/" that's easy to state too. And if you implemented the 
final Recommendation ".../REC-xmldsig-core-20020212/" and track the erratum 
"http://www.w3.org/2001/10/xmldsig-errata", voila!

Furthermore, when it comes to W3C namespaces and identifiers, we have a 
policy about how one might maintain or break them  -- depending on your 
level of maturity [1]. From an interoperability point of view, the salient 
bits to keep in mind are: do changes, "(a) change the meaning or validity 
of existing documents written using the namespace, or (b) affect the 
operation of existing software written to process such documents." We're 
also trying to come to consensus of how to version erratum that might be of 
interest to you [2].

[1] http://www.w3.org/1999/10/nsuri
[2] http://www.w3.org/2002/05/31-errata

As a user of specifications, once the W3C converges on a stable/mature 
document it prefers to depend on specific/dated versions of things. *If* a 
dependency is not yet mature, then either (a) the dependent W3C 
specification isn't stable/mature yet either, or (b) the W3C specification 
needs to create an "in-line" "snapshot" of that specification. (In general, 
it's impossible to implement and interoperate against things in the future, 
though there are some cases of technologies that may be backwards/future 
compatible in ways that allows one to provide more flexible references 
(e.g., Unicode)
[2] http://lists.w3.org/Archives/Member/w3c-i18n-ig/1998Sep/0034.html ).

So, in the case of FIPS-186-2-change:
0. Was it not stable? Should we have not relied upon it in one of our 
standards?
1. Does the change break existing implementations. Is a compliant FIPS-186-2 
processor no longer compliant? Will a FIPS-186-2 application not work with 
a FIPS-186-2-change application? In which case you might want to make 
*that* clear. And if that's the case, the W3C might need to update it's XML 
Signature Recommendation.
2. Or does this not affect interoperability but contains security caveats?

In either case, you could maintain the existing specification and you 
could've provided a link to erratum/update document; or you could've 
maintained the original one and included a URI which will always provide 
the latest one.

3. And what will be different with FIPS-186-3? Is FIPS-186-2 abandoned? Are 
dependent specifications and applications now useless/worthless/insecure? 
Or just missing out on the "newer better" version -- isn't that ok?

Try to develop policies for references, dependencies, and revisions that is 
not the easiest thing in the world, but if you break references it makes it 
very difficult to figure out how to reference your specifications at all.

Received on Monday, 21 October 2002 16:25:24 UTC