Subject: RE: Confirm decision on identity handling.

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 21 Apr 2003 12:29:28 -0700

> >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.
> 
> I guess my main question would be, in what way does this 
> allow for a "more 
> stringent local security policy"?

If alice and amy are both users with valid certs, amy cannot connect to bob
using her own cert, but using alice's identity in the identity payload.

I personally don't think it is a big deal, but Steve Kent has said he thinks
it is, and I can see higher security organizations wanting it.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 22 Apr 2003 10:52:46 -0700

Just wanted to comment on this: I agree with Paul. Since we seem
unable to produce a coherent specification with respect to PKI-related
policies, when using certs the ID payload should not be present. If we
cannot agree on this, then the next best position is that the ID payload
must exactly match an identity contained in the cert. Anything else
leads to utter confusion and confounds interoperability.

I can't believe that after so many years, we are still paralyzed w.r.t.
this topic. What a farce. For the last several weeks, I've been trying
to get several ostensibly mature implementations to interoperate using
certs, and I've not had much success. How sad.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Apr 2003 16:17:11 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    Scott> Just wanted to comment on this: I agree with Paul. Since we seem
    Scott> unable to produce a coherent specification with respect to
    Scott> PKI-related 
    Scott> policies, when using certs the ID payload should not be
    Scott> present. If we 

  I would agree, that if you said:

  When using a PKIX-style certificate which is provided in a CERT payload
that the ID payload should not be set to anything other than ID_DER_ASN1_DN
or ID_DES_ASN1_GN.
  The provided GN or DN MUST be identical to that in the certificate.
 (It is redundant, I agree)
  The appropriate policy can clearly be looked up by GN/DN.
  So, I just don't get it. 

  It seems to me that if you are using a pre-exchanged certificate, or other
out-of-band certificate retrival system, that all ID payload types are
useful. 
  
    Scott> this topic. What a farce. For the last several weeks, I've been
    Scott> trying 
    Scott> to get several ostensibly mature implementations to interoperate
    Scott> using 
    Scott> certs, and I've not had much success. How sad.

  The last time I tried this, it all failed because implementations could
not produce PKCS10 certificate requests, nor could they load self-signed
certificates. So there was no way to get public keys to the other side.  
  How have things "improved"?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [