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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf