- caops-wg - lists.ogf.org

OCSP section 2
by Olle Mulmo 03 Jun '05

03 Jun '05

> * In section 2 (former section 3) the following text was removed: > "Grid’s Virtual Organizations may contain more than one CA, so > establishment of OCSP Authorized Responders between them is essential > to provide an interoperable service." When we proposed such change we > were thinking in the importance of highlighting the co-existence of > multiples CAs into the same VO as a practical challenge for Grid OCSP. > What do you think? I don't understand what this text is aiming at. Is it only to establish the fact that we operate in an environment with multiple trust anchors and that these need to be federated through e.g. a PMA, or is there something else between the lines? "Authorized responders between them"... are you thinking of some cross-certification / bridge scenario? /Olle

2 1

OCSP - use of nonce
by Olle Mulmo 02 Jun '05

02 Jun '05

> There are a couple of remarks about nonces that I think the > sophisticated security worker - especially some of the ones I was > hoping to interest in this service - would not agree to. I have no > problem with the language in 4.5 but the client recommendation > somewhere in section 7 just says flat out don't do it -- seems > contradictory. There are circumstances where real time is needed. We > need a nuanced nonce instead. The intended spirit of Section 7 was to say don't do it -- by default. Your suggested modifications below will be incorporated. > > In 7.3, say > OCSP clients are not recommended to include nonces except ... - or - > OCSP clients should only include nonces ... in requests to local > Trusted responders or other OCSP responders by prior agreement and > consultation. (See section 4.5.) > > In 4.5 say > Some services may not support nonce requests, and in other cases it > may produce intolerable burden on the OCSP responder and delay for the > client application. Nonces should only be used in situations where > the most up to date information is required, particularly to meet > security requirements. > > [Drop the "overkill" sentence - not useful.]

2 1

OCSP document - proxies and delta CRLs
by Olle Mulmo 31 May '05

31 May '05

> * Page 7, section 5.5: the paragraph suggesting the use of Delta CRLs > to obtain Proxy Certificate´s status has been deleted ("Another option > refers to using OCSP in a Push Operation Mode as mentioned in section > 6.3, where relying parties SHOULD obtain revocation information > through its OCSP service provider as soon as it is updated by the > corresponding CA through Delta-CRLs"). Only as a way to let the reader > know about this possibility, don't you think that it is worth to keep? For an EE to "register" a proxy certificate with an OCSP responder, we will require a protocol, and/or extensions to an existing protocol. Why cannot the "disabling" of a previously registered proxy cert use the same channel? The two operations are about making changes to the responder's revocation database, so for me it makes sense to have them tightly coupled. I don't rule out the use of Delta CRLs, but a Delta must be built relative to a full CRL, which must be referenced. What is the full CRL of an EE? In addition, support would have to be added in the responder validation routines to allow EE (or proxies thereof?) certs to sign CRLs. Overall, this smells too much of a hack to me. /Olle

1 0

OCSP section 5.1 - key protection
by Olle Mulmo 31 May '05

31 May '05

> *5.1 > While we do not require the use of hardware protection, > we RECOMMEND that the security of the OCSP responder key > be in parity with the CA issuing key. > > [This is a meaningless recommendation, because we have no single > standard for CA issuing keys. Also, there are differences in the > way OCSP and CA issuers are handled - you can change the OCSP > key pair every hour if you want. Disagree about HSM. Reading the text again, I realize that I had Authorized responders in mind. What the text says is that there should some correlation between how securely you operate your CA, and how securely you provide current status of those certificates. This comment should be expanded and moved elsewhere. I have no problems adding your suggested text: > Access to OCSP responder keys must be carefully controlled. > In all cases system level access to OCSP responder systems must > be limited and logged. Access to key backup media must also > be limited and logged. For OCSP responders using software crypto > stores, we recommend that this key NOT be backed up. We also > recommend the key be changed more frequently than end user signing > keys. > These steps can reduce but not eliminate the demand for hardware > crypto stores; hardware security modules should be used for high > visibilty OCSP responders (see also prev paragraph?). > Service providers should also consider transponder configurations > to reduce the number of highly secured OCSP responder keys needed.

1 0

Separating the OCSP doc comments into separate threads -- watch out!
by Olle Mulmo 31 May '05

31 May '05

1 0

OCSP requirements - final(?) version uploaded
by Olle Mulmo 27 May '05

27 May '05

All, I cleaned up the document and resolved some of the outstanding issues. Tracking was too hard to keep around (too many changes) so I removed those. Note that document submission for GGF14 is tomorrow. I would request that the members of this list read through the document NOW (yes, prior to the meeting), and bring up any comments on the document on this list, ideally so that we can go to GGF14 with the document in WG last call. The document can be obtained at https://forge.gridforum.org/projects/caops-wg/document/ OCSP_requirements_for_Grids/en/1 A PDF rendering is attached for your convenience. /Olle

4 3

FYI: The GGF security area list is not working
by Olle Mulmo 27 May '05

27 May '05

FYI, A number of messages have been sent to security-area(a)ggf.org in the past day(s) without getting delivered. The systems people are currently looking at the problem. In the meanwhile, may we do some PR for two new groups that now have their mailing lists up and running: Firewall Interest (fi-rg) and Trusted Computing (tc-rg). To subscribe to these lists, send mail to majordomo(a)ggf.org with one or both of the following lines in the message body: subscribe fi-rg subscribe tc-rg Hope to see many of you in Chicago, Olle & Dane

1 0

RE: RV: [caops-wg] Re: Grid OCSP proposal
by Oscar Manso 09 May '05

09 May '05

Olle Mulmo wrote: > To avoid confusion: Please make use of proper terminology when such is > defined (for once). OK, in fact we are attaching a corrected version of the working document that includes a section called "Definitions", precisely to use a common technical vocabulary. Also according to our last email, we've deleted references to the "OCSP Extensions" proposal. > > The proper name for the "trust chaining" scenario is called > "Authorized responder", and the authorization is marked by the CA via > the inclusion of the ocsp-signing extended key usage. Thanks, we've already included this in the "Definitions" section. > [...] > > One responder being authorized by multiple CAs is a perfectly legal > and reasonably common mode of operation. I know of at least one > commercial software (the one that I wrote...) that supports both the > case of all CAs signing a single key pair, and the responder having > multiple signing keys simultaneously, selecting the appropriate on > depending on which certificate that status is requested for. We agree, it is also the same implementation that we've done at CertiVeR. > > /Olle Best regards, Jesus & Oscar.

3 2

[Fwd: [permis-users] GT4-PERMIS integration is complete]
by David Chadwick 08 Apr '05

08 Apr '05

-------- Original Message -------- Subject: [permis-users] GT4-PERMIS integration is complete Date: Fri, 08 Apr 2005 17:02:58 +0100 From: Sassa <o.otenko(a)kent.ac.uk> To: permis-users(a)kent.ac.uk, permis-dev(a)kent.ac.uk Dear PERMIS users, now PERMIS can be integrated with GT4. It can operate as a GT4 PDP (like the Authorisation Handler in GT3.4), or as an authorisation service (the GT4 port of the GT3.4 PERMIS SAML Authorisation service). Please, see our website for installation instructions. http://sec.cs.kent.ac.uk/permis/ http://sec.cs.kent.ac.uk/permis/GT4Cookbook.html Questions are welcome in private or to the list. Regards, Sassa -- ***************************************************************** PLEASE NOTE NEW CONTACT DETAILS AS OF 1 JAN 2005 David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NZ Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

RV: [caops-wg] Re: Grid OCSP proposal
by Oscar Manso 17 Mar '05

17 Mar '05

Dear all, Our suggestion to introduce information in the form of OCSP Extensions was raised because we understand that through the use of such mechanism the Validation Authority could provide dynamic information that could be useful in order to take validation decisions. We were thinking of an optional mechanism served on demand provided through OCSP. On his last email, Mike mentions other protocols that probably will be more adequate to convey such type of information. At this time we are working on a GT4 pilot that uses OCSP Extensions as proposed and we expect to present you some results soon. On the mean time, we understand that there is no need to discuss further the introduction of OCSP extensions in this document in order not to delay its publication. However, given the fact that the subject has been raised and that Mila has already made some useful comments we would like to comment on them. Milan Sova wrote: > If I understand you correctly, you want to introduce a new > extension to express the "freshness" of the status information. I'd > stay with the crlTime field of the CRLreference extension and let the > relying party make the decision based on the exact time. Or am I > missing your point? > > > Isn't reasonCode extension capable of providing this information? Mila, we agree with your comments. The information proposed can already be conveyed using the standard protocol. Maybe we didn't pick the right examples... but that does not mean that the extension mechanism can not convey useful information such as the CA-related attributes mentioned in our previous message. > > I don't think so. The relying party should decide by itself how > much trust it gives to any particular CA and their requirements may > differ. I can hardly imagine how could the OCSP service know about the > level of trust every relying party has towards every CA. Of course that it is up to the relying party to decide by itself whether to trust or not a CA. Our suggestion here is that, given the fact that for the relying party may be difficult to have information about all the CAs that can be trusted, the VA could certify (by means of several external and independent audits) the security policies established by each CA reporting such information to the relying party. > Moreover this goes against the principle of authentication and > authorization separation and IMHO could not be considered a good > practice. Agree with you for several reasons (performace above all) as the AuthZ decision shall be better taken by an AuthZ Service acting separated from the AuthN subsystem. However our point here is that as both AuthN and AuthZ processes are linked in such a way -depending on the AuthZ model being implemented- that the output from one of them is used as the input of the other; then the AuthZ Decision process may benefit itself from information purely related to the AuthN process, maybe by retrieving CA-related attributes or any other attribute considered to be adequate by the relying parties. The main purpose of these attributes is to match them against the AuthZ Policy Rules just as any other user attributes so that a final decision can be obtained. Notice that once these attributes have been received - at Proxy initialization time - no further retrieving is necessary by the AuthZ Service and according to our first results, performance is not diminished and overall security level is enhanced. > > Sorry, I don't see the connection to trust chaining (perhaps we > differ in understanding the term). Could you explain your view, please? We're interpreting "Trust Chaining" not in the sense of providing transitive trust relationships between two EECs through mechanisms like cross-certification, but instead -as mentioned on the note in page 10 just before section 7.1 of the working document- by creating a one-way trust relation between a relying party and a CA (Relying Party -> OCSP Responder -> CA) by signing the OCSP Response with a private key which correspondent Public Key Certificate has been issued by such hierarchy. The only condition is that this keypair must be the same for every configured CA on the OCSP Responder (same certificate request for every OCSP Signing Certificate being requested). In practice it means that no additional overhead is produced with this solution as OCSP Response signatures are created with the same private key. Maybe it's not "Trust Chaining" in the broad sense of the word as the Trust Relation is one-way only , but we hope that the idea is clearer now... Anyway let us know any question :) > Regards Oscar & Jesús

3 2