Agenda

  • (David Kibbe, co-chair) - Brief summary of current work and status of consensus vote on Direct Ecosystem Community X.509 Certificate Policy.
  • (Arien Malec, co-chair) - Review of Version 0.6 changes to Direct Ecosystem Community X.509 Certificate Policy made in response to comments.
  • (Greg Chittim, secretary) - Discussion round for additional comments and clarifications from members.
  • (All members) - Discussion round next steps and action items. (Contingent on time availability).

Attendees
  • PRESENT
  • Alice Nyberg
  • Andy Hereen
  • Brett Peterson
  • Bruce Schreiber
  • David McCallie
  • Don Jorgenson
  • Greg Meyer
  • John Odden
  • John Williams
  • Melissa Manning
  • Pete Palmer
  • Sri Koka
  • Arien Malec
  • David Kibbe
  • Greg Chittim
  • ABSENT
  • Adrian Gropper
  • Brian Ahier
  • Brian Hoffman
  • Chris Moyer
  • Colin Barry
  • Gary Christensen
  • Mark Gingrich
  • Mark Stine
  • Noam Arzt
  • Pat Pyette
  • Sean Nolan
  • Steve Waldren
  • Umesh Madan
  • Vince Lewis
  • Will Ross

Notes

  • (David Kibbe, co-chair) - Brief summary of current work and status of consensus vote on Direct Ecosystem Community X.509 Certificate Policy.
    • o Many thanks to Brett Peterson for all his work on the CP
    • o Welcome to Arien, who all know, and is back in the private sector again
  • (Arien Malec, co-chair) - Review of Version 0.6 changes to Direct Ecosystem Community X.509 Certificate Policy made in response to comments.
    • o From v0.5 to v0.6
      • § Mostly pointed, targeted, that don’t address the *overall* policy
      • § 4.5.1 – from approved applications to not allowing unauthorized parties
      • § 3.2.3.1 – removed specific requirement around notary public. Inserted more flexible language from FBCA for medium level of assurance, making notary an option not a requirement
      • § 3.1.5 – global name uniqueness – we mean within the CA – CA shouldn’t be issuing duplicate certs for the same organization or individual
      • § 3.2.6 – may take this exact CP, or an “equivalent” as deemed by DirectTrust.org
      • § 4.2.3 – made language consistent with 3.2.3
      • § 5.1.2 – Physical access – removed requirement for keycard access, made less strict
      • § Changed version numbers and dates
      • o Comments/concerns/questions
        • § John Odden – do we do wordsmith now”?
          • Arien – later
          • Question and discussion in in-person antecedent
          • § David Kibbe – how does this interact with the Real ID act?
            • You’re okay with a passport, or a driver’s license + a backup form
            • Arien - The 3.2.3.1 language was stolen from the FBCA CP, so would prefer to keep it consistent than spending a lot of time improving it. Many of the Real ID issues might be covered by the antecedent clause
            • Do we think about pointing some language to the FBCA CP?
            • David McCallie – assume a cert is bound to the CP at the time it was issued, so pointers to other CPs probably don’t make sense
            • § David McCallie - Should the CP refer to certificate discovery at all?
              • 2.1.1 - change to “no stipulation”
              • Removing other references to DNS as well
        • o Arien – potentially unaddressed comments:
          • § Bruce Schreiber
            • - Private Key concerns:
              If the hisp manages the private key, how strong and consistent is the individual authentication.
              Alternatively, can a user or provider properly guard and maintain a private key on an individual level?
              • o Out of scope for this document
              • - Certificate Discovery concerns
                BIND as offered in CPANEL, or the Rackspace Portal or Godaddy Portal do not support CERT records at this time. Is there an alternative TXT record format that can be acceptable?
                There has been talk of using SRV records pointing at LDAP servers. That could be included here as well as a reference to an LDAP implementation
                standard.
                • o Reference implementations handle this. NS record points to the subdomain for which you’re managing organizational identity.
                • When is the domain only cert acceptable versus the individual cert? Is that a responsibility of the sender or is there a policy?
                  • o This is a relying party decision, probably out of scope for CP
            • § Don Jorgenson
              • - The Direct Ecosystem CP seems to anticipate a DirectTrust.org CA compliance process that largely duplicates that required by the FBCA. Why not include FBCA requirements by reference and focus on the Direct specific requirements? If FBCA compliance becomes a requirement, the Direct Ecosystem CP could be specified and maintained by DirectTrust.org without the necessity of establishing a separate enforcement infrastructure. FBCA required audits could be extended to cover Direct Ecosystem CP compliance.
                • o Need something like this for a while, as FBCA does not address org identity at all.
                • - In the FBCA CP, CAs designate their own RAs and are responsible for their compliance with the CP—why not follow that model? (Sect. 1)
                  • o CP should not prevent this. Don to review language to ensure that it doesn’t.
  • (Greg Chittim, secretary) - Discussion round for additional comments and clarifications from members.
  • (All members) - Discussion round next steps and action items. (Contingent on time availability).
    • o We’re going to be very close in v0.7
      • § Arien to fix reference to DNS and other changes discussed
      • § Major issues are around governance process for DirectTrust.org. Should likely be more general, but still allow for the org. Don, Gary, Greg to take a swing at this to describe functionally instead of organizationally.
      • § After these, we should be able to finalize consensus next week and get to 1.0