Re: New other certs extension I-D

[Stephen Farrell <stephen.farrell@xxxxxxxxx>]

Hiya,

Stephen Kent wrote:
> 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. 

That's possibly true, but also possibly not. Given that we
don't specify those APIs here we can't really tell, and since
this would be a non-critical extension, only applications that
go looking (and hence understand what they want to do) would
find out about its existence.

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

Right.

> 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 would claim that (modulo -00 type text), there is the core of
such a problem and solution description in the draft. Totally
agree that it needs work though.

> I am not comfortable defining an extension for which we do
> not do this.

But I don't see how to tell the application exactly what to do
(since that's application specific) while at the same time
specifying a generic extension. (I think this is the nub of
what we're discussing.)

If there is a way, then I'm all for adding such text. I do agree
that there needs to be some text saying that if you do make use of
the linkage, then you need to be aware of various security
considerations (e.g. if an old private key were liable to be
leaked) and possible application gotchas (e.g. name changes).

If there isn't then we either kill the idea, or else have to
go with an application-specific extension, which is much less
interesting (I reckon), since I'd argue that the same problem
will arise in many applications. Basically, anyone who wants
to change things at cert renewal time but where there's
existing application state tied to the old cert.

I also reckon that this extension could be useful in load
balancing situations, though I guess one could well argue
that that's sufficiently different and can be handled via
wildcards (or handled well enough).

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

Yes, I think this is only interesting if there's a real chance that
it'll be used. Otherwise, we can just let it wither away... (I've
had a couple of "hmm, interesting..." type mails off-list, but no
more than that.)

Maybe the thing to do is to put this on the agenda next time to
see if it gets more than a few scattered yawns? If so, I guess
I can try do up a -01 before then reflecting this thread.

Cheers,
S.