February 2006 - caops-wg

Re: [caops-wg] OCSP & Proxy Certs
by Mike Helm 22 Feb '06

22 Feb '06

I was talking to Frank Siebenlist of Argonne & Globus, and he is interested in taking on some of the client side issues in the OCSP Requiremets paper & making sure they are properly addressed. This is something he and Von Welch, in another context, have emphasized as being very important for OCSP and similar services. This attention & input should be very useful. What was the discussion at CAOPS at GGF-16? I haven't seen any minutes or feedback. Thanks, ==mwh Michael Helm ESnet/LBL

2 2

GGF16 Meeting Materials
by Darcy Quesnel 21 Feb '06

21 Feb '06

GGF16 meeting materials are now available online. http://forge.gridforum.org/docman2/ViewCategory.php?group_id=56&category_id… Darcy

1 0

OCSP Document with additional comments from CertiVeR and UPC.
by Jesus Luna 14 Feb '06

14 Feb '06

Hi, I'm sending a new incarnation of the OCSP document which includes some comments/additions from CertiVeR and UPC. I'm not sure about my comment regarding VOMS-like systems (page 12) 'cause if it is correct then may bring additional complexity to the Proxy Revocation Mechanism. :( Salut, -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> o o o Jesus Luna Garcia | Polytechnic University of Catalonia o o o PhD Student | Department of Computer Architecture o o o phone: +34 93 401 7187 | Campus Nord. www.ac.upc.es U P C fax: +34 93 401 7055 | C/Jordi Girona 1-3, Modul D6-116 E-mail: jluna(a)ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

1 0

Presentation slides OCSP document
by Jesus Luna 14 Feb '06

14 Feb '06

Regards, -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> o o o Jesus Luna Garcia | Polytechnic University of Catalonia o o o PhD Student | Department of Computer Architecture o o o phone: +34 93 401 7187 | Campus Nord. www.ac.upc.es U P C fax: +34 93 401 7055 | C/Jordi Girona 1-3, Modul D6-116 E-mail: jluna(a)ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

1 0

RE: [caops-wg] OCSP & Proxy Certs
by Cowles, Robert D. 13 Feb '06

13 Feb '06

> Conclusions: > We should recommend CA operators include an AIA URL for OCSP, and > stand up a server. > Since not every CA can do this, we should recommend some agency > (IGTF? commercial?) stand up clearinghouse OCSP responders which > can become well-known & trusted resources > A protocol for permitting authenticated updates (registering of > revoked proxy certs) may need to be developed > OCSP client software must ignore "unknown" responses about proxy > certs - no info is no info in this case. > Following up on discussions at the EUgridPMA and post-meeting discussiions, I'm really nervous about the fragility of a network of OCSP responders.... that's just for the CA's and doesn't really address the issue that Mike raises of how we set up a network of responders that will do what we want with proxy certificates. For what it's worth, there seem to be a number of wireless providers in airports, etc. that I'm seeing recently who are supplying OCSP information that Firefox chokes on and so it won't allow me connect to the site. Being a typical user, I don't give damn about the PKI infrastructure, I just wantto chckmy email and I don't want have to spend an even longer time screwing around ... as a result, I now use IE to connect to wireless systems for payment, registration etc. Also, IE doesn't seem to cache the DNS and so as I move from airport to airport, it is more likely to do the redirection to the new registration page in a timely fashion than Firefox. (I suspect that the same issue is involved in the OCSP error code I receive, but I haven't bothered to look it up. BC

6 16

Proxy certificate revocation text
by jluna＠ac.upc.edu 10 Feb '06

10 Feb '06

Hi! You will find attached to this message our proposed text for the Proxy Revocation topic, taking into account some comments from D. Chadwick as mentioned in the teleconferece. Best regards, Oscar & Jesus

3 2

Some -small- comments about the document
by jluna＠ac.upc.edu 10 Feb '06

10 Feb '06

Dear all, As mentioned in the teleconference, next you will find some comments/questions about the document (ver 0.3): -Page 6, line 8: I'm not pretty sure about it, but if you perform a random search then chances for finding an operative OCSP Responder are greather than sequentially searching for it. -Page 6, lines 14-18: maybe we are entering into too much detail about DNS SRV requirements for OCSP. It is good for the paper, but in that case maybe we should write something more about the WS-Resource option. -Page 6, line 20: Reference point to [WSRES], but should say [WSREF]. -Page 7, lines 15-17: Do you want us to insert a link/reference to our OGRO API? Such API implements a configuration file providing this set of options so it may be a good example ;) -Page 7, lines 23-25: The term "OCSP Policy" is exactly equal to "OCSP configuration file" (as in 4.7), so we may replace it for keeping a uniform terminology. -Page 8, line 1-2: I'm not pretty sure about it but think that the second "to" is misplaced here. Apart from this, as such "features" are inherent (sniff) to networks :( the "MUST" could be changed for a "SHOULD". -Page 8, line 10: The term "Grid Services" in this context is not very clear for us, could you please explain little more? -Page 10, line 43: The term "multi-certificate queries" refers to OCSP Requests messages querying the status for more than one certificate? If so, then I don't know if it should be pointed this way as that is part of any conformant RFC2560 implementation. -Page 14, line 17: As pointed before, maybe we should say that such policies could be part of a more general OCSP Configuration file. Best regards and hope to send you comments about Proxy Certs and DCRLs during the week, Salut, Oscar & Jesus

3 2

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

I-D ACTION:draft-ietf-pkix-scvp-22.txt
by Alan Sill 06 Feb '06

06 Feb '06

Thought you would be interested in the following link. Topic: draft-ietf-pkix-scvp-22.txt http://www.imc.org/ietf-pkix/mail-archive/msg03049.html Alan ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

Fwd: [caops-wg] Proxy Cert Revocation - Pros&Cons
by jluna＠ac.upc.edu 06 Feb '06

06 Feb '06

Hello Mike & all, I'm sending this message again. Hope you receive it! Salut, Jesus Luna ----- Mensaje reenviado de jluna(a)ac.upc.edu ----- Fecha: Fri, 3 Feb 2006 12:31:24 +0100 De: jluna(a)ac.upc.edu Responder-A: jluna(a)ac.upc.edu Asunto: [caops-wg] Proxy Cert Revocation - Pros&Cons Para: caops-wg(a)ggf.org Dear all, As mentioned in the last teleconference, we are sending to the list a first version of "Proxy Rev Pros+Cons". Hope you like it :) ****Pros: **Improved security as every involved Proxy Cert will be included into the path validation prior being authorized by Grid relying parties. **Relying parties may have more control over their owned Grid resources as Proxy Revocation could be the mechanism to implement blacklists in those Authorization systems not supporting them. This could be implemented by using a fine-grained AA revocation support in Proxies with embedded Authorization information (i.e. CAS, VOMS). In this way, resource owners may be able to revoke authorization attributes, while identity providers would be in charge of revoking the authentication credential (the Proxy Certificate itself). **The EEC owner may be able to indirectly manage submitted jobs by revoking or suspending User Certificates. ****Cons: **A Proxy Certificate may be created for accessing more than one particular resource, while authorization attributes are typically issued in a finer-grained way. The use of fine-grained revocation would help to control the revocation of authorization attributes while avoiding conflict with other processes being executed on behalf of the same Proxy Certificate. In this case, the revocation of the Authorization Information would be done by the resource manager. **Small CAs may be required to operate a fault tolerant (24*7) OCSP service and in most of the cases to re-issue EECs in order to include the AIA extension. **If CAs are not willing to operate their own OCSP service, then a long term relationship with an appropriate OCSP provider should be established because the administrative and technical costs that such task involves may be too expensive for the CA. **Being short-lived, Proxy Certificates registration and identity validation may become a bottleneck at the RA/OCSP service. Also the mechanisms to securely perform such task should be developed (i.e. we require it to take place as an atomic and authenticated transaction). The solution to this problem should be highly scalable as the potential number of Proxy Certificates could be expected to be greater than EECs. For long Proxy Certificate hierarchies, the certificate path building process at the RA/OCSP may represent a sensible overhead for the service. In order to avoid such bottleneck, no proxy certificates should ever be registered for Identity Revocation. Only registered owners should be allowed to revoke their proxy certificates. However, this change would imply changing the semantics of the OCSP response for Proxy certificates. In this case, an unknown OCSP response for a Proxy certificate would be taken as valid identity. **The Proxy Revocation process will require developing the secure mechanisms to authenticate and authorize the requestor. If blacklist will be implemented through this mechanism, then low-latency or even real-time publication/notification of such revocation should be emitted to relying parties so jobs being executed with compromised credentials could be stopped as soon as possible. Note that pre-computed OCSP responses can not be used for this purpose. **It is recommended to adopt full chain validation because if an OCSP Request for a single Proxy Certificate is created the full path is not included in the message-, then the OCSP Responder may become overloaded with the Proxy Path Validation process (i.e. performing the path discovery). Best regards from Barcelona, Oscar & Jesus ----- Fin del mensaje reenviado -----

1 0