On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote:

On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos <ji...@it.auth.gr <mailto:ji...@it.auth.gr>> wrote:


    Doesn't this break compatibility with older clients? It is older
    that need to see "revoked" which is equivalent to "not good" for
    of "non-issued" Certificates. I think this is what 6960 is trying to


    Older clients will see "revoked" but newer clients will see
    "revoked" plus additional information to interpret as
    "non-issued". Is
    there any specific text in the Mozilla Policy or the BRs that
    forbids the use of this RFC 6960 practice?

    BRs 4.9.13: "The Repository MUST NOT include entries that indicate
    a Certificate is suspended."

You just quoted it.

6960 is trying to say “not revoked, suspended for now, but this may be used to issue a legitimate certificate at some point in the future”
Read Section 5. Read the related contemporary mailing list discussions.

It would be useful to identify whether there’s an objective to the questions, since that might help us cut down things quicker:
- Are you running a 5019 responder or a 6960 responder?
- Do you agree that the definition in 6960, Section 2.2, applies to pre-certificates?

If you are running a 6960 responder, and you don’t believe it applies to pre-certificates, we should work that out first.

2.2 applies to pre-certificates but between when the pre-certificate and the final certificate is issued, there is a gap. As I understand it, this is the main topic of this discussion, trying to interpret the best course of action for this gap. If the responder was allowed to respond with revoked and all the provisions of 6960 related to "non-issued" certificates, until the final certificate is issued (if it is ever issued), that seems like a safer option for Relying Parties because they would not risk seeing a "valid" response for a Certificate that has not been issued yet.

That was my initial thought which made me post to this thread. I thought it made sense but I could be wrong.


dev-security-policy mailing list

Reply via email to