ietf
[Top] [All Lists]

Re: Secdir review of draft-ietf-sidr-res-certs

2011-03-14 10:42:53
At 5:58 AM +0100 3/11/11, Martin Rex wrote:
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?

this is not about signing certs with extensions submitted by a Subject and which the CA does not understand.

A request "everything must be considered critical, even if not marked
as such" implies that every conceivable extension can only be a constraint.

I would prefer to say that the vast majority of extensions are excluded from this profile, to make it easier for RP software to process resource certs. The critical marking is not equivalent to what we have stated in this doc, although there are similarities. For example, there are a lot of standard extensions that 5280 requires RP software to recognize that are explicitly forbidden in the RPKI context.

With its original meaning, the "ciriticality" flag could be used to sort
extensions into "constraints" (critical) and "capabilities" (non-critical).

Note that not all extensions can be marked critical, so that using the critical flag would not be a solution in all cases anyway.

The problem with newly inventend constraints is that they require flag days.
capabilities do not suffer from this, and allow for a smoother migration.

This doc is a profile of 5280 and thus the imposition of constraints is to be expected. I do not know what you mean by the phrase "... capabilities do not suffer from this ..."

 > 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.

Interoperability is NOT enhanced by allowing certs with extensions that are extraneous to the focus of this architecture, and to the CP for this PKI. I suggest you read the architecture doc and the CP, both of which are available at the SIDR page to get a better sense of the context targeted by this profile.

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.


I disagree with our reading of this text, relative to this context.

Steve
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf