Re: operational protocols
David Boyce <D.Boyce@isode.com> Mon, 07 April 1997 11:03 UTC
Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id EAA11566; Mon, 7 Apr 1997 04:03:20 -0700
Received: from woozle.isode.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id EAA11563; Mon, 7 Apr 1997 04:03:16 -0700
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com with SMTP (local); Mon, 7 Apr 1997 12:01:36 +0100
X-Mailer: exmh version 1.6.7 5/3/96
To: Stef Hoeben <Stefan.Hoeben@esat.kuleuven.ac.be>
cc: "Housley, Russ" <housley@spyrus.com>, ietf-pkix@tandem.com
Subject: Re: operational protocols
In-reply-to: Your message of "Mon, 07 Apr 1997 10:21:17 +0200." <Pine.ULT.3.95.970407095804.241A-100000@dante>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 07 Apr 1997 12:01:34 +0100
Message-ID: <3208.860410894@isode.com>
From: David Boyce <D.Boyce@isode.com>
Stef Hoeben writes: > >Russ: > >> I do not see how the CIL can be usefully used as a certificate >> extension. >> Please provide a more detailed explaination. > >Normally, a CA gives its certs and CRL to a Directory, which is >normally no _Trusted_ Third Party. Because the certs and CRL are >signed by the CA, the Directory can't mess these up. But the >Directory can answer on a request for a certificate: 'I don't have >it, the CA never issued it' [ My comments are being made from an X.500 point of view. In order to understand where Stef is coming from, it is a good idea to read Silvio Micali's paper he referred to previously. An understated presumption is that the user has some kind of legal contract with the Directory to be supplied with certificate information, which places a duty on the Directory to justify its responses. This seems dubious in the general case, although perhaps individual exceptions may be desirable. DJB] There may be any number of reasons (insufficient access being just one of them) why a Directory might not return a certificate, and it doesn't even have to tell you why. It doesn't have to be interpreted as a denial of service attack. >So if a Directory really doesn't have a certificate, it must prove >it to the user. I don't see why, without some special contractual requirement. This is an administrative issue. > This can be done by the CIL: a list with the serial >numbers (or other ID's) of all certificates the CA has given to the >Directory, and this list must be signed by the CA. >So if a user requests a cert which the Directory didn't have, the >Directory _must_ give the CIL which the user can check so verify >the requested cert isn't in the CIL. This cannot be enforced. Attribute substitution of this kind is not part of DAP or LDAP (the concept of attribute type hierarchy is an exception, although unlikely to apply in this case). The user, on failing to obtain a cert, might then request a CIL, perhaps from some other entry; but the Directory may still decline to supply one. >=> The only problem looks: how to tell the users they will get a > CIL instead of a 'I don't have that cert' if they ask for a > non-existing cert. > I don't think you can put it in a private extension of the > certficate, because that's exactly what a nasty Directory > won't give... Depends on what level you are viewing the 'user' from; at the DAP or LDAP level, the user can request either or both of the cert and CIL, and the Directory may or may not decide to supply them; but if supplied they are separate attributes. The application may of course translate this into more 'user-friendly' information subsequently. >> How is LDAP different than any other access to a certificate and CRL >> repository? I do not see what makes the CIL important in the LDAP >> environment more than any other environment (like FTP or full DAP). > >Oops, mistake: LDAP isn't different. It's the same for the other >protocols. Sorry for the confusion. Indeed it is the same. >> Also, does the use of distributed, replicated Directories help solve your >> concern? If not, how about the use of more than one distriution mechanism, >> say FTP and LDAP. > >You mean some independent directories with the same info? Sure, that would >help, but isn't that expensive and impractical in most cases? I think he means multiple Directory System Agents holding copies of the same information, which is part of the standard X.500 model. (This would mean that the same certificate in the same entry could be held on multiple servers.) However, the issue at the heart of the question remains one of the user wanting to establish a legally-binding requirement of service on the Directory, which is quite a different matter. I don't see that CILs solve this either - if the Directory refuses to provide certs, why should it provide CILs? David. -- David Boyce Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND I'net: d.boyce@isode.com Isode's WWW: http://www.isode.com/ X.400: I=d;S=boyce;P=isode;A=mailnet;C=fi;
- Re: operational protocols Housley, Russ
- Re: operational protocols Housley, Russ
- Re: operational protocols Patrick Richard
- Re: operational protocols Reginald Carey
- Re: operational protocols Stef Hoeben
- RE(2): operational protocols T.A.Parker
- Re: operational protocols Mike Smith
- Re: operational protocols Mike Smith
- Re: operational protocols Stef Hoeben
- Re: operational protocols David Boyce
- Re: operational protocols Stef Hoeben