**MACE Call 12-April-2010**

**Attending**

Ken Klingenstein, Internet2 (stand-in chair)

Jim Jokl, U. Virginia (discussion leader)

Rodney McDuff, U. Queensland

Paul Hill, MIT

Diego Lopez, RedIRIS

Michael Gettes, MIT

Scott Cantor, The Ohio State U.

Mark Poepping, CMU

Keith Hazelton, U. Wisconsin - Madison

Ann West, Internet2

David Wasley, independent

Renee Shuey, Penn State U.

Scotty Logan, Stanford U.

Renee Frost, Internet2

Steve Olshansky, Internet2 (scribe)

**New Action Items**

[AI] (All) Send input to Ken about how this service ought to be packaged - i.e. amendment to existing InCommon contract, or other.

*Carryover Action Items*

[AI] (Ken) will revise the mission statement based upon feedback received on the call.

[AI] (Ken) will send out info on DHS secure online transactions

[AI] (Ken) will follow up on a MACE/AMSAC call.

[AI] (Ken) will follow up with Kuali/Rice about I2MI collaboration.

[AI] (Ken) will draft a catalyst doc, covering the key items to be addressed in advising VOs how to use our infrastructure.

[AI] (Leif) will contact Ken/Steven/Tom about potential overlaps between the SDCI proposal and projects in the EU.

[AI] (Leif) will discuss the IDTrust meeting on the PKNG list, seeking feedback.

[AI] (Jens) will speak to an Eduroam rep about communicating with Educause.

[AI] (Ken) will draft and circulate a letter to Rice leadership, requesting input to roadmaps and use cases, and to ensure our projects with Kuali projects are aligned with their high-level strategic direction.

[AI] (Nate) will distribute information to the list about upcoming tactical issues facing MACE

[AI] (All) send Bamboo IAM comments to Tom ASAP for coordination.

[AI] (All) interested in participating in the international collaboration activity contact RL "Bob."

[AI] (RL "Bob") will contact a representative of Kuali Rice about coordinating a call.

[AI] (Ken and Mark) will distribute some information on trust anchors in the context of dynamic network configuration in GENI testbed, as well as for general access control.

[AI] (Ken) will circulate some meeting notes from the last TERENA/ REFEDS meetings.

**Discussion**

The discussion focused on the upcoming InCommon cert service, which will include both server certs (not being discussed today), and end-user certs. The goal is to announce this at the upcoming Spring I2MM.

It was noted that the structure of the offering (e.g. subscription? amendment to existing participation agreement?) may affect whether institutions will need to issue an RFP or just go with a sole-source arrangement.

Cert mobility could be a challenge, as some clients only support a single signing cert, as could revocation.

It is uncertain whether these certs could be used for grid/TeraGrid authn, i.e. whether they would be accepted (not whether the provider would allow their use for this). There will be no limitation imposed on how these certs can be used. Thus it is up to the RP to make the decision as to whether they are acceptable for any particular use.

Workflow via e-mail was discussed early on as a potential use case, but it is unknown if that will gain any traction.

Q: Is a code-signing cert equivalent to a mail signing cert?

A: No, there are differences particular to the specific application.

Q: Are signing certs usable as authn certs?

A: Yes, they could be used for both

Q: Are there any limitations to the number of certs assigned to an individual?

A: One valid e-mail address per cert.

Q: Cert mobility - can a single cert be used from multiple clients?

A: Perhaps, but the challenge will be in the specific client implementation...

Q: Can this be used for encryption?

A: This will require a modification of the cert, but is feasible depending upon the specific situation and app capabilities. Many clients will accept different certs for signing and encryption, but if one doesn't support this then this is a problem. Escrow would be necessary for obvious reasons. Attacks on the escrow system would become very attractive - a significant potential vulnerability.

Q: How will certs be provisioned?

A: Presumably through an InCommon web interface for authorized users, relying upon the existing vetting processes at a high level but unclear for the general user populations. It could be as simple as allowing any user from a participant IdP (i.e. able to demonstrate affiliation) to obtain one with a simple e-mail handshake... It could also be combined with the photo-ID identity proofing process for incoming students.

It was observed that keeping the personal cert offering simple, especially initially, will be important for encouraging adoption. I.e. not dwelling too much publicly on potential sticky questions as to usage and process for the signing certs. Where should the more detailed conversations take place? It was proposed that reviving HEPKI-TAG may be the right venue. Or an InCommon-participants working group? Given the goal of promoting InCommon, the latter is the more likely answer. Determining the right folks to participate in these discussions could be a challenge. This service will very likely bring different kinds of participant into InCommon, some of which may not be inclined to pursue IdM initially.

It was proposed that there are potentially multiple discussions to be had within InCommon participants, including:

- basic SSL cert usage (is this really needed?)

- personal cert usage and policy discussion

A BoF at the Spring I2MM was proposed as a useful venue. There is already a breakfast session planned April 28 7:30-8:30 AM, but perhaps this could morph into a more interactive session:

http://events.internet2.edu/2010/spring-mm/agenda.cfm?go=session&id=10001231&event=910

The question of cert LoA arose, and this will depend upon the issuance process. This could utilize different CAs.

Discussion turned to intra- v. inter-institutional use. It was observed that if it is a hard sell to use these within the organization, it might not bode well for inter-organizational use.

Q: For inter-institutional e-mail, will there be liability issues to confront?
A: Unclear at this point.

**Question MACE would like an answer for:

Q: Will wildcard server certs be offered?

A: Yes, but unclear whether there will be pricing accordingly.