Stephen Kent wrote:
n to act as CAs , and we want to limit their liability.
One way to do this is to restrict the fields and extensions in
resource certs to make then not very useful for other applications.
A CA should never sign extensions that it doesn't understand.
Why has the RP to be bothered with this?
A request "everything must be considered critical, even if not marked
as such" implies that every conceivable extension can only be a constraint.
With its original meaning, the "ciriticality" flag could be used to sort
extensions into "constraints" (critical) and "capabilities" (non-critical).
The problem with newly inventend constraints is that they require flag days.
capabilities do not suffer from this, and allow for a smoother migration.
I also note that we want to impose these constraints on both CAs and
RPs, because we have lots of examples of CAs issuing "bad" certs,
accidentally. se want to use RP strictness to help "motivate" CAs to
do the right thing :-).
I don't think that this idea will work.
The consumers of the technology will want things to interoperate,
not to fail. And implementations will provide the necessary workarouds.
Besides, such an idea is in conflict with rfc-2119 section 6
6. Guidance in the use of these Imperatives
... they must not be used to try to impose a particular method
on implementors where the method is not required for interoperability.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf