RE: Other certs extension

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

I'd say that PI and the OC extension serves 2 different scenario.

In the first scenario the RP system makes a full match of the certificate against validations policies, extract all naming information and determines the suitability of the certificate along with the matching of the identity to the accessed account.

In the second scenario only basic validation is done to make sure the cert is valid, but beyond that the RP system simply configure certificates of various kinds to represent users in their claimed capacity. In this scenario, name matching can be omitted or very limited.


In the first scenario PI works nicely, but so does a lot of other possible solutions. OC Extensions are not needed here.
But in scenario 2 where the RP system know their users by their certificates, then OC could be very useful.

One might think that all use of PKI should follow scenario 1, but in practice that is not the case. Quite some situations exist where applications are forced to accept existing certificates from legacy PKIs. As they don't always meet naming conventions of the app, learning/registering existing certificates (that do not contain an PI) is a realistic option. Recently RFC4680 and RFC4681 were developed to support such approach over TLS authentication.

In this capacity, OC extensions can be deployed reactively, while PI needs to be in place in existing certificates to work.

I have not yet decided if I want to support this draft, but I do recognize some benefits.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-
> pkix@xxxxxxxxxxxx] On Behalf Of Stephen Farrell
> Sent: den 8 april 2008 14:36
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: Other certs extension
>
>
>
> Hi Denis,
>
> (Sorry, I'd meant to include something on PI based on your earlier
> comments, but I forgot. It'll go into a -03 version if/when that
> gets done.)
>
> Denis Pinkas wrote:
> > Stepen,
> >
> > Since you said that "comments on the content are, of course, also
> much appreciated" ...
> >
> > The document should explain under which circumstances the Permanent
> Identifier extension (RFC 4043)
> > would fullfil the goal.
>
> My earlier response on this was (and still is):
>
> "
> - I don't think there's a technical need for a permanent identifier for
>    this purpose (as I understand it N-R is the main motivator for 4043)
> - I'm not sure that there are any real assigner authorities and
>    depending on a new name space might just make the problem at hand
>    worse
> - I've no idea whether 4043 is widely supported or not (mind you, the
>    proposed new extension isn't even implemented so that's less of a
>    concern)
>
> However, I do agree that were 4043 used, it could solve the problem
> at hand, so even if the new extension does go ahead, the spec should
> call that out."
>
> > The next question would then be: are the additional features provided
> by the proposal really important and necessary ?
> > If yes, this should be argumented.
>
> Is "important/necessary" a gating factor for an experimental RFC?
> In any case, I'd argue that the other certs extension does fulfill
> a particular need that crops up sometimes, and is worth specifying
> so that if it becomes important, then there's a clear way to do it.
>
> Stephen.
>
>
> >
> > Denis
> >
> >> We briefly discussed this draft [1] in Philadelphia where
> >> there was some support for taking it on as a WG item, as
> >> well as some concern. I've just posted an update to the
> >> draft that I hope might mitigate some of the concerns
> >> expressed.
> >>
> >> At the meeting, we agreed to discuss it on the list,
> >> i.e. to discuss whether or not to make it a PKIX WG item,
> >> and if so, whether it ought be experimental track or
> >> whatever.
> >>
> >> FWIW, I think it'd be a fine PKIX draft, and reckon
> >> experimental is right unless its adopted for some
> >> interesting application, which I don't see happening
> >> right now.
> >>
> >> So - should this be a PKIX draft? And if so, aiming
> >> at what kind of RFC?
> >>
> >> Cheers,
> >> Stephen.
> >>
> >> PS: Comments on the content are, of course, also much
> >> appreciated. (And its still only 7 pages, incl. cruft:-)
> >>
> >> [1]
> >> http://www.ietf.org/internet-drafts/draft-farrell-pkix-other-certs-
> 02.txt
> >
> >
> >
> >
> >
> >