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
I will come back to this material in a little different way later, but I wanted to address these points: Jesus Luna writes:
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.
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?
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
Let's try to work thru some use cases. This is surely an attractive idea but I am not sure we can deal with all the corner cases. More on this in another message (perhaps not directly tho).
From this I conclude that the only AIA that's safe is the EE's
Let me list some assumptions and characteristics of proxy certs, and related services (please correct and add as needed). There's also some new things on the table that we need to consider. Proxy cert characteristics Autochthonous - typically generated on the spot, by the user or a delegated process Not likely to be "registered" anywhere (perhaps in myxproxy, see below) Different types (pre-, post- RFC3280, general, specific attributes) Different capabilities (attributes; dependent on conforming software) Time limits - minutes to weeks (potentially longer) Cascades of certs - delegated rights to create proxies given to processes Portable - software crypto store; private key can typically be copied to a new location Proxy certs are the means of crossing domain boundaries (not always, but one of the design points) [I think this is one of the points that is going to create the most trouble for proxy cert OCSP, if that's not already evident] Services using proxy certs Will have access to the end entity certificate that tops the proxy chain Whether they have access to a trust root for the EE cert or not, is the question that motivates a more general validation service, something to take up later New services MyProxy - this credential store service has become more important in the past year or so, and developing in tandem is SLCS - short lived certificate services Bridge existing authentication to an X.509 - generating CA; this may be operated together with a MyProxy service (see http://myproxy.ncsa.uiuc.edu/) MyProxy can store and manage key pairs for various usage scenarios. Who can revoke proxy certs (or who wants to revoke them)? Let me list some possibilities, from less controversial to more, and then discuss some usage scenarios. - The EE certificate owner - A lower generation proxy cert from the chain - the proxy cert itself - the affected resource owner - a local security officer - The EE cert issuer or any member of that chain I put these in 3 groups. The first, the proxy cert & EE cert, just seem to me to be instances of the same "agent". The 2nd is one of the motivations for this work: we should provide a means for resource owners to protect their resources, w/o causing unnecessary problems for EE cert holders. The latter Jesus mentioned in his message ... and it seems weird to me. As a CA operator I can't imagine a scenario where I would revoke a user's proxy cert. It seems like it's out of my scope as CA manager (it's something like your bank manager telling you where to spend your money). Thinking about our PKI architecture ... I don't think we would or could permit our root CA to revoke the EE certs in the subordinate CAs. The CRL-reading software probably wouldn't understand it. Some conclusions I draw: 1) The user (EE Cert) & the site security folks (group 2) are 2 separate anchors for proxy cert trust 2) The CA revoking sub certificates and the EE revoking proxy certificates are somewhat different - does this change how we manage revocation info (That is, in CA, Isub(n) can revoke EEsub(n+1), but EE and any Proxy sub(n) can revoke Proxy sub(n or greater)) Observation: Group 2 - site security - is fuzzy. In every local context it probably is clear but there will be many variants, and thus the right to revoke is going to vary, yes? MyProxy particularly introduces a new player. If myproxy is set up as an enterprise service, or VO service &c, then the server manager has some role independent of the other 3 groups. Does the MyProxy manager have the right to revoke proxy certificates held in this store? Let's suppose there's a perfect infrastructure, where all the CAs issue EE certs with AIA URLs to their OCSP responders. Suppose EE proxy generators cause the proxy certs to inherit this AIA URL. An application encountering a proxy certificate will find a CA OCSP responder that it can query. (An application - something doing real work, as opposed to security :^) Suppose this infrastructure includes a MyProxy service that installs its own OCSP responder URL; the application will find that (does it still find the remote OCSP responder or not)? Suppose this infrastructure has its own local OCSP responder, for caching and to meet local security needs. The application will find this URL. Now imagine that a proxy cert crosses a domain boundary. Perhaps the myproxy responder, or Domain1's local responder, are local-only servers and cannot answer outside their domain. What happens to the application when it tries to act as an OCSP client? link to his issuing CA's OCSP responder; or, an OCSP server acting as a clearinghouse - community resource (like certiver, or the DOEGrids demo for EUGridPMA). This seems to lead to a recommendation that CA OCSP responders develop the capability to store & return info on their clients' proxy certs. This is a tall order, but not insurmountable. Now let's look at this from the EE's point of view. I have some chain of proxy certs, and I've set off a job that I need to stop. I want to revoke the proxy cert or certs it's using. How do I do this? Well, in general I have an AIA URL in my own cert, and I may or may not have some knowledge of a clearinghouse OCSP server. I could run a simple script that delegates a proxy ocsp responder right to some service. How do I limit that right? Or, could I just register the proxy cert I want to revoke, thru an authenticated process to the OCSP service I want to use for registering this revocation? OCSP doesn't have a UI or protocol for this phase of its work; it seems to me we are the point of describing an extension protocol for this UI. Let's look at the revocation problem from the local security point of view. They can meet their needs by standing up a local OCSP responder, and persuading their community to use it on their resources. But they would like to protect themselves from problems they don't know about, which include security problems arising in closely linked domains. For example, Supercomputer Site A and Big University B are closely linked. "A" would really like to know about local revocations in "B" to keep problems from spreading. "A" and "B" could establish an agreement to replicate data back and forth from local blacklist - OCSP responder databases. A more generalizable and scalable arrangement might be: "A" and "B" could agree to use a standard evaluation algorithm, which orders OCSP revocation as (local, then clearinghouse, then EE AIA); and adopt a relationship with clearinghouse OCSP's and CA OCSP's, permitting the local site to upload proxy cert revocation information to the databases of these CA's. MyProxy manager, if permitted to deal with this, seems more like a variant of the EE case. The myproxy manager needs to be able to act on the credential store's customers' behalf in the same way the customer would behave. 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. I am sure there is much more to say about this and other views. I have some document comments about some minor points but I have a plane to catch and will get back to that in a day or 2. Thanks, ==mwh Michael Helm ESnet/LBL
Mike Helm writes:
Let me list some assumptions and characteristics of proxy certs, and related services (please correct and
Bob Cowles at the OSG Consortium security meeting today mentioned another possible OCSP - short term proxy cert configuration that I should make you aware of. The idea here is that proxy cert lifetime be extended longer and longer, perhaps becoming indistinguishable from short term certs or even long term certs. Then use a revocation mechanism like OCSP to kill them when absolutely necessary (more typically, drop authorization privileges, but as a practical matter it's not yet completely clear how that is to be done). I think that this case is or can be covered by the spectrum of OCSP scenarios we already have, but maybe Bob or others can look at the document and test it against their proposal. It also shades into some of the ideas that some of us have been discussing for a full fledged validation service, a topic we can take up elsewhere. Bob Cowles mentioned this to me recently (maybe Boston GGF) or at least some version of it but I don't know that either one of us mentioned it in this group before. Thanks, ==mwh Michael Helm ESnet/LBL
On Jan 22, 2006, at 19:12, Mike Helm wrote:
Proxy cert characteristics Autochthonous - typically generated on the spot, by the user or a delegated process
A fine word, but not applicable. When a user on host A delegates to B, which then authenticates to C, the proxy cert is created at A, stored at B and seen at C. The private key is autochthonous, but this is generally true of non-proxy private keys as well.
For those of us mortals who flunked their Latin&Greek: autochthonous |ôˈtäkθənəs| adjective (of an inhabitant of a place) indigenous rather than descended from migrants or colonists. • Geology (of a deposit or formation) formed in its present position. Often contrasted with allochthonous . Main Entry: au·toch·tho·nous Pronunciation: o-'täk-th&-n&s Function: adjective 1 : INDIGENOUS, NATIVE <an autochthonous people> 2 : formed or originating in the place where found <autochthonous rock> <an autochthonous infection> - au·toch·tho·nous·ly adverb (not that this helps very much ;-) ) there is even an "autochthonous.org" (autochthonous.org - Getting back to where we're from!) A confused Frank. Matt Crawford wrote:
On Jan 22, 2006, at 19:12, Mike Helm wrote:
Proxy cert characteristics Autochthonous - typically generated on the spot, by the user or a delegated process
A fine word, but not applicable. When a user on host A delegates to B, which then authenticates to C, the proxy cert is created at A, stored at B and seen at C. The private key is autochthonous, but this is generally true of non-proxy private keys as well.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
For those of us mortals who flunked their Latin&Greek: autochthonous |ôˈtäkθənəs| adjective (of an inhabitant of a place) indigenous rather than descended from migrants or colonists. • Geology (of a deposit or formation) formed in its present position. Often contrasted with allochthonous . Main Entry: au·toch·tho·nous Pronunciation: o-'täk-th&-n&s Function: adjective 1 : INDIGENOUS, NATIVE <an autochthonous people> 2 : formed or originating in the place where found <autochthonous rock> <an autochthonous infection> - au·toch·tho·nous·ly adverb (not that this helps very much ;-) ) there is even an "autochthonous.org" (autochthonous.org - Getting back to where we're from!) A confused Frank. Matt Crawford wrote:
On Jan 22, 2006, at 19:12, Mike Helm wrote:
Proxy cert characteristics Autochthonous - typically generated on the spot, by the user or a delegated process
A fine word, but not applicable. When a user on host A delegates to B, which then authenticates to C, the proxy cert is created at A, stored at B and seen at C. The private key is autochthonous, but this is generally true of non-proxy private keys as well.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Matt Crawford writes:
On Jan 22, 2006, at 19:12, Mike Helm wrote:
Proxy cert characteristics Autochthonous - typically generated on the spot, by the user or a delegated process
A fine word, but not applicable. When a user on host A delegates to B, which then authenticates to C, the proxy cert is created at A, stored at B and seen at C. The private key is autochthonous, but this is generally true of non-proxy private keys as well.
I think you have the generation wrong. What I should have said is "the proxy key pair", which is what I think is often what is commonly meant when "proxy cert" is used, and what I meant, but there is no dispute that that word usage is wrong. Certainly, the proxy cert, which is a label on one of the keys, is created at A. But that key pair is typically created = generated at B and stays there, or is meant to stay there, and that is what is autochthonous. At least, that's how I understand the typical usage. If the key pair appears somewhere else, that is strange, and probably not a good thing either.
Proxy cert characteristics [...] But that key pair is typically created = generated at B and stays there, or is meant to stay there, and that is what is autochthonous.
But that's true of almost any key pair (it's generated in the smart card, HSM, laptop, ... and is meant to stay there), so it isn't an interesting statement about proxy key pairs in particular.
Matt Crawford writes:
Proxy cert characteristics [...] But that key pair is typically created = generated at B and stays there, or is meant to stay there, and that is what is autochthonous.
But that's true of almost any key pair (it's generated in the smart card, HSM, laptop, ... and is meant to stay there), so it isn't an interesting statement about proxy key pairs in particular.
Oh no. Smart cards are quite portable. This is a particularly interesting example, since one of the common deployment scenarios consists of having the PKI management issue you a card, having installed the keys on it for you. Our HSMs at least are portable. Usually something has to be done for key movability in HSMs for disaster recovery. Key pairs in browsers and other software crypto stores are allowed to be copied from one store to another and indeed that is the typical way they have to be used in Grids. &c. The private keys in these cases are only meant to be kept private; appearance in a different locale is not necessarily a bad thing.
Matt Crawford writes:
[About proxy certs]... When a user on host A delegates to B, which then authenticates to C, the proxy cert is created at A, stored at B and seen at C.
2 contradictory thoughts occurred to me A) What if proxy certs had a "Made at <X>" stamp on them (Does anybody do this now?) Would this help? At the very least, the relying party could scan certs for this attribute and disallow something it doesn't like. B) What we don't want is migrating proxy cert private keys (Is this true? I wouldn't be surprised to find somebody depending on being able to do this, but I hope not). But all we can do is stamp the public key, not the private key. We can't tell if a private key has migrated somewhere we don't want it to be.
2 contradictory thoughts occurred to me A) What if proxy certs had a "Made at <X>" stamp on them (Does anybody do this now?) Would this help?
This has been discussed before, and that kind of stamp would be useless unless it came from someone trusted party (i.e., not the user) that "vets" the key pair: it's associated owner, it's location (maybe), it's level of protection, and so on. Having such a beast around would allow us to shortcircuit and circumvent a lot of the problems, so rather than using it as a patch to the patch to the original problem, it would allow for completely new usage scenarios.
But all we can do is stamp the public key, not the private key. We can't tell if a private key has migrated somewhere we don't want it to be.
Arguably, you don't really care about the location: you care about the protection. Key server A may securely transfer it to key server B for redundancy purposes, a key on a smart card moves around as the user moves around, and so on. And, as discussed above, you cannot argue about protection level unless the assertion is made from someone that "manages" the private key and which is somehow labelled "trusted", e.g. a MyProxy server or a smart card.[*] /Olle [*] Managed credential stores is a phrase that we use in an EGEE context for this kind of stuff -- see e.g. section 4.3 in DJRA3.3: https://edms.cern.ch/file/602183/1.3/EGEE-JRA3-TEC-602183-DJRA3.3-1.2.pdf
I don't want to go down the path of arguing these cases, particularly if they've been hashed out thoroly before, but the better we understand how people expect to use proxy certs, the better the OCSP scenarios will be. I am going to rearrange the order of the comments. "Olle Mulmo" writes:
[B] But all we can do is stamp the public key, not the private key. We can't tell if a private key has migrated somewhere we don't want it to be.
Arguably, you don't really care about the location: you care about the protection. Key server A may securely transfer it to key server B for redundancy purposes, a key on a smart card moves around as the user moves around, and so on.
Ok, I don't care about the smart card case in this context; I assume that proxy certs are never on such a device. But is that true? 2nd, one of the justifications I heard years ago for proxies was to cross administrative domains ie delegate a right from userA on host alpha to userA (same) on host beta. Clearly "key pairs COULD be copied but shouldn't be" was one of the guiding principles. But is that true? Are there scenarios where people expect & need to be able to pack up & move their proxy private keys? Let me assume the answer is either a) they don't or b) these are very specific well - defined cases. If neither, then I don't think what follows is useful anyway.
A) What if proxy certs had a "Made at <X>" stamp on them (Does anybody do this now?) Would this help?
This has been discussed before, and that kind of stamp would be useless unless it came from someone trusted party (i.e., not the user) that "vets" the key pair: it's associated owner, it's location (maybe), it's level of protection, and so on.
Having such a beast around would allow us to shortcircuit and circumvent a lot of the problems, so rather than using it as a patch to the patch to the original problem, it would allow for completely new usage scenarios.
I am not sure why you need that level of assurance about the "made at <X>" assertion (sure it couldn't hurt). Let's use Matt Crawford's diagram: "When a user on host A delegates to B, which then authenticates to C, the proxy cert is created at A, stored at B and seen at C." The made-at assertions seem like any other that might be in a proxy cert, but I am assuming the user at A is making this assertion along with the rest of his ID info. If he puts the wrong made-at information in the cert, the worst that can happen is that he denies himself some service by failing some policy test - either on B or C. But the difficulty I see with this is that we really want to stamp the proxy private key with this made-at info, the proxy certs themselves are used to cross admin boundaries. There is no standardized private key usage management (people have talked about things like that and I think Entrust has some features but nothing general that I know of). Thanks, ==mwh
On OCSP AIA's in end entity certs. We discussed the problem of small CA's standing up an OCSP responder & operating them on a 24x7 basis; this is one of the "cons" to the recommendation that CA's do this, and stamp their EE certs with their OCSP responder. But it is not necessary that the CA provide its own responder; it can delegate that right to another responder, as Olle/David Groep (apparently) suggest. So it is only necessary that a CA find an OCSP service with which it can establish that relationship; then it can include this responder URL in its certificates. Obviously, this must be a long-term relationship, because a change in responders or URL information will invalidate those end entity certificates.
Dear all, Mike's email is pretty comprehensive and there are several interesting points to comment. I'll try to make it in a couple of emails (hope so!)... Mike Helm wrote:
Time limits - minutes to weeks (potentially longer)
I can see that these "longer lived" proxy certificates are like the kind of credentials that you commented in your last email (something related with OSG Consortium). IMHO it looks like in the worst of the cases they can be treated like EEC...or even SLC (which seems to be one hot topic at the in-progress EUGridPMA meeting), in any case hope we can found that they can be covered by the mechanisms described the OCSP Reqs document (at a glimpse I don't see a reason for the opposite).
Services using proxy certs Will have access to the end entity certificate that tops the proxy chain
This is enough information for the OCSP Responder -should it be aware of Proxy Certificates statuses-.
SLCS - short lived certificate services
I was not aware of such concept, but reading the TAGPMA document at: http://www.tagpma.org/files/IGTF-AP-SLCS-20051115-1-1.pdf I've found that in section "4.3 Revocation" the following is stated: "It is assumed that the Short Lived Certificates will not need to be revoked because their life time is shorter than the update cycle of most CRLs. If revocation is supported, then revocation requests can be made by certificate holders, Site identity managers and the SLCS CA. These requests must be properly authenticated. Others can request revocation if they can sufficiently prove compromise or exposure of the associated private key. Individual holders of a SLCS certificate must request revocation if the private key pertaining to the certificate is lost or has been compromised, or if the data in the certificate are no longer valid." Most of the text is pretty similar to Mike's conclusions at the end of this email and the interesting point here are from my point of view the followings: -Entities able to make revocation requests and even though the protocol to use is not specified maybe we should take a similar text. -However I don't agree at all with the "Others can request revocation...." maybe it is too open and in our case should be constrained to Mike's comments below ("Who can revoke...."). BTW in some place I read that SLC must contain AIA extension with OCSP info...
Who can revoke proxy certs (or who wants to revoke them)? Let me list some possibilities, from less controversial to more, and then discuss some usage scenarios. - The EE certificate owner - A lower generation proxy cert from the chain - the proxy cert itself
- the affected resource owner - a local security officer
- The EE cert issuer or any member of that chain
The latter Jesus mentioned in his message ... and it seems weird to me.
My terrible mistake I was trying to express with words a concept related to the "branch pruning" slide from the PPT being commented, where the Proxy Cert should be revoked in some entity above in its Cert Path has been revoked :)
From this I conclude that the only AIA that's safe is the EE's link to his issuing CA's OCSP responder; or, an OCSP server acting as a clearinghouse - community resource (like certiver, or the DOEGrids demo for EUGridPMA).
Here I would like to highlight again the possibility for the parties to agree beforehand (at VO creation/planning) on a OCSP Responder maybe different from AIA, so it may be necessary to let them the flexibility to configure such agreed OCSP Responders at some level: Maybe at the OCSP Policy/client configuration? In any case it would be interesting to take the chance of current EUGridPMA meeting maybe to pose the neccesity of having a (set of) Trusted OCSP Responders which I understand is the clearinghouse Mike mentioned here. I think that Tony Genovese is talking about a Cert Validation Service so it would be interesting to hear about this topic.
Conclusions: We should recommend CA operators include an AIA URL for OCSP, and stand up a server.
Or specified at a policy agreed beforehand as mentioned above.
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
Maybe at PMA's Authentication profiles or at some simmilar document this recommendation could be reinforced in a near future. TERENA's TACAR repository could be also a good idea for a service like this and maybe interesting to mention there now that NREN Grids are being commented at their taskforces.
A protocol for permitting authenticated updates (registering of revoked proxy certs) may need to be developed
Oscar and myself will try to comment something about this topic later, as we have developed such mechanisms at the CertiVeR project.
OCSP client software must ignore "unknown" responses about proxy certs - no info is no info in this case.
OK, but should it be also a config option for those clients whose OCSP provider does not support proxy revocation?
I am sure there is much more to say about this and other views. I have some document comments about some minor points but I have a plane to catch and will get back to that in a day or 2.
Have a nice travel Mike and hope to read from you soon! Regards a todos! -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Jesus Luna writes: [About revocations ... of short term/proxies]
-Entities able to make revocation requests and even though the protocol to use is not specified maybe we should take a similar text.
Maybe, altho as you mention later
Oscar and myself will try to comment something about this topic later, as we have developed such mechanisms at the CertiVeR project.
As well as the OGRO configuration format ... There's a standards document in here somewhere, but it's a little too early for that. Maybe we should add some information about these R&D projects that you all have done, at the least as appendices to the OCSP document. They may not be the last word on this but it will help get the idea out there. What do you think?
-However I don't agree at all with the "Others can request revocation...." maybe it is too open and in our case should be constrained to Mike's comments below ("Who can revoke...."). .... Here I would like to highlight again the possibility for the parties to agree beforehand (at VO creation/planning) on a OCSP Responder maybe different from AIA, so it may be necessary to let them the flexibility to configure such agreed OCSP Responders at some level: Maybe at the OCSP Policy/client configuration?
Have we done a good enough job of describing the different OCSP responder usage scenarios or usage patterns? There is a very good sequence of OCSP responder technical types, but the usage patterns were some of the early motivators of this document. The ones I remember: The CA-related OCSP responder The PMA or large scale clearinghouse: this is what DOEGrids operates as a demo for EDG/EUGridPMA (http://amethyst.es.net/) and the product service Certiver offers them or something like corestreet in the US The VO or site OCSP responder One of the motivators of the paper - sites like NERSC wanted a local blacklist and emergency shutoff mechanism The OCSP caching responder There was also a meshing or chaining responder; I think the original use case was this was a feature of a VO or clearinghouse OCSP in order to glue together CA-linked OCSP responders. All of this is in the document but is it clear? Also, one can see the patterns and models behind this (P2P, DNS, &al) - is it worth spelling out those analogies?
In any case it would be interesting to take the chance of current EUGridPMA meeting maybe to pose the neccesity of having a (set of) Trusted OCSP Responders which I understand is the clearinghouse Mike mentioned here. I think that Tony Genovese is talking about a Cert Validation Service so it would be interesting to hear about this topic.
Conclusions: We should recommend CA operators include an AIA URL for OCSP, and stand up a server.
Or specified at a policy agreed beforehand as mentioned above.
This is ok, but in a world of Grids with porous boundaries, this can make interoperability harder. Suppose "CA alpha" doesn't do OCSP URL's because it's in a Grid where an OCSP responder is assumed (by policy like you mention). A user with a CA alpha cert wants to work with users in the Modern-Grid project, and all their CA's have OCSP responders and extensions in their certs, and no central OCSP responder. So the system and security admins have an OCSP problem with CA alpha's hosts and users. On the other hand, CA alpha's customer base might not notice a problem - their reply party policies will either a) use the AIA extension they find, and be happy with that; or more likely b) use the agreed-on central OCSP resource, configured to deal with Modern-Grid's different OCSP convention It is clearly _better_ that a VO or Grid set up a central responder in order to make sure its own policies are used, isn't it? Should we make this recommendation? Also, in this scenario, I think there are problems moving the proxy cert revocation information between the different kinds of grids, should that be of interest. Modern-Grid's OCSP responder might know of CA-alpha-based proxy certs that are revoked, and are worth reporting, but it has no idea about what place to deliver that information. I don't think we've figured out how to do that, but at least having the EE cert carry an AIA OCSP extension could be the starting point (where to look).
recommendation could be reinforced in a near future. TERENA's TACAR repository could be also a good idea
Terena sounds like a good focal point - are they interested?
OCSP client software must ignore "unknown" responses about proxy certs - no info is no info in this case.
OK, but should it be also a config option for those clients whose OCSP provider does not support proxy revocation?
How do we need to express this? What I want to do is make sure we don't recommend a software engineering problem. I think we can expect that very few proxy certs will ever be revoked (but the ones you want revoked, you really want them revoked).
Mike Helm wrote:
Jesus Luna writes: [About revocations ... of short term/proxies]
recommendation could be reinforced in a near future. TERENA's TACAR repository could be also a good idea
Terena sounds like a good focal point - are they interested?
I've already sent a message to TERENA's nrens-n-grids mailinglist, copied also to the people which seems to be directly involved with TACAR: Licia Florio (licia@terena.nl) and Diego Lopez (diego.lopez@rediris.es). As soon as I got a response will let you know. On the PMA-side, are they interested in hosting a service like this? -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Dear all, Are we having today the teleconference proposed by Olle? Best 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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
I am missing some of these announcements. I received this message and the ones related to it from Mike Helm, but did not see a request for a teleconference from Olle. The EUGridPMA meeting is in Vienna tomorrow thorough Friday, no? http://eugridpma.org/agenda/fullAgenda.php?ida=a054 (Waiting to hear about tele / video-conferencing support for that one, too!!) Best, Alan On Jan 24, 2006, at 11:18 AM, Jesus Luna wrote:
Dear all, Are we having today the teleconference proposed by Olle?
Best 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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <><>
Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
Jesus Luna writes:
Are we having today the teleconference proposed by Olle?
I don't think anyone set one up; it's not possible for me to do that on travel, altho I could attend one today (w/ difficulty). I could set one up Fri (27) early PT, or next week. My facility will not allow toll-free inbound calling. Thanks, ==mwh
Mike, Even though Friday could be a good day for the teleconference, maybe it should be better for the rest of this week to further elaborate on the CAOPS list about the topics from your previous emails (I hope we can reply them between today and tomorrow) so for the next week we may be able to write an alpha-version of the Proxy Revocation' issues text. In this way the teleconf would be a good point to further refine such text and get it to discussion at the next GGF meeting....sounds like Xmas wish but we think that the document is pretty close to be finished... :) Saludos, Mike Helm wrote:
I don't think anyone set one up; it's not possible for me to do that on travel, altho I could attend one today (w/ difficulty). I could set one up Fri (27) early PT, or next week. My facility will not allow toll-free inbound calling.
Thanks, ==mwh
-- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Did someone ever set a time? If not, I suggest we set something up at www.freeconference.com for Monday, 18:00 UTC. (7pm Central European, 9am Pacific) /Olle -----Original Message----- From: owner-caops-wg@ggf.org [mailto:owner-caops-wg@ggf.org] On Behalf Of Jesus Luna Sent: Tuesday, January 24, 2006 6:58 PM To: helm@fionn.es.net Cc: caops-wg@ggf.org Subject: Re: [caops-wg] Teleconference Mike, Even though Friday could be a good day for the teleconference, maybe it should be better for the rest of this week to further elaborate on the CAOPS list about the topics from your previous emails (I hope we can reply them between today and tomorrow) so for the next week we may be able to write an alpha-version of the Proxy Revocation' issues text. In this way the teleconf would be a good point to further refine such text and get it to discussion at the next GGF meeting....sounds like Xmas wish but we think that the document is pretty close to be finished... :) Saludos, Mike Helm wrote:
I don't think anyone set one up; it's not possible for me to do that on travel, altho I could attend one today (w/ difficulty). I could set one up Fri (27) early PT, or next week. My facility will not allow toll-free inbound calling.
Thanks, ==mwh
-- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
I think that not yet Olle. In any case maybe monday is too soon in spite of the topics raised by Mike's email; anyway we (Oscar and myself) are available next monday on the suggested schedule. BTW, I'll send to the list asap information about our revocation mechanisms & OGRO itself. Olle Mulmo wrote:
Did someone ever set a time?
If not, I suggest we set something up at www.freeconference.com for Monday, 18:00 UTC. (7pm Central European, 9am Pacific)
/Olle
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
On Jan 27, 2006, at 18:18, Mike Helm wrote:
"Olle Mulmo" writes:
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
I think that would have to be 6:00 pm Central European time to be 9 am Pacific: http://www.timeanddate.com/worldclock/meetingtime.html? month=1&day=30&year=2006&p1=0&p2=87&p3=64&p4=224 http://tinyurl.com/apqxu Alan On Jan 29, 2006, at 3:59 PM, Olle Mulmo wrote:
On Jan 27, 2006, at 18:18, Mike Helm wrote:
"Olle Mulmo" writes:
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
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
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.
Trying again... I have rescheduled the slot (same access code, "CAOPS") and will open the line at 08:00 Pacific == 17:00 Central Europe. (Thanks, Alan!) Hope you can manage this earlier starting time despite the late notice. While we're at it, let's schedule a follow-up phone call right away. (If we don't need it, we won't use it.) How does Thursday sound? /Olle On Jan 30, 2006, at 01:54, Mike Helm wrote:
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.
OK for us (Oscar + Jesus) and thursday would be also allright. See you all later ;) Jesus Luna Mensaje citado por Olle Mulmo <mulmo@pdc.kth.se>:
Trying again...
I have rescheduled the slot (same access code, "CAOPS") and will open the line at 08:00 Pacific == 17:00 Central Europe. (Thanks, Alan!)
Hope you can manage this earlier starting time despite the late notice.
While we're at it, let's schedule a follow-up phone call right away. (If we don't need it, we won't use it.) How does Thursday sound?
/Olle
I will try to make it -- will be coming from a local meeting on A&A I am participating in with the local security people here at TTU. Am available Thursday at the same time or later also. Agenda or short list of topics? Thanks, Alan On Jan 30, 2006, at 2:17 AM, Olle Mulmo wrote:
Trying again...
I have rescheduled the slot (same access code, "CAOPS") and will open the line at 08:00 Pacific == 17:00 Central Europe. (Thanks, Alan!)
Hope you can manage this earlier starting time despite the late notice.
While we're at it, let's schedule a follow-up phone call right away. (If we don't need it, we won't use it.) How does Thursday sound?
/Olle
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
I can make this. I have to do this at home today, due to the short notice, & my telephone situation is not the best (my connection will be noisy). Beyond the discussion in email, here are some things I would suggest: Specifying (== "recommending") a format for the AIA URL in conforming CAs Spec a format for proxy registration URL Use the OCSP AIA Add to it Add new extension Describe the possibilities, leave for future standard Do we want to describe details of the registration protocol? No - leave for future standard Yes - just give basic requirements Technical question: how to specify a proxy revocation? I think the answer is, the complete chain from EE -> specific proxy cert Or can we count on specific proxy certs always being different from one another (key, attribute contents, time stamps, &c) so only a representation of the specific cert is needed? I hope so. Describe deployment usage scenarios a little more (as opposed to technical types): caching, local/VO-based, CA-based, clearinghouse Recommend PMA's or large VO's "sponsor" clearinghouse(s)? Recommend clearinghouses support proxy revocation registration? Document: Add a digest of recommendations at the beginning (sections like recommendations for client, for responders, for CAs (particularly), with recs just in bullet or short sentence format) Some minor wording changes (coming) Regards, ==mwh
Hi. Mike Helm wrote:
I can make this. I have to do this at home today, due to the short notice, & my telephone situation is not the best (my connection will be noisy).
Sorry, I hoped I would be able to connect from here (Zagreb), but now it is clear I can not. Will try on Thursday... Regards -- Milan Sova sova@cesnet.cz
Milan Sova writes:
Sorry, I hoped I would be able to connect from here (Zagreb), but now it is clear I can not. Will try on Thursday...
We have (tentatively) agreed to meet again next Monday same time (06 feb 2006 8 AM PT). Details later. I have some sketchy notes which I will post this afternoon.
Hi. Mike Helm wrote:
Milan Sova writes:
Sorry, I hoped I would be able to connect from here (Zagreb), but now it is clear I can not. Will try on Thursday...
We have (tentatively) agreed to meet again next Monday same time (06 feb 2006 8 AM PT). Details later.
Good - this time I should be able to attend ;) Regards -- Milan Sova sova@cesnet.cz
FYI: Dial-in information is same as last week: Dial-in Number: 1-712-432-2323 Participant Access Code 22677 /Olle On Jan 31, 2006, at 00:40, Milan Sova wrote:
Hi. Mike Helm wrote:
Milan Sova writes:
Sorry, I hoped I would be able to connect from here (Zagreb), but now it is clear I can not. Will try on Thursday...
We have (tentatively) agreed to meet again next Monday same time (06 feb 2006 8 AM PT). Details later.
Good - this time I should be able to attend ;)
Regards -- Milan Sova sova@cesnet.cz
Hi. Olle Mulmo wrote, On 30.01.2006 09:17:
Trying again...
I have rescheduled the slot (same access code, "CAOPS") and will open the line at 08:00 Pacific == 17:00 Central Europe. (Thanks, Alan!)
^^ Sorry - missed this particular message when catching up reading my email between trips ;((( -- Milan Sova sova@cesnet.cz
Sorry for the delay, but my afternoon filled up. The notes will be even sketchier as a result. Please fix & fill in as needed. OCSP call 30 Jan 06 8 AM PT Attendees: {?} Oscar, Jesus, mwh, Olle, R Cowles, A Sill - ? AI: Oscar & Jesus will provide some "cons" to Mike's recent suggestions Mike will incorporate recent suggestions, new text from O & L above, and update OCSP draft (+ add digest recommendations and some minor edits as time permits) for Mon 06 Feb (some additions "*" below) Olle will set up another call same time same system (~8AM PT Mon 06 Feb) Decisions: Focus on pros & cons of proxy cert revocation management; it is valuable to make general recommendations but recognize further work and changes will take place Don't develop any extra protocol or related specification for this at this time The general topic of cert validation is out of scope of this document Does anyone have text for the delegated proxy responder cert recommendation? Discussion: Q: is it necessary to revoke proxy certs Owners should revoke only? Gets messy from security pt of f view OCSP gets complicated about registry. * Will post recs/ objections [If I can paraphrase: Oscar & Jesus' point of view is that the user - the holder of the EE X.509 cert - is the real "agent" of proxy cert revocation, and focusing on this person is not too hard, he can be authorized to register & revoke his cert. But allowing the proxy certs to revoke other proxies, and relying parties to do so, this is hard. [Mike: One of the motivations for doing this doc, is that the relying parties want a way to control their environment, they want a tool to limit damage. The proxy cert is not really (or not just) an identity cert, it is developing authorization characteristics, and as such it seems to me at least that both the owner & the resource owner share "jurisdiction" over the proxy in use. [Yes this makes things very messy and we have to make sure the complexity is understood well enough to avoid specifying an unsupportable service.] Terena will disucss OCSP global service? Did Tony talk about at EUGridPMA Just talked about Validity service Stand up large scale ocsp responder? Should we do thru Terena? [Apparently TERENA will discuss this next week? Was there a decision or AI here, I don't remember] [The context here is that we seem to have a consensus that we need one or more large scale, well known OCSP responders to act as clearinghouses, gateways to other responders &c. Some discussion of how to do that/ fund it/ &c - really outside our scope, so:] * Recommend PMA's stand up / support OCSP large scale responder? Let's recommend to PMA; they can worry about practical details, funding, sponsoring Olle - Validation service is 1 level up O: David Groep's suggestion: delegate an OCSP usage as extended signing Management signing Include one more extension on the client side Creates authorized responder OCSP responder can deal with the cert as issued. [That is issue response under multiple certs] Not intended for today's proxy cert [I think I am beginning to understand this ; this was in the slide deck at last GGF (see link earlier message) and must have been mentioned at the previous one, altho I don't remember it. I think the core idea is to create a response from an "Authorized" (see doc) responder for a proxy cert, as opposed to the implied "Trusted" responder response. We should recommend that this capability be developed, but need text to explain it clearly.] [What are proxies? How are they used?] Limit vulnerability Constrained delegation Limited lifetime There are long-lived services - resource brokers O: punting on proxy certs & OCSP M: need it [This section is a return to earlier point, as more ppl got to the call] O: need white/black list Could be complement to OCSP The mess comes from proxy certs revoking proxy certs User could do it. Problem is in rules & how authorized to revoke proxy certificates Primarily it is up to users (Oscar & Jesus). How to move information around? Prepare recs, send Can meet Monday - same time. [Bob Cowles also raised a point ... paraphrase something to the effect of why do proxy revocation as opposed to some other kind of authorization * disabling or user blocking. I said something to the effect of, we can provide a more targeted response, not eliminating a user's ability to do work, just the bad work; particularly important in Grid resources with primitive or minimal authZ infrastructure. I'll check the doc for supporting text.]
participants (8)
-
Alan Sill -
Frank Siebenlist -
Jesus Luna -
jluna＠ac.upc.edu
-
Matt Crawford -
Mike Helm -
Milan Sova -
Olle Mulmo