15th EUGridPMA Meeting, Nicosia, CY
January 26-28, 2009
https://www.eugridpma.org/meetings/2009-01/

Minutes by Jim Basney.

Decisions and Action Items:
* IGTF will ask relying parties to support SHA-256 by Jan 1 2010.
* DFN-SLCS: Issue with CN is pending.
* NetherNordic: Milan and Sajjad are the assigned reviewers.
* PKgrid: DavidG and Ursula will review the self-audit.
* GridKA: Jens and Milan will review the self-audit.
* CALG: This CA is accredited.
* IGTF Charter: Proposed changes to Sections 3 and 3.1 to allow
  namespace overlap among multiple CAs operated by one organization.
  TAGPMA and APGridPMA must review.
* SLCS Profile: Version 2.1.1 is approved by EUGridPMA.
* NIIF: Emir and Christos will review the self-audit.
* CAOPS: Auditing Guidelines going to public comment.  Grid
  Certificate Profile will be resubmitted as a recommendations track
  document. Relying Party Defined Namespace Constraints going to
  working group final call once Jens adds examples.
* DavidG will make a template on the EUGridPMA wiki for sharing
  information about commonly useful software.
* BalticGrid: Emir and DavidG will review the self-audit.
* GridCanada: Moved from EUGridPMA to TAGPMA.
* The following CAs are due for self-audit: SlovakGrid, SIGNET, PolishGrid
* Advice to Globus: The issuer should not need to be amongst the
  allowed subjects in signing_policy files. Don't do the signing
  policy check on self-signed certificates. If you install a trust
  anchor, you trust it.

Minutes:

Andreas Kekkou welcomed us to Nicosia.

David Groep made introductions and found note-takers.
Introductions around the room.
UK eScience report: 
  - 1759 personal certs, 2800+ host certificates
  - 155 RA staff, 70+ RA locations
LIPCA: 439 certificates
DFN: 84 grid RAs, 252 hosted CAs, 40,000 valid EECs

Yoshio Tanaka presented updates from the APGridPMA.

Vinod Rebello presented updates from the TAGPMA.

Jim Basney presented updates from the IGTF RAT.
Should we require CAs to publish their issued certificates?
For purposes of assessing risk.
No, we won't require it for now.
The RAT will send email and ask CAs to audit their own.
The RAT welcomes more volunteers.

David Groep led a discussion of hash algorithm usage.
SHA-1 has known weaknesses similar to MD5 weaknesses.
Need to migrated to SHA-256.
OpenSSL supports SHA-256 as of 0.9.7.
IGTF should send a message to relying parties that CAs will start
using SHA-256 in 2010.
Require RPs to support SHA-256 by Jan 1 2010.

David Groep presented on Web Cacheability of CRLs.
Suggestion: since cron can't vary runtime within a minute, have the
fetch-crl cron job script sleep for up to 60 seconds randomly so that
CRL requests are distributed throughout the minute.

Reimer Kalrsen-Masure presented accreditation slides for the new
DFN-SLCS-CA.
Issue: Does the classic CA signing policy prevent it from issuing in
the SLCS CA namespace?
Some disagreement about whether an organization can have multiple CA
instances with overlapping namespaces. Need to review the charter.
TAGPMA did not allow NCSA MICS/SLCS to have overlapping namespaces.
Does the SLCS profile require subjectAltName email? No.
Did the GridShib CA work out of the box?
Nothing related to Shibboleth works out of the box. :)
Does DFN have any documentation about their setup?
DFN modified the software so it works with their existing system.
DFN added a SOAP CA back-end to GridShib CA.
Where does the name in the certificate subject come from?
It is set by the GridShib CA software, constructed from the attributes
from the identity provider.
How does the GridShib Java Web Start application authenticate?
The credentials are delivered in the JNLP file.
The JWS application writes the short-lived credentials to disk rather
than the browser keystore because they browser keystore would fill up
with expired certificates. It is convenient for grid users to have the
credentials written directly to disk.
The JWS application uses the Globus libraries to store the credentials
in the GSI standard file format and location.
What is the maximum Shibboleth session length?
The important part is the IdP session length.
Switch forces a re-login rather than using the Shibboleth session.
8 hours is a common IdP session lifetime.
Shibboleth 2 can force a re-authentication.
At the moment, DFN is Shibboleth 1 based.
Issue: CN is ePPN (formatted like an email address) which is not an
"appropriate representation of the actual name of the end entity."
DFN AAI doesn't make first name available.
Switch has "CN=First Last ####" and it gets First and Last Names from
the AAI.
DFN will try to get First Name released from Shibboleth IdPs.
RPs members will survey relying parties about relaxing this
requirement.
Issue with AIA extension in certificate.
This is OK by GFD-C.125.
Discussion of namespace overlap among authorities managed by a single
institution.
This is a technical issue with signing policy files not able to
exclude OU=SLCS from the DFN-GridGermany CA namespace.
In the CP/CPS documents, the namespaces are distinct.
The classic DFN-GridGermany CP/CPS specifically excludes OU=SLCS.

Jan Meijer and Henrik Austad presented the NetherNordic SLCS/MICS.
https://slcstest.uninett.no/slcsweb/
Using simpleSAMLphp to talk to IdPs.
Using ePPN as CN. Similar issue to DFN.
MICS requires face-to-face ID vetting whereas SLCS doesn't.
NetherNordic SLCS/MICS will use a vetting attribute to determine if
face-to-face ID vetting has been performed.
MICS requires a second authentication element, whereas SLCS doesn't.
NetherNordic MICS may use SMS messages as the 2nd element.
Plan for 2nd authentication factor not yet decided.
Software: http://www.assembla.com/spaces/confusa/documents
Can we use a designated CRL signer?
Grid software doesn't support it. Shouldn't be needed.
Offline root? Yes, it allows you to revoke the subordinate online CAs.
SLCS and MICS should be two separate CAs.
Reviewers: Milan and Sajjad

Alessandro Usai presented introduced QuoVadis.
Regarding changing the OID in the CP/CPS:
Don't want to change OID of main document every time grid part
changes. The grid part will have its own OID which will change on each
change anywhere in the CP/CPS.
There is some requirement for contracts in the CP/CPS?

Stephen Davidson (QuoVadis) presented via phone the
Policy and Practices in the SWITCH PKI implementation.
CP/CPS updated based on comments from Jens and Reimer.
Jens and Reimer would get more details from the WebTrust audit.

----- Break for the day -----

Sajjad Asghar gave a self audit report-outs for the PK-grid CA.
Is it OK for the audit log to be offline?
Yes. This is an offline CA. The requirements for online CAs do not apply.
Should host certificates provide a dnsName in subjectAltName?
Yes, this is a requirement. PK-grid CA will make this change.
When performing identity verification again after 5 years of renewal
or re-key, should new copies of identity documents be collected?
Yes, if they have changed/expired.
Should invalid requests be recorded in the audit logs?
Yes, even spam to the CA should be archived to meet the letter of the
requirement.
Has anyone reviewed the review?
DavidG and Ursula will review it.

Ursula Epting gave a self audit report-out for the GridKA-CA.
Jens and Milan will review the review.
Is a change to RFC 3647 recommended? This is a lot of work to convert
the existing CP/CPS from RFC 2527 format. This is not required.
If you're re-writing in any case, because of a lot of changes,
then it's good to change to RFC 3647.
Do we need to re-accredit the CA if the CP/CPS changes from RFC 2527
to RFC 3647?
Someone from the PMA should check it, but a full re-review is not
required.
Plan to upgrade to CRL v2. Any issues to expect? No.
These CRL requirements are in RFC 3280/5280.
Old Netscape extensions are deprecated but harmless.
Is objectSign usage allowed? Yes, but not recommended.
Better to make it optional and only enable it if requested.
Will be discussed during Jen's soapbox session.

Alice de Bignicourt gave a self audit report-out for the GRID-FR CA.
Will keep the old CP/CPS format since it avoids a re-review?
This is not desirable...
Alice will post in the new (RFC 3647) format, and we will consider the
re-review non-blocking.
10 countries served as LCG catch-all. These countries are covered by
new CAs.  The RAs should encourage members to use their local
CAs. This is happening.

Dana Ludviga presented CALG CP/CPS updates.
How are service names authenticated? DavidG's CA doesn't authenticate
it. So long as you're authorized to get the certificate for the host,
you're OK.
Recommended to have CN=fqdn rather than CN=host/fqdn.
How to verify possession of the private key?
Proposed a manual process for comparing the requests. Error prone?
Need to compare the RSA public key. OK as is.
Discussion of "post office certificate" compared to government issued
photo ID? Is a review of the post office CA warranted?
OK for the DomainComponent to be IA5STRING. Need to update the CP/CPS.
This CA is accredited.

Discussion of namespace overlap rules according to the IGTF Charter
(http://www.igtf.net/charter.html).
Question of definition of "authority". Is it the CA instance or the
organization that runs the CA. It is the "accredited authority". The
organization is the "PMA member".
Proposal: allow a member that runs multiple CAs to have namespace
  overlaps. Change in Section 3.1. We still have the requirement that
  "every identifier ... is associated with one and only one identity."
Benefits:
- Simpler for users. They have a single DN from the Classic/MICS/SLCS.
  One entry in VOMS and grid-mapfiles rather than multiple.
- Allows users to "upgrade" from SLCS to MICS/Classic (for example).
- Allows users to "downgrade" from MICS/Classic to SLCS (for example,
  if they're away from their computer and need a short-lived
  certificate.
- Simpler for system administrators.
- Allows CA roll-overs.
Issues:
- Makes incident response more difficult. A DN in the logs would not
  map directly to a single CA. If a DN is associated with abuse,
  multiple certificates may need to be revoked across multiple CAs.
- One of the CAs is compromised. Makes others suspect.
- Can't differentiate between them in VOMS? May want to give one admin
  rights and not the other. VOMS can do an issuer check. It is
  configurable in VOMS. Middleware could parse the OID.
Would be very difficult to coordinate/allow overlap between
organizations. This is only feasible in the case one organization runs
multiple CA instances.
In SLCS, the certificate is short-lived but the identity is
long-lived.
If the level of assurance (LOA) is different from SLCS than
MICS/Classic, then do we need to identify them differently?
Require a top-level policy document that describes how you guarantee
uniqueness among all the CAs in the organization.
Shall we allow the same issuer to issue the same DN in SLCS and
Classic but differentiate by only OID? No, the Issuer should also be
different.
The Issuing CA must be uniquely associated with a profile.
Can't have a single authority accredited under multiple APs.
Need a memorandum to the other PMAs for their approval.
Describe the namespace management in each CP/CPS or a separate
document? OK to do it in each CP/CPS so long as they are maintained
consistently.

Review of SLCS 2.1.1 changes.
Switch SLCS CA will implement CRLs in February.
6 month period for requiring CRLs is March 6 2009
(6 months since Lisbon meeting).
EUGridPMA requests Open Science Grid to keep accepting SLCS CAs
without CRLs until that time.
SLCS 2.1.1 is approved.

Dave Kelsey presented an AuthZ WG update.
What are the implications for overlapping DNs in VOMS?
ACs are tied to DNs.
"Revocation of EE cert must stop issue of attributes."
An AA may not see the EEC.
If any service requires authentication, it should check revocation.
Wouldn't allow pull-based AAs.
This requirement needs to be re-worded.
The relying party must check the quality of the chain of certificates.
Should we require that attributes should only be issued after
authentication? If yes, then of course this authentication should
require a CRL check.
Do we want to require the CAs to vet the AAs?
The accrediting body will tell the CA that the AA is OK.
Put "AA:" in CN to distinguish from the host certificate of the AA
service.
Only the "CN=AA:*" certificate would end up in the list of trusted
AAs.
Current draft is on the EUGridPMA wiki.

Tamas Maray gave a self-audit report for the NIIF CA.
Tomas will submit the review documents to the PMA.
Reviewers: Emir and Christos were volunteered.

Jens presented on multiple topics.
Guidelines for reviewing a self-audit needed?
PRQP provides methods for getting CA information.
"Streaker" (stronger and weaker) security.
Discussion of names.
Jim prefers legal names in certificates (person, organization, DNS).
Grid CAs supporting long-lived data encryption?
DFN non-Grid CAs support it, with key escro.
gLite projects using symmetric keys for data encryption.
Discussion of object signing.

Willy asked: is it OK to switch from OpenSSL to BouncyCastle for key
generation? No known problems.

Yoshio Tanaka opened the CAOPS WG session.
Auditing Guidelines document is going to public comment.

DavidG presented an update on the GFD-C.125 grid certificate profile
document.
David O'Callaghan is presenting his compliance suite tomorrow.
CAOPS has moved areas in OGF so it can publish standards documents.
OGF steering committee recommends updating and submitting as a
recommendations track document.

DavidG discussed the Relying Party Defined Namespace Constraints
document.
Relying parties have not provided requirements.
Globus is happy to implement the result.
gLite Java Trust Manager implements namespaces file.
The namespaces file in the IGTF distribution meets the requirements in
this document but is not a standard format.
Will bring it to WG final call.
This is an informational track document.
Document is blocking on Jens writing examples.

----- Break for the day -----

David Groep proposed a wiki repository of "pointers to useful stuff".
~8 people indicated they would be willing to contribute.
Many CAs are using OpenCA, but different/modified versions.
Should it be on a private or public wiki?
Use the EUGridPMA wiki because it is private / requires authentication.
David will make a template.

David O’Callaghan presented on Automated Certificate Checks.
One issue: doesn't distinguish between failing a SHOULD or a MUST.
David showed that many CAs do not meet the requirements.
Some of them say that "no new CA" should do it.
We should do something about this. It doesn't look good.
Currently checking CA certificates.
Also thinking about checking end entity certificates.
https://www.eugridpma.org/cgi-bin/cvsweb.cgi/util/checkcerts/
Could also check certificate requests?
The X509 Perl module can't read requests.
Would be nice to integrate into CAs to test for bad keys before
issuing certificates.

Hardi Teder presented the self-audit of the Baltic Grid CA.
39 certificates revoked because of Debian OpenSSL vulnerability.
Reviewers: Emir and DavidG
Self-audit was helpful.

Which CAs are due for a self-audit? (No self-audit in 3 years or more.)
Austrian Grid CA (Willy Weisz) should have a new CP/CPS in March.
CESNET should have a new CP/CPS soon.
CyGrid CA will present at the next meeting.
Should we retire the Estonian Grid CA? No certificates active.
GridCanada CA is due for an audit. Migrating to TAGPMA? Yes.
PolishGrid is due.
On the critical list: SlovakGrid, SIGNET, PolishGrid, INFN

Discussion of future meetings.
January 2010: DavidO will investigate.
  Tentative Jan 18-20 in Dublin, Ireland.
May 2010: Dana will investigate.
  Tentative May 25-27 or 17-19 in Riga Latvia.
Sep 2010: Emir will investigate.
  Tentative in Zagreb Croatia.

David led a discussion on signing policy files.
Should the issuer be amongst the allowed subjects?
Globus Toolkit 4.2.1 requires that it is.
We have not demanded that the CA name be in the assigned namespace for
end entity certificates.
Globus asked IGTF for advice on this issue.
Concept: If you install a trust anchor, you trust it. Signing policy
files should not apply.
Proposed: Don't do the signing policy check on self-signed
certificates. 
Agreed.

Jens led a discussion on the high-level CA policy.
We're seeing more of these, and also seeing cases where the high-level
CA comes from a different organization from the EEC-issuing CA.
Made edits to requirements and recommendations section.

Thanks to Andreas Kekkou for hosting our meeting!

The End.
