RE: X.509, PKIX, and pathLenConstraint

[Hal Lockhart <hal.lockhart@xxxxxxxxxxxxx>]

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
> 
>