On 20/4/2022 6:40 π.μ., 'Jacob Hoffman-Andrews' via
[email protected] wrote:
Separate from the "final" / "corresponding" question, I find this
phrasing confusing:
" * if a corresponding certificate cannot be verified as matching
a precertificate using the algorithms in RFC 6962, then two
distinct corresponding certificates are presumed to exist, and it
is misissuance if the two corresponding certificates have the same
serial number and issuer, even if only one corresponding
certificate actually exists;"
In particular the "if" in "it is misissuance if" is confusing, since
it's actually unconditional: given that
- the precertificate and the corresponding/final certificate exist,
- have the same serial number,
- either have the same issuer or are related via a Precertificate
signing certificate
- and don't match per RFC 6962
Then there's a misissuance; there's no "if" because the corresponding
certificate that is presumed to exist is presumed to have the same
serial and issuer. Also "matching a precertificate" is ambiguous: does
it mean "a specific precertificate" or "any precertificate?"
For context, Andrew's original reason for proposing this text was:
> When a Precertificate Signing Certificate is used, the issuer of a
> precertificate and its corresponding certificate are not the same, but
> there could still be a duplicate serial number violation.
The duplicate serial number violation can happen when there are two
corresponding certificates with the same issuer and serial, right? But
that seems to be covered by the straightforward "no duplicate serials"
rule. No exemption to the "no duplicate serials" rule need apply for
setups with Precertificate Signing Certificates, because those setups
specifically avoid the "same issuer and serial" problem.
Here's my stab at it, knowing this has been discussed many times
before and it's challenging to write well:
- "It is misissuance for two or more certificates to be issued with
the same issuer and serial, with one exception: if exactly two
certificates are issued with the same issuer and serial, and one of
them is a precertificate, and one of them corresponds to that
precertificate, it is not misissuance."
Although the proposed text makes sense to be, perhaps there is another
way to describe it.
The BRs (section 4.9.10) introduce useful terms that could be used to
better describe this scenario:
/"The OCSP responder MAY provide definitive responses about "reserved"
certificate serial numbers, as if there was a corresponding Certificate
that matches the Precertificate [RFC6962]./
//
/A certificate serial number within an OCSP request is one of the
following three options:/
//
1. /"assigned" if a Certificate with that serial number has been issued
by the Issuing CA, using any current or previous key associated with
that CA subject; or/
2. /"reserved" if a Precertificate [RFC6962] with that serial number
has been issued by a. the Issuing CA; or b. a Precertificate Signing
Certificate [RFC6962] associated with the Issuing CA; or/
3. /"unused" if neither of the previous conditions are met."/
Using parts of that text, I propose the following:
/A certificate serial number is one of the following three options:/
//
1. /"assigned" if a Certificate with that serial number has been issued
by the Issuing CA, using any current or previous key associated with
that CA subject; or/
2. /"reserved" if a Precertificate [RFC6962] with that serial number
has been issued by a. the Issuing CA; or b. a Precertificate Signing
Certificate [RFC6962] associated with the Issuing CA; or/
3. /"unused" if neither of the previous conditions are met."/
__/CAs SHALL NOT use the same "reserved" serial number for different
Precertificates under the same Issuing CA, even if a corresponding
Certificate does not actually exist./
Using the language from the BRs (changing MAY to a SHALL), I guess the
last bullet of the proposed policy could also be replaced by:
* /The OCSP responder SHALL provide definitive responses about
"reserved" certificate serial numbers, as if there was a
corresponding Certificate that matches the Precertificate [RFC6962]/
since it mainly affects the OCSP service (CRLs only provide information
about "revoked" certificates).
Thanks,
Dimitris.
//
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0ec52cd1-a93d-894b-4afb-e8362127ec22%40it.auth.gr.
