Dear all, We will have a CAOPs session co-located with the EUGridPMA meeting in Nicosia, Cyprus. Although the EUGridPMA meeting is a closed meeting, the CAOPS session will be open to anyone. The session will take place on January 27th (Tuesdasy), from 16:30 to 17:30 Cyprus Time (GMT+2). Here is a proposed agenda: - Relying Party Defined Namespace Constraints - WG last call (David G) - GFD.125 (David G?) - Auditing document (Yoshio) - Agenda of the CAOPs/IGTF Workshop at OGF25 - AOB Here is a guideline of videoconferencing which was sent to the IGTF ML by DavidG: ---------------------------------------------------------------------- The following details should connect all parties to the proper MCU. For direct connections (not using the GDS), enter the conference number using the key pad using the far-end controls, and confirm with the "#" key. Or select it from the menu at the top. Different numbers each day, but the big advantage: NO need to register equipment beforehand. All days: MCU name mcu.surfnet.nl MCU IP 192.87.102.231 On Tuesday Name EUGridPMA 15/2 Start date/time Tue, 27.01.2009 07:00 (UTC) Duration 10h00m H.323 (IP) conference dialin: 0031 801 8215000 Conf no 8215000 ---------------------------------------------------------------------- Sorry for this short notice, but your participation is appreciated. Thanks, -- Yoshio Tanaka (yoshio.tanaka@aist.go.jp) http://ninf.apgrid.org/ http://www.apgridpma.org/
Dear all, Here are decisions made at the meeting.
The session will take place on January 27th (Tuesdasy), from 16:30 to 17:30 Cyprus Time (GMT+2).
Here is a proposed agenda:
- Relying Party Defined Namespace Constraints - WG last call (David G)
Need Jens's example before making a last call. David will upload the latest version on the gridforge.
- GFD.125 (David G?)
We agreed to start processes for making this draft as a recommendation.
- Auditing document (Yoshio)
We agreed to submit this document for public comments.
- Agenda of the CAOPs/IGTF Workshop at OGF25
Yoshio and Christos will discuss this. Any idea/suggestion is appreciated.
- AOB
-- Yoshio Tanaka (yoshio.tanaka@aist.go.jp) http://ninf.apgrid.org/ http://www.apgridpma.org/
Dear all, Dave Kelsey sent me a detailed minute. Thanks, Dave. ---------------------------------------------------------------------- 10. CAOPS-WG Yoshio takes over chair. Auditing Guidelines Document (Yoshio) Went to final call last October, but Christos K initially wanted to make some revisions, but now decided against this. Yoshio will send document to public comment soon. Grid Certificate Profile GFD-C.125 (DavidG) This was released some time ago. David O'C is implementing a compliance-testing suite. Grid Steering Group has suggested the following; test compliance of a number of our CAs make some needed changes and re-submit as a technical recommendation. All agree. Relying Party Defined Namespace Constraints Policy document. (DavidG) Been around since 2005. Defines why we need a signing policy file and a list of requirements for such a policy language. DavidG goes through list of requirements. Reimer asks about negative conditions on branches of the namespace tree (like the need we discussed yesterday to exclude "ou=SLCS". They seem to be missing right now. Add these exclusions. Jens points out he was going to write some examples. He still plans to do this. The date of the requirements poll should also be dropped. Aim for public comment before OGF25. 3 sessions have been requested for CAOPS and IGTF in OGF25. ---------------------------------------------------------------------- -- Yoshio Tanaka (yoshio.tanaka@aist.go.jp) http://ninf.apgrid.org/ http://www.apgridpma.org/ From: Yoshio Tanaka <yoshio.tanaka@aist.go.jp> Subject: Re: [caops-wg] CAOPs Teleconference Date: Wed, 28 Jan 2009 00:53:52 +0900 (JST) Message-ID: <20090128.005352.127768346.yoshio.tanaka@aist.go.jp>
Dear all,
Here are decisions made at the meeting.
The session will take place on January 27th (Tuesdasy), from 16:30 to 17:30 Cyprus Time (GMT+2).
Here is a proposed agenda:
- Relying Party Defined Namespace Constraints - WG last call (David G)
Need Jens's example before making a last call. David will upload the latest version on the gridforge.
- GFD.125 (David G?)
We agreed to start processes for making this draft as a recommendation.
- Auditing document (Yoshio)
We agreed to submit this document for public comments.
- Agenda of the CAOPs/IGTF Workshop at OGF25
Yoshio and Christos will discuss this. Any idea/suggestion is appreciated.
- AOB
-- Yoshio Tanaka (yoshio.tanaka@aist.go.jp) http://ninf.apgrid.org/ http://www.apgridpma.org/ -- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
I am a little puzzled by the statements in section 3.2.3 commonName of GFD125. "For certificates issued to networked entities, typically the (primary) FQDN of the server is included in the commonName. For regular network entity certificates, there MUST NOT be any additional characters in the commonName[25]. [25]Some components of some grid middleware also recognize Kerberos-style 'service' names in the CN as well that look like 'servicename/fqdn'. In the majority of the cases, a normal server certificate without the 'servicename/'-qualifier can be used as well – although the documentation of the middleware will not always state that clearly. It is recommended to phase out the 'servicename/'-qualifiers where possible." This seems to take the point of view that there is only a single network entity running a a given host, when there can be many network entities on one host, bound to different ports and with different people responsible for administering them. I would think it is a better strategy to encourage the use of 'servicename' qualifiers in the CN for different entities on the same host and then require the use of DNSName in SubjectAltName for those people that want to check an FQDN. I think it is clearly NOT a good idea to force the reuse of a single host certificate for many different services running on that host. In this case you either have all those services running in the same UID, or you make multiple copies of the host private key, OR issue multiple certificates with the same CN that are used for different entities (policy violation). Doug
Doug Olson writes:
This seems to take the point of view that there is only a single network entity running a a given host, when there can be many network entities
The only network entity that ssl/tls can really distinguish is the host itself, not the applications running on it. Even that is not quite the right way to put this. Thanks, ==mwh
On 6/25/2009 3:04 PM, Mike Helm wrote:
Doug Olson writes:
This seems to take the point of view that there is only a single network entity running a a given host, when there can be many network entities
The only network entity that ssl/tls can really distinguish is the host itself, not the applications running on it. Even that is not quite the right way to put this. Thanks, ==mwh
The SSL layer is using whatever server certificate the application presents. Different applications should use different certificates. Doug
Doug Olson writes:
The only network entity that ssl/tls can really distinguish is the host itself, not the applications running on it. Even that is not quite the right way
The SSL layer is using whatever server certificate the application presents. Different applications should use different certificates.
There's no problem with that that I know of. SSL/TLS and the Grid gssapi variant has certain issues that have to be addressed, that's all. Thanks, ==mwh
On 6/25/2009 4:34 PM, Mike Helm wrote:
Doug Olson writes:
The only network entity that ssl/tls can really distinguish is the host itself, not the applications running on it. Even that is not quite the right way
The SSL layer is using whatever server certificate the application presents. Different applications should use different certificates.
There's no problem with that that I know of. SSL/TLS and the Grid gssapi variant has certain issues that have to be addressed, that's all.
The problem comes from having a recommendation that the CN is only the FQDN but also having several different server certificates issued for different applications (with different people responsible) all with the same subjectname. I am saying the recommendation in GFD125 should be changed. Doug
Hi, Doug Olson wrote on 26.06.2009 01:58:
On 6/25/2009 4:34 PM, Mike Helm wrote:
Doug Olson writes:
The only network entity that ssl/tls can really distinguish is the host itself, not the applications running on it. Even that is not quite the right way
The SSL layer is using whatever server certificate the application presents. Different applications should use different certificates.
There's no problem with that that I know of. SSL/TLS and the Grid gssapi variant has certain issues that have to be addressed, that's all.
The problem comes from having a recommendation that the CN is only the FQDN but also having several different server certificates issued for different applications (with different people responsible) all with the same subjectname.
the CN might be identical but how about looking at the full sDN, ie putting in the proper OUs or using Grid-service specific DNS aliases for the same machine or multiple IP# on the same machine to distinguish the services/certificates if it can't be done by OUs. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: <https://www.pki.dfn.de/faqpki> -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-580 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
participants (4)
-
Doug Olson -
Mike Helm -
Reimer Karlsen-Masur, DFN-CERT -
Yoshio Tanaka