Subject: RE: X.509, PKIX, and pathLenConstraint

From: Sharon Boeyen <[email-masked]>
Date: Tue, 6 Mar 2001 15:35:48 -0500

I can't help thinking this is getting much more complicated than it needs to
or that the discussion needs to be split into two threads, one on path
length constraints and the other on CRL-issuers.

First, there IS a definition of what a CA is (X.509 clause 3.3.16. It is "An
authority trusted by one or more users to create and assign public-key
certificates. Optionally the certification authority may create the users'
keys."

A CA also has responsibility for certificate revocation , but can delegate
that to another authority, or delegate the task of making revocation status
information available (e.g. an OCSP responder)as per the 509 quotes David C
passed along. That is the reason that the X.509 text now uses the term
CRL-issuer pretty much throughout when it talks about an entity that issues
a CRL. 

In the path validation process, from a path length constraints standpoint it
should make no difference what the final cert is used for, nor does it
matter what type of data was signed with the certified key. The constraint
on the path is still the same. The final cert and the one containing the
constraint do not count against the constraint. Is that point agreed? I want
to separate these so I'll know if the DR is ok to progress.

On the other issue of who issues CRLs, if the CA that issued the certificate
doesn't do it, then it is the responsibility of that CA to indicate the
responsible authority (as per the 509 quotes from David C), however an
entity that does not issue certificates is not a CA. Having said that, I'm
not convinced that at least for path validation reasons we need yet another
term.

Sharon

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 07 Mar 2001 08:57:45 -0700

Steve, this may be "merely" a question of semantics, but let
me outline a user-driven scenario that may be of interest here.

Suppose that I am a hospital administrator operating a network
that allows doctors, nurses, etc., to access various resources
using their X.509 certificates.  And let's assume for now that
these certificates are issued by one of the public CAs, e.g.,
VeriSign, and not by say the state medical association.

As the hospital administrator, I am probably a lot more concerned
with whether the doctor in question currently has hospital privileges
than I am in whether that doctor's signature is legally binding,
and I am certainly in a much better position to be authoritative 
about that issue than VeriSign is -- the fact that a doctor had 
his medical license revoked would not be cause for VeriSign to 
revoke his certificate.

I could, of course, set up a local database, and merely look up that 
user's status, but although that works for access control, it doesn't 
work nearly as well for say S/MIME.

So what I might like to do is to intercept all outgoing requests for 
CRLs or OCSP, and send to my own local CRL or OCSP responder.
I would manage that by periodically checking the real CRL list,
but in addition I can revoke a certificate locally as I see fit.
All that I have to do is to ensure that my certificate is included in
the relying party software as a trusted root, or at least is chained to
a trusted root.

BTW, since the relationship is completely independent of the
CA that issued the certificates, there is nothing in the certificate
that would point to my CRL responder, not even a CRLDistributionPoint.

Now, am I a CA, or not? After all, I will never be issuing certificates, 
only CRLs.

My inclination would be to say that yes, I am, but what say you?
Does it really matter one way or the other?

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

>>> Stephen Kent <[email-masked]> 03/06/01 04:16PM >>>
David,

To me, the text you cite (7.3) lends further credence to the notion 
that a CA is the entity that signs CRLs. Only the CA that issued a 
cert could sign a CRL revoking that cert, until v3 of X.509, where 
the introduction of indirect CRLs and CRL DPs opened up new 
possibilities. The fundamental question is whether these features 
create a new class of entity that can sign CRLs but not be marked (in 
its certificate) as a CA, or whether these facilities merely allow 
one CA to delegate CRL signing to another CA, perhaps operated under 
the same administrative jurisdiction.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Mar 2001 11:32:55 -0500

Bob,

>Does it really matter one way or the other?

I think your example simply fails to work, i.e., using the validation 
processing algorithm there is no way to cause clients to rely on your 
locally generated CRLs vs. the CRLs identified by the CAs. This is a 
scenario that motivates the use of DPV.

Steve

---

From: Hal Lockhart <[email-masked]>
Date: Wed, 7 Mar 2001 11:32:54 -0500

I thought that this was the type of situation that Attribute Certificates
were designed to handle. Aren't you confusing Authentication with
Authorization?

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [email-masked]
F: 1-508-229-0338             www.entegrity.com
=======================================================

> -----Original Message-----
> From: Bob Jueneman [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 10:58 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: X.509, PKIX, and pathLenConstraint
> 
>

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 08 Mar 2001 11:49:47 -0700

Hal,

I think it is mostly an issue of timing.  I can imagine all sorts of wills/cans/should scenarios, including setting up the state medical association as an authoritative CA, or getting VeriSign, etc. to include such certifications in their certificates and keep on top of the issue, and/or using attributes certificates, XML, or whatever.  But it takes a surprisingly  long time to roll out all of these fancy options, even once a critical mass of vendors start offering them.  

The approach I suggested might be useful in the interim, I feel.

Bob

>>> Hal Lockhart <[email-masked]> 03/07/01 09:32AM >>>

Hal