Subject: Re: Extended Key Usage and path validation

From: [email-masked]
Date: Tue, 7 Nov 2000 22:23:05 +0000

First of all, I should probably introduce myself: I'm the lead PKI Architect for
the SITA/Equant Digital Certification Service, where I've been responsible for
most of the technical and policy implementation on issues surrounding our PKI
roll out.

Now to business:

Terry et al:

I'm not sure that I would concur with your willingness to assign a set of
standard values to the Certificate Policy field - (I'm not in favour of the
Netscape EKU Extension either, but that's another argument) - It's my reading of
the various standards that the Certificate Policy field should contain the OID
for the Certificate Policy under which that particular Certificate was issued -
and within that document, there would be the application limitation as specified
in section 1.4 of the Certificate Policy RFC.

I know the issue here is that we need some technical way to assure that a given
certificate isn't used for something that it was not intended for, but I'm not
sure that either the current method or your proposed fix is the way it should
go. Shouldn't this be something that an attribute certificate be used for, or am
I completely off the mark with that?

------
Patrick Patterson
PKI Architect, IPVAS CA
SITA/Equant JV.

---

From: [email-masked] (Terry Hayes)
Date: Tue, 07 Nov 2000 16:09:17 -0800

> in section 1.4 of the Certificate Policy RFC.

This seems to be the dominant interpretation of the Certificate Policies 
extension.  However, as I said before, this does not provide a standard 
OID value that can built into mass-market applications and used to check 
the intended use.   Using a different policy OID in each certificate 
hierarchy would required too much configuration.

Maybe what is needed is a very basic Certificate Policy document with a 
corresponding OID, that spells out the (small number) of requirements 
for issuing highly interoperable SSL or S/MIME certificates.  For 
example, the policy for an SSL certificate would limit (allow?) its use 
(in section 1.4) to SSL operations.  It might also state that the CA 
must ensure that correct values are provided for the  dnsName option of 
the SubjectAlternativeName so the the usual matching of identity with 
URL can be performed securely.

A CA can put this global OID into the CertificatePolicies along with 
OIDs for its own more specific or more constrained policies.  The 
extension can handle more than one OID.

> I completely off the mark with that?

I don't think attribute certs are the answer.  They aren't deployed 
widely yet, and aren't supported by some protocols.  In addition, isn't 
they subject to the same problem of determining whether the CA is 
allowed to set attributes enabling SSL or S/MIME operations?

Terry Hayes
Netscape Communications Corp.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 08 Nov 2000 08:27:49 +0100

Terry Hayes wrote:
> > It's my reading of
> the intended use.

Yes.

> for issuing highly interoperable SSL or S/MIME certificates.

No. This would be messing with policies.

Ciao, Michael.