Subject: Re: some thoughts re DPD and DPV

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2001 13:20:11 -0400

At 5:42 PM -0800 3/23/01, Paul Hoffman / IMC wrote:
>At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
>>We could make ALL requests refer to a policy configured at the 
>>server, rather than allowing for explicit transmission of these 
>>parameters. To make this as flexible as the current proposals, we 
>>would have to add a new protocol, to allow a client to register a 
>>policy with a server, so that the client could later refer to that 
>>policy. We probably want a facility to inquire about a registered 
>>policy as well.
>
>This sounds horrendously complex. To date, the IETF has had 
>near-zero success with defining policy protocols, with policy 
>working groups pretty much being unable to get closure. The method 
>promoted in SCVP (can give individual policy info in requests or can 
>use aggregated OIDs) seems much more sensible than forcing all 
>clients to know (or, worse, discover and push) the policies on the 
>server.

I think we are dealing with a very different situation here, relative 
to the general policy mess you allude to. The set of parameters for 
controlling path validation is better defined, although there are 
some points of disagreement. If we have a policy registration 
protocol, then the user can (subject to local controls) just register 
the few policies he regularly uses, or can retrieve (for review) the 
ones that his company imposes.

>The number of policies a typical client wants will probably be few 
>(most likely, just roots). Why make this so much more complicated 
>than needed?
>
  The motivation is to make the protocol exchange smaller, and the 
DPD/DPV protocols simpler. Don't you think reference to policies in 
this fashion achieves these goals?

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 3 Apr 2001 10:31:34 -0700

At 1:20 PM -0400 4/3/01, Stephen Kent wrote:
>I think we are dealing with a very different situation here, 
>relative to the general policy mess you allude to.

They all say that, often in their charters. :-)

>this fashion achieves these goals?

The first motivation seems spurious. Having policy negotiation does 
not achieve the second motivation, and in fact fights directly 
against it. SCVP already has references to policies: server-defined 
OIDs. It also allows a client and a server to agree to use a bit more 
bandwidth in passing the request in exchange for the client not 
needing to know the server's OIDs. Prohibiting this sensible action 
seems draconian, given that the clients and servers will aready agree 
to use it. (If a server doesn't agree, it will return an error for 
any requests other than OID-based ones.)

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2001 13:43:12 -0400

At 11:12 AM +0000 3/24/01, Liaquat Khan wrote:
>I'm not against the idea of having a (validation) policy registered 
>on the server, which the client refers to in its request message. 
>However, IMO would it not be more practical for the CA which issued 
>the certificate to be responsible for defining this policy and 
>registering it directly with its validation server?  This may remove 
>some of the complexity of each client having its own policy and a 
>protocol for registering this at the server.    The client would 
>only need to refer to the appropriate policy, which will be based on 
>the target certificate being checked.   Just some initial thoughts...
>
>Regards,
>Liaquat
>
  The validation policy is a matter for the client (RP) to decide 
upon, not the CA that issued the cert being validated.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2001 13:57:09 -0400

At 10:31 AM -0700 4/3/01, Paul Hoffman / IMC wrote:
>OIDs. It also allows a client and a server to agree to use a bit 
>more bandwidth in passing the request in exchange for the client not 
>seems draconian, given that the clients and servers will aready 
>agree to use it. (If a server doesn't agree, it will return an error 
>for any requests other than OID-based ones.)

Well, we're not negotiating policy here, in general. The client, 
absent serve-mandated overrides, is merely uploading policy to a 
server and getting back a policy reference. Or the client is asking 
the server to tell the client about server-configured (e.g., default) 
policies.  Your concerns dont' seem to align with what I have 
proposed.

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 3 Apr 2001 11:54:46 -0700

At 1:57 PM -0400 4/3/01, Stephen Kent wrote:
>Well, we're not negotiating policy here, in general.

OK, then I misunderstood your proposal.

>  The client, absent serve-mandated overrides, is merely uploading 
>policy to a server and getting back a policy reference.

That sounds OK, although still more complicated than allowing a 
client to say the same things directly in a request. It means two 
protocols instead of one, or one protocol that has two modes: "what's 
my policy reference?" and "is this cert valid using this policy 
reference?".

>  Or the client is asking the server to tell the client about 
>server-configured (e.g., default) policies.

This requires that a (supposedly simple) client can parse a huge bag 
of bags of policies looking for the one it likes best. I believe that 
this is unlikely to happen in the real world.

>   Your concerns dont' seem to align with what I have proposed.

My apologies. If what you meant was "there is a mode where a client 
says what policy it wants to use in future requests and can get a 
reference/OID for that", I think that's OK, but it doesn't simplify 
the protocol, it just splits the protocol into two parts. And it 
requires the client to remember the OID for the desired policy across 
requests, which is probably feasble but more limiting than allowing 
the client to just put the policy directly into the request.

Why not have an optional second protocol for policy-to-OID mapping, 
and allow either policies or OIDs in the request?

--Paul Hoffman, Director

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2001 16:02:30 -0400

Paul,

>protocols instead of one, or one protocol that has two modes: 
>"what's my policy reference?" and "is this cert valid using this 
>policy reference?".

Well, it depends on one's model of operation. If each application 
makes use of one or a few policies all the time, as several folks 
have suggested, then one can configure the OIDs for the appropriate 
policies in the app and have it use them in the request. In that 
case, one could get away without implementing the policy registration 
protocol protocol in the client.  If there are default policies 
mandated by an organization, then even this level of complexity might 
be avoided, if one has a means of signalling which application 
context is being invoked, although this begins to be a lot like the 
trivial case of the preceding mechanism.

>of bags of policies looking for the one it likes best. I believe 
>that this is unlikely to happen in the real world.

I see this as a separate application, a utility, outside of the 
client apps. Here too, one need not provide the facility if the 
client has no choice.

>requires the client to remember the OID for the desired policy 
>across requests, which is probably feasble but more limiting than 
>allowing the client to just put the policy directly into the request.

You are right that this is cheating, in a way, splitting the protocol 
into two parts. But, if many client would not need to invoke the 
policy management facilities, the clients would not have to implement 
the policy management protocol and thus could be simpler.

>and allow either policies or OIDs in the request?

Because allowing policy parameters to be specified in the protocol 
makes the protocol much more complicated, syntactically, and makes it 
harder to extend if one wants to add more controls. The split permits 
policy invocation and policy management to be separated, which may 
generally be appropriate.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2001 16:58:48 -0400

Folks,

I have submitted the corrected minutes for our last meeting, (cc'd to 
this list as well) and was about to submit the slides. But I have 
contributions only from Mike Myers and Denis Pinkas (and, of course, 
me).  All other speakers from the PKIX WG meetings at the 50th IETF 
should send me their slides now, so that I can forward them to the 
secretariat.

Thanks,

Steve