Eric Gray wrote:
For instance, a lot of external (non-IETF) documents use the same terms,
even referring to RFC 2119, and yet explicitly create implied differences
in interpretation. For instance, I know of a few cases where - in spite
of an explicit reference to RFC 2119 - usage in context implicitly treats
"SHOULD" and "MAY" as equivalent (often because the fact that a requirement
is defined as something that SHOULD be done, makes it an optional
requirement - very much like "MAY").
We can take a parochial view and claim that this "outside usage" doesn't
affect us
We do not need to go that far.
Inside-IETF (ab)use of rfc2119 terminology is fairly common.
Canonical example of how bad it can get is PKIX (rfc5280).
The document targets three very distinct audiences:
- implementors of PKIX ("relying parties")
- application writers on top of PKIX implementations
- PKIX-conforming CAs.
but often fails to indicate to which audience individual requirements
apply.
Then it creates lots and lots of SHOULD and MUST requirements on
Certificates and Certificate Extensions (Section 4) and on
CRLs and CRL extensions (Section 5), and goes on and
waters down essentially all of those SHOULDs into factual MAYs
with the concept of a "minimum requirements implementation".
You may now think "well, that still leaves the MUST in place".
WRONG. All of the MUSTs in Sections 4 and 5 are _euthanized_
for "implementations of PKIX" with the following paragraph
in Section 6.1 of rfc5280 on the implementation of a certificate
path validation function (end of 3rd paragraph of section 6.1):
https://tools.ietf.org/html/rfc5280#section-6.1
While the certificate and CRL profiles specified in Sections 4 and 5
of this document specify values for certificate and CRL fields and
extensions that are considered to be appropriate for the Internet
PKI, the algorithm presented in this section is not limited to
accepting certificates and CRLs that conform to these profiles.
Therefore, the algorithm only includes checks to verify that the
certification path is valid according to X.509 and does not include
checks to verify that the certificates and CRLs conform to this
*> profile. While the algorithm could be extended to include checks for
*> conformance to the profiles in Sections 4 and 5, this profile
*> RECOMMENDS against including such checks.
So much for the IETF itself being clear on its use of rfc2119
in its own standards and RFC documents.
-Martin