Re: New other certs extension I-D

[Stephen Kent <kent@xxxxxxx>]

Title: Re: New other certs extension I-D

At 12:13 PM +0000 1/7/08, Stephen Farrell wrote:

> Hi Steve,
>
> Stephen Kent wrote:
>
> > Maybe my comments were not precise enough.
> >
> > My concern is that there is not sufficient description of what an
> RP
> > MUST/SHOULD do with the info provided via this proposed
> extension.
>
> I'm still not getting the concern. Since this extension is not part
> of
> path validation, the RP actions are essentially application specific,
> so
> there're no MUSTs or SHOULDs required for the RP here, other than
> to
> re-iterate that an RP MUST only use certs that passed 3280(bis)
> validation, which I took as implicit but might be worth calling
> out.
>
> That's more or less what we do with e.g.
> SubjectDirectoryAttributes
> [1] which is also not an input to path validation.

Yes, but SDA is marginal and we used to disparage its use :-). (In RFC 2459 we said "The subject directory attributes extension is not recommended as an essential part of this profile, but it may be used in local  environments." and I'm sorry we deleted that warning in 3280.)

Here I think the danger is greater, because we're including pointers to cert but not being explicit about what we expect RPs to do with them.  It's not enough to say that the certs have to pass the validation policy. If an app believes that the a cert pointed to by this extension is intended to replace one it already associates with a given entity, then this might create problems at the not-well-defined interface between the PKI modules and applications. 

> However, if there're any security
> concerns then there could be some
> MUST NOTs, for example, it might make sense to say that an RP MUST
> NOT assume that the other certs all have the same key usage etc.,
> but that's sort-of motherhood and apple pie stuff, and I guess
> isn't what you meant.

no, it's not.

> > Giving example of what an RP MIGHT
> do is not enough. We need to be
> > precise. In so doing, we should be able to figure out what
> constraints
> > are imposed on CAs who make use of the extension, and what
> security
> > implications arise.
>
> > If we just create syntax for transporting these pointers, and
> some
> > suggestions about what an RP might do with the info, we create
> a
> > situation where a CA doesn't know what utility they provide
> (because it
> > cannot count on how an RP will use the info) and users cannot
> know what
> > their local PKI engines are doing with the info, which may
> undermine
> > local PKI management efforts.
>
> Can you give an example? (I've thought about it a little bit, but
> haven't come up with a good example of a problem that wouldn't
> just
> be an implementation bug in an RP.)

As noted above, we don't prescribe the interface between PKI processing and app use of data that comes from that processing. If this extension is intended to solve a specific problem in this realm, then we need to be precise in describing what the problem is, and how this extension solves it. I am not comfortable defining an extension for which we do not do this.

> As to a CA not knowing the utility, I
> disagree. Were this extension
> to see real life use, then CAs would surely only include it when
> they do understand the effects. (I can even imagine them
> charging
> a premium;-)

Then let's have CAs contribute to the discussion and say what they would do with the extension, and how they want RPs to process it.

Steve