Google Trust Services (GTS) reached out to Wayne directly, but I'm also posting here as the conversation seems to be rapidly converging on solutions. GTS still has reservations that the proposed solutions may be problematic to implement and may leave a number of CAs and one very common CA vendor in a bind to get from their current state to whatever the final state is cleanly. While Mozilla's requirements and recommendations are not strictly binding, they carry a great deal of weight and could lead to rapid implementation of a sub-standard solution.
Google Trust Services would like to see the current precertificate 'requirements' moved to the 'recommendations' section with a note explaining that once the formal details are worked out via bylaw changes (preferably) or further discussion on m.d.s.p (if bylaw changes are deemed too slow), they will become requirements. Sorry to post late in the process like this. Unfortunately, as a globally distributed team within a much larger company, Google Trust Services team cannot always move and post as quickly as we'd like. We will follow-up early next week with more details about our concerns, but there are a number of complex interactions and subtly conflicting requirements that seem best served by taking the time to ensure the final state is settled on in haste. It would be great to achieve consistency sooner than later, so a time bounded window to get there seems best to balance convergence versus a rush to decisions that may adversely affect the ecosystem or be a challenge to live with for years. -- Andy Warner Google Trust Services On Friday, September 20, 2019 at 1:20:02 PM UTC-7, Curt Spann wrote: > This is a great discussion and I want to thank everyone for their continued > input. Let me try and summarize my interpretation based on the input from > this thread and related RFC. > > My interpretation is an “unknown” OCSP response should be used in the > following conditions: > 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for > which the OCSP responder is NOT authoritative (wrong issuing CA). > 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for > which the OCSP responder IS authoritative (correct issuing CA) but for > whatever reason the OCSP responder does not know the status of the requested > certificates and ONLY if the certificate for which the status is requested > contains another OCSP responder URL available in the AIA extension. > > My interpretation is a “revoked” OCSP response should be used in the > following conditions: > 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for > which the OCSP responder IS authoritative and the requested certificate has > been revoked. > 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for > which the OCSP responder IS authoritative and the CA corresponding to the > issuerNameHash and issuerKeyHash has been revoked. > 3. When the OCSP request contains an issuerNameHash and issuerKeyHash for > which the OCSP responder IS authoritative and the requested certificate has > not been issued. This OCSP response MUST include the extended revoked > definition response extension in the response, indicating that the OCSP > responder supports the extended definition of the "revoked" state to also > cover non-issued certificates. The SingleResponse related to this non-issued > certificate MUST specify the revocation reason certificateHold (6), MUST > specify the revocationTime January 1, 1970, and MUST NOT include a CRL > references extension or any CRL entry extensions. [1] > > I agree number 3 above is in conflict with the BRs as pointed out by Wayne. > > - Curt > > [1] RFC 6960: https://tools.ietf.org/html/rfc6960 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
