RE: Confirm decision on identity handling.

[Gregory Lebovitz <Gregory@netscreen.com>]

I am pretty darn close to agreeing with this text. I agree completely with
the intent. I would just like to see it word-smithed to be a bit clearer, in
order to attain "predictable interoperability," as Steve would say. Let's
make it very explicit.

My proposal below attempts to say:
- the base interoperable way is DO NOT CHECK ID matches cert
- implementations MUST be able to handle IDs that do not match cert contents
- to allow for local security policy decisions, implementations MAY be
configured to match.
- Matching will only interoperate if both sides support the feature and have
matching turned on.

Proposed Text:
The Identification Payload, denoted ID in this memo, allows peers to
assert an identify to one another. The receiver will interpret the identity
payload as a unique identity string for policy lookup in its SPD.
Implementations MUST NOT mandate a check that the ID match anything in the
certificate presented, and therefore MUST be able to accept the case where
the identity presented does NOT match the certificate contents. 

To allow for more stringent local security policy, implementations MAY offer
a configuration option to check that the idenity presented in the identity
payload matches the equivalent identity type in the presented certificate.
In such a case, interoperability will only be achieved by two consenting
parties who both have such configuration options available on their
respective gateways and who both enable the option. 

Gregory.

> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Friday, April 11, 2003 12:26 PM
> To: Paul Hoffman / VPNC
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Confirm decision on identity handling.
> 
> 
> On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote:
> > 
> > We are better off with just the first sentence and a 
> revision of the 
> > one proposed here by Ted:
> > 
> >    The Identification Payload, denoted ID in this memo, 
> allows peers to
> >    assert an identify to one another. This identity may be 
> used for policy
> >    lookup, but does not necessarily have to match anything 
> in the CERT
> >    payload; both fields may be used by an implementation to perform
> >    access control decisions.
> 
> Paul's proposed revision seems clearer and reflects the discussion in
> San Francisco.  Does anybody have any problems with this text, or
> should we just go with it?
> 
> 							- Ted
>