Re: New other certs extension I-D

[Stephen Farrell <stephen.farrell@xxxxxxxxx>]

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.

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.

> 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 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;-)

Stephen.

[1] http://tools.ietf.org/html/draft-ietf-pkix-rfc3280bis-10#page-38