Modular+Specs+Certificate+Discovery+Feedback

include component="page" wikiName="siframework" page="ModularSpecTabs" This page is where ONC and ProjectTeam members will respond to comments on the final artifacts posted from Modular Specification Pilot Phase 3. Although this is correct, the use of either LDAP or DNS is required meaning the HISP can choose either DNS or LDAP to host certificates. The statement in the document appears to imply that a HISP must use DNS to host certificates and may choose to use LDAP as well. I didn't find anything in the document that clarified that HISP needs to choose one certificate server implementation. It might also be worth clarifiying that although a HISP can use one method or the other to host certificates, a client MUST support resolving certificates using both DNS and LDAP. || TI Team: Clarified and will be updated ||  || using only one DNS query when if fact the DNS server will only respond with user level certificate for full email addresses and or level. certificates for queries that only contain the domain. Although this is clarified in a separate section, I would consider rewording this paragraph. || TI Team: Clarified and will be updated ||  || process. || TI Team: Clarified and will be updated ||  || (although it should be out of scope as to what constitutes a "valid" certificate or reference the applicability statement or policy guidance from another source) after a certificate is resolved. If the certificate is determined to be "invalid", then the next step in discovery commences. Item 2) should probably state something similar as well. || Certificate validity is out of scope for this architecture. ||  || workgroup purposely chose not to enumerate the use cases of certificate validity and only made reference to artifacts from other workgroups and/or policy agencies. || Certificate validity is out of scope. ||   || and does not provide any additional value over what is outlined in the risk mitigation document. || Removed ||   || are issue for DNS certificate discovery. ||   ||   || are extensible and could be integrated into user or organizational identify proofing and certificate issuance workflow. || Clarified ||   || discovery to be dynamic. || Need further guidance on this. ||   || not a recommendation. || Removed from recommendations. ||   ||
 * ~ Date Submitted ||~ ID Number ||~ From ||~ Issue ||~ Response ||~ Status ||
 * || 7.1 Scenario || Direct-Certificate-Discovery-TechnicalArch || The scenario mentions " The use of LDAP server is optional"
 * || 7.1 Scenario || Direct-Certificate-Discovery-TechnicalArch || The 6th paragraph implies that the DNS server will respond with either the user level certificate or the org level certificate
 * || 7.2 High Level... || Direct-Certificate-Discovery-TechnicalArch || Section 1a outlines querying for the user level certificate first, then the org level certificate next. Section 1b should follow this same
 * || 7.2 High Level... || Direct-Certificate-Discovery-TechnicalArch || The parenthesize header of 1b) should probably read "if no valid certificates are found in step 1a". There is a step of certificate validation
 * || 7.3 Assumptions || Direct-Certificate-Discovery-TechnicalArch || Item 3 should fall into the category of certificate validity. Is certificate validation in scope for Mod Spec Phase 3? The S&I framework
 * || 7.3 Assumptions || Direct-Certificate-Discovery-TechnicalArch || Is item 4 giving guidance as to how a HISP should implement their LDAP services? What exactly does "split" imply? || Test implementation does not provide guidance on how HISPs may implement their LDAP services. This assumption has been removed. ||  ||
 * || 7.3 Assumptions || Direct-Certificate-Discovery-TechnicalArch || In item 5, could you give more context to "single" service? Does this mean only one publicly exposed URL or that entries will not use "references" to other LDAP services? || Removed. ||  ||
 * || 7.3 Assumptions || Direct-Certificate-Discovery-TechnicalArch || Item 8 has gone through rigorous scrutiny by multiple Direct workgroups over the last 18 months, and the consensus is that SSL is not necessary
 * || 7.3 Assumptions || Direct-Certificate-Discovery-TechnicalArch || Item 9 builds on top of item 8. White listing is against the grain of the Direct certificate discovery philosophy. || Removed ||  ||
 * || 8.1 Steps || Direct-Certificate-Discovery-TechnicalArch || Section 7 and its subsections do not describe the user level vs org level certificate queries. The same sequence of user/org level queries are issued for LDAP that
 * || 10 Risks || Direct-Certificate-Discovery-TechnicalArch || Section 2 under DNS is specific to the DNS implementation. Although the use of large zone files is probably generally true, some DNS servers
 * || 10 Risks || Direct-Certificate-Discovery-TechnicalArch || Section 2 under LDAO could be true for almost any type of service including DNS. ||  ||   ||
 * || 10 Risks || Direct-Certificate-Discovery-TechnicalArch || "//DNS by default is public. That makes it vulnerable to threats such as spoofing."//
 * What does “is public by default" mean?
 * Spoofing attacks within Direct are handled with anchor trust exchange.
 * I don't follow as this statement is essentially saying DNS is not suitable for this use.
 * I suggest clarifying or removing this statement. || Removed. ||  ||
 * || 10 Risks || Direct-Certificate-Discovery-TechnicalArch || //"Certificate entries must be manually added to a DNS server’s zone file. These are large text based records. This could present a sustainability concern for large HISPs that deal with hundreds of other providers/HIEs/HISPs."//
 * I disagree with this.
 * The data format of DNS records in one implementation and the management interfaces to store/load records have nothing to do with the risk of DNS being used for large scale directory services.
 * Organizations are hosting massive scale records in DNS today and this powers the internet worldwide.
 * There’s no question that DNS is currently the single largest directory access protocol in use on the planet so where is the sustainability concern coming from?
 * This statement needs backing or clarification. || This has been clarified. ||  ||
 * || 11 Recommendations || Direct-Certificate-Discovery-TechnicalArch || Section 2. As state previously, the Direct workgroups have determined that SSL provides little value for certificate discovery. || This has been addressed in the previous concern. ||  ||
 * || 11 Recommendations || Direct-Certificate-Discovery-TechnicalArch || Section 3. This needs to be reviewed. One of the value propositions of using public services is to reduce maintenance and configuration and allow certificate
 * || 11 Recommendations || Direct-Certificate-Discovery-TechnicalArch || Does section 4 need to be a recommendation as it is already explicitly stated in section 5.4 of the applicability statement? This should be a MUST,