RE: X.509, PKIX, and pathLenConstraint

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

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 <hal.lockhart@xxxxxxxxxxxxx> 03/07/01 09:32AM >>>
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       hal.lockhart@xxxxxxxxxxxxx 
F: 1-508-229-0338             www.entegrity.com 
=======================================================



> -----Original Message-----
> From: Bob Jueneman [mailto:bjueneman@xxxxxxxxxx] 
> Sent: Wednesday, March 07, 2001 10:58 AM
> To: kent@xxxxxxx 
> Cc: ietf-pkix@xxxxxxx; d.w.chadwick@xxxxxxxxxxxxx 
> Subject: Re: X.509, PKIX, and pathLenConstraint
> 
> 
> 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 <kent@xxxxxxx> 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
> 
>