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
clients
that need to see "revoked" which is equivalent to "not good" for
cases
of "non-issued" Certificates. I think this is what 6960 is trying to
accommodate.
No.
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
strictly
forbids the use of this RFC 6960 practice?
BRs 4.9.13: "The Repository MUST NOT include entries that indicate
that
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.
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
