October 2005 - caops-wg - lists.ogf.org

Encoding AIA in first-level Proxy Cert
by Jesus Luna 09 Feb '06

09 Feb '06

Hello, About this topic we would like to comment that -in analogy to non Grid PKIs- revocation of a N-level Proxy Certificate should only be performed by its Issuer (N-1 level entity, does not matter if it is an EEC or another Proxy) *and* by any other entity up to the Root CA itself (that is hierarchy levels N-2...0). When a certificate is revoked, then their issued certificates (again does not matter if EEC or Proxies) should be considered revoked. The "one-request" mechanism proposed in OGRO (embedding the whole Proxy Cert Path in one OCSP Request ) could manage this proposal with some modifications, because when the OCSP Response is received then it could invalidate the Cert Path just below the certificate whose status is not "Good". We have been exploring also the "direct Proxy revocation" method: when a Proxy is destroyed or revoked for any other reason then an "administrative" message is sent to the OCSP Service so the revocation is done directly in its certificate status database. The authorization checking on such admin message is based on a very simple system that verifies if the issuer (message originator) is able to revoke such credential (i.e. is part of the Certificate Path and can be found in any level above the Certificate being revocated).This should be customizable by the relying party, i.e. in a new rule of the Grid Validation Policy. Based on this, we don't think encoding the AIA into the Proxy Certificate should be mandated, but instead it would be better to apply the same provisions of section "4.4 Responder discovery" (from the current version of the document). In any case a mechanism like OGRO's Grid Validation Policy may deliver this feature to relying parties. We hope to have understood the same idea that you presented with the PPT back at the GGF15, but in any case please let us know what you think. Regards, Oscar & Jesus

8 36

Which OCSP responder to trust?
by Jesus Luna 25 Jan '06

25 Jan '06

Hello again, In slide 4 of the presentation "OCSP-GGF15.ppt" three different OCSP discovery mechanisms are mentioned to validate user and Proxy Certificates; in this case we agree with them (in fact the first two are referenced in some way in secton "4.4 Responder discovery"), however it could be convenient to mention also the possibility of using the multicited OCSP Policy to accomplish such configuration at the relying party. The third option "OCSP-signing proxy delegated to responder", could you elaborate more on this? We are not getting the idea behind such concept. Regards (one more time!), Oscar & Jesus

2 2

OCSP validation performance in Grid environments
by Jesus Luna 28 Oct '05

28 Oct '05

Hello again (one more time!), Even though we are still in the process of formally publishing this info, we would like to comment about the results obtained at this date with OGRO+Grid Validation Policy+GT4. Maybe some of them could be interesting for the "OCSP Requirements for Grids" document. We have measured the time elapsed in validating through OCSP (OGRO) a Proxy Certificate Path i) at the client-side when the user creates it by executing "grid-proxy-init" and, ii) at the server-side when the GT4's WSRF Container receives a Grid Service invokation (CounterService) through the secure message mechanism. In both cases we were using different Grid Validation Policies to understand the overhead introduced when customizing parameters like use of digital signatures, nonces, HTTP/HTTPS, fault tolerance, etc. In most of the cases the results showed that the decision to protect the OCSP Request with digital signatures, nonce and HTTPS introduces an overhead which is practically non-existent when compared with the overhead of communicating with the OCSP Responder itself. To aliviate such overhead we have implemented a mechanism called pre-validation, which embeds the OCSP Response as a Proxy Certificate extension when such credential is being created by the client. When the server needs to validate such data, it merely needs to extract the pre-validation data from the Proxy and procced with the usual OCSP verification process. In our tests we have measured elapsed times 30% lower than those obtained with "traditional" OCSP validation at the server (WSRF Container). Hope this information may be useful for the document. Best regards (finally!), Oscar & Jesus

1 0

Proxy Certificates discussion
by Jesus Luna 28 Oct '05

28 Oct '05

Dear all, We have been reading the presentations made by some of you in the last GGF sessions and we would like to comment about OCSP and Proxy Certificates, due in part to the experience that we have achieved with our Open Grid Ocsp -OGRO- API and on the other hand with the spirit to finish as soon as possible the "OCSP requirements for Grids" document. Next you'll receive three follow-ups to this email related with the Proxy Certificate's topic: -First we will present our point of view about the proposal of encoding AIA in first-level Proxy Cert, as mentioned in the presentation "OCSP-GGF15.ppt" available on the CAOPS-WG' Web page. -In second place we would like to comment about the "Which OCSP Responder to Trust?" topic, also mentioned in the PPT. -Finally we would like to briefly present the results of some tests done in the last weeks with OGRO and its Grid Validation Policy. We have not only tested several policy configurations (i.e. signing the Requests, using nonces and sending OCSP over HTTPS), but also implemented a mechanism to further improve OCSP validation perfomance in Grids, called "OCSP Pre-validation" which is being beta-tested in our installations prior to be published in OGRO's Web page. In any case, based in your comments we may be able to commit asap to the list the draft text for the document's Proxy Validation section. Best regards form Barcelona, Oscar & Jesus

1 0

RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
by Cowles, Robert D. 16 Oct '05

16 Oct '05

> -----Original Message----- > From: Frank Siebenlist [mailto:franks@mcs.anl.gov] > Sent: Wednesday, October 12, 2005 9:06 PM ... > > Note that with Kerberos cross-realm authentication, one realm > is unable > to issue credentials for the director of the other institute... Isn't the kerberos realm included in the token, thereby providing the equivalent of the CA information? > > With your proposed scheme, any "trusted" CA in Italy, Germany, even > Holland..., would have the theoretical opportunity to issue a > certificate that would impersonate the director of Berkeley, NCSA, > Livermore, Los Alamos... and we would have no way to enforce > any policy in real-time that could prevent it. Impersonate? How? One of the points of this discussion is that there isn't enough information in the certificate to be able to use it reliably for knowing who someone is unless it's surrounded by a lot of other "context" (like registering with a VO and saying "here is my certificate"). The only way we could tell whether the Frank Siebenlist a certificate refers to is you is if it contains a lot of personally identification information (PII) about you (MMN, phone, SSN, birhtdate) ... all the kind of stuff that we've learned to NOT make available in a public setting. As David has pointed out, there's no real difference between having the CA's divide up the space of DN's or having them each have a unique CA name that we then append to the DN to get something globally unique.

2 1

RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
by Cowles, Robert D. 16 Oct '05

16 Oct '05

> -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Thursday, October 13, 2005 2:39 AM ... > > Robert > > perhaps the real question is, do you change your authorisation rights > more or less frequently than your identifier. If more > frequently, then > it does not really matter if your identifier changes every > year or two > since you can change your authorisation rights to match the new > identifier when it comes active. But if your authorisation rights are > much longer lived than your identifier, then it becomes a > pain to have > to change these as well. However, in this case I would > suggest that your > authorisation rights are wrapped into the PKC, say in the > subjectDirectoryAttributes extension, then they would carry > over to the > new identifier. > > regards > > David In teresting point .. and that is precisely a problem we have with Attribute Certificates and Proxy Certificate renewal. I have been wondering if we can extend the allowed lifetime of proxy certificates so long as we can revoke their authorizaton to do anything. BC

2 1

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 16 Oct '05

16 Oct '05

> the issue is about global naming. You used a globally unique email > address in the certificate when you posed the question, so I > said yes. > If on the other hand you had just put Brett in the cert then > of course I > would not expect this to always name the same person. > But how can you believe that brett(a)isp.com is globally unique over time when companies like Verisign will resell "isp.com" almost immediately when it becomes available? BC

2 1

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 16 Oct '05

16 Oct '05

> > As I have said before, the purpose of a CA is to authenticate > a user's > right to use a claimed name, and then bind that to his public > key ie. to > certify the key to name binding. ie., a certification > authority. It is > not, I repeat not, to be a naming authority. > > regards > David As I have said before, the purpose of a CA it to be sure that if it is issuing a certificate either the DN has not been used before by that CA or it can verify that it is issuing the Cert to the same person as used the DN before. Unfortunately, this means storing Personally Identifiable Information so you can have something to check at time of renewal / re-issue ... and we are being required to have more and more protection associated with any PII we retain. Bob Cowles

2 1

RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
by Cowles, Robert D. 16 Oct '05

16 Oct '05

> -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Friday, October 14, 2005 9:48 AM ... > Cowles, Robert D. wrote: > > > > The gridmapfile gives no clue as to CA or to VO. > > > > Why do PKI *users* care about 2)? > > They dont (except to know which CA to go to). Name constraints is a > trust issue between CAs, they set the policies, and then the > RPs enforce > them when giving access to their resources. Of course an RP > can ignore a > CA's policy, and trust any cert it wanted to, but then it would be > entirely responsible for any losses incurred. > > regards > David Precisely .. it's between CA's. When I brought up the issue of signing policy several year ago it was in the context that we weren't telling the relying parties that the authentication mechanism relied on the signing policy file and in keeping the DN's for the CA's to be disjoint sets. A site could easily believe that another CA was entirely trustworthy in authenticating users (e. g. Verisign rather than Thawte) and not realize that if the set of DN's you could get Versign to issue overlapped with one of the other CA's then you no longer had viable authentication, eventhough all the Ca's were doing their job and you correctly described the certificates that could be trusted in the signing policy file. My point is that we always say it's up to the RP to put any CA in the list of trusted CA's but we weren't saying that the DN's MUST NOT overlap those from any other trusted CA.

1 0

RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
by Cowles, Robert D. 16 Oct '05

16 Oct '05

> -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Friday, October 14, 2005 9:50 AM ... > > Cowles, Robert D. wrote: > > > > The gridmapfile gives no clue as to CA or to VO. > > Also to the time of day, or user location, or request parameters, or > hundreds of other things that might place conditions on what > the user is > allowed to do. So gridmap files were a nice first shortcut to get > something working fast (a bit like the GridShib mapping file > today)but > they cannot realistically be expected to provide a long term solution > > regards > > David No .. but they seem very "sticky" and difficult to get rid of. I am also aware of sites adding CA's to the trusted list without understanding the implications of having a "trusted CA" that had no signing policy constraints .... I could be wrong -- if a CA doesn't appear in the signing policy file, is it unconstrained or competely constrained? (if couse, if the latter, the site is likely to add an unconstrained entry to get things working rather than try to figure out the proper constraints.) BC

1 0