- caops-wg - lists.ogf.org

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

Fwd: [wg-all] Document #62 published: Policy Management Authority Model Charter
by Olle Mulmo 05 Feb '06

05 Feb '06

Finally! /O Begin forwarded message: > From: "Gregory Newby" <newby(a)arsc.edu> > Date: February 2, 2006 21:29:43 GMT+01:00 > To: wg-all(a)ggf.org > Subject: [wg-all] Document #62 published: Policy Management > Authority Model Charter > > Announcing a newly published Community Practice document in the GGF > document series: > > Title: Policy Management Authority Model Charter > Author/editor: R. Cowles, T. Genovese, P. Gietz, M. Helm > GFD #: GFD-C.062 > Download link: http://www.ggf.org/ggf_docs_final.htm > > Abstract: This document provides a template that can be used to > develop a charter for a Grid Policy Management Authority [GPMA] The > GPMA is responsible for the management of a "Grid Public Key > Infrastructure" [GPKI] and its associated "Grid Certificate > Authorities" [GCA]. GPMAs will serve as the points of contact for > GPKIs that wish to interoperate. A GPMA is responsible for managing > external relationships and any resulting internal changes. > > > -- Greg Newby (GGF Editor) >

1 0

Proxy Cert Revocation - Pros&Cons
by jluna＠ac.upc.edu 03 Feb '06

03 Feb '06

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

1 0

RE: [caops-wg] Teleconference
by Cowles, Robert D. 30 Jan '06

30 Jan '06

Yes .. this is now scheduled for 10am PST > -----Original Message----- > From: owner-caops-wg(a)ggf.org [mailto:owner-caops-wg@ggf.org] > On Behalf Of Mike Helm > Sent: Sunday, January 29, 2006 4:55 PM > To: Alan Sill > Cc: Olle Mulmo; caops-wg(a)ggf.org; 'Jesus Luna' > Subject: Re: [caops-wg] Teleconference > > Alan Sill writes: > > I think that would have to be 6:00 pm Central European time > to be 9 am > > Pacific: > > > >>> If not, I suggest we set something up at > www.freeconference.com for > > >>> Monday, > > >>> 18:00 UTC. (7pm Central European, 9am Pacific) > > >> > > >> 9 AM PT will work for me, but I have to leave promptly > at 10 AM. > > >> Thanks, ==mwh > > > > > > Date: Monday, January 30, 2006 > > > Start Time: 7:00 p.m. Central Europe Time > > > > > > Dial-in Number: 1-712-432-2323 > > > Participant Access Code 22677 > > This is becoming problematic for me; my other appointment has > just been > moved up from 1030 AM to 10 AM PT. I will probably have to leave > around 930. > >

1 0

RE: [caops-wg] Encoding AIA in first-level Proxy Cert
by Cowles, Robert D. 29 Jan '06

29 Jan '06

> In DOEGrids ... I am not sure about every other IGTF PKI however ... > end entity certificates can revoke themselves. It's often done. For > instance, when a security issue arose at one site, several customers > revoked their own certificates until local problems were cleared up. > > Why wouldn't we permit this idea to be extended to proxy certs? > That is, why shouldn't a proxy cert be permitted to revoke itself? > What conditions would speak against that? It does cerate an interesting denial of service possibillity in that if I compromise a machine that has proxy certs going thru it, I can revoke all subsequent proxies for the whatever proxy certs I find on that machine. If a higher level had to do the revocation then I would have to know something about the proxy certs generated by apps using those proxies, and it would seem more difficult t get that information. BC

2 1

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