[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell Inc. -- the leading provider of Net services software;DS eBusiness Solutions
TEL;PREF;FAX:01-801/861-2522
EMAIL;WORK;PREF;NGW:BJUENEMAN@xxxxxxxxxx
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah 84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah 84606
X-GWUSERID:BJUENEMAN
END:VCARD
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell, Inc.;DS eBusiness Solutions
TEL;PREF;FAX:01-801/861-2522
EMAIL;WORK;PREF;NGW:BJUENEMAN@xxxxxxxxxx
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah 84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah 84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD