Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

I've gone ahead and moved [4] to the "Recommended Practices" section.

The ballot to modify the BRs is now in the formal discussion period leading
up to a vote [5].

I'll be resolving the existing compliance bugs on this issue as INVALID.
I'd like to thank the CAs that proactively submitted incident reports
rather than taking a "wait and see" approach. That degree of transparency
is both appreciated and encouraged.

- Wayne

[5] https://cabforum.org/pipermail/servercert-wg/2019-October/001145.html

On Wed, Oct 2, 2019 at 2:20 AM Rob Stradling  wrote:

> On 02/10/2019 00:51, Wayne Thayer wrote:
> > On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
> >
> > I propose that you update [4] to say that Mozilla won't treat
> > non-compliance with [4] as an "incident" whilst it remains the case
> > that the BRs are inconsistent with [4].
> >
> > I could simply move [4] to a "recommended practice" (SHOULD) until the
> > ballot comes into force, then move it back to "required". That implies
> > that the bugs which have been opened for this specific issue (responding
> > "unknown" - not to be confused with "returns 1 byte") will be closed as
> > INVALID.
> >
> > Are there strong objections to this course of action?
>
> It seems a bit strange to recommend a practice that CAs cannot currently
> adhere to without violating the BRs and some other root programs'
> policies, but at the same time it is helpful to signpost upcoming policy
> changes.
>
> I don't object strongly.
>
> > - Wayne
> >
> > [4]
> >
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 02/10/2019 00:51, Wayne Thayer wrote:
> On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
> 
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case
> that the BRs are inconsistent with [4].
> 
> I could simply move [4] to a "recommended practice" (SHOULD) until the 
> ballot comes into force, then move it back to "required". That implies 
> that the bugs which have been opened for this specific issue (responding 
> "unknown" - not to be confused with "returns 1 byte") will be closed as 
> INVALID.
> 
> Are there strong objections to this course of action?

It seems a bit strange to recommend a practice that CAs cannot currently 
adhere to without violating the BRs and some other root programs' 
policies, but at the same time it is helpful to signpost upcoming policy 
changes.

I don't object strongly.

> - Wayne
> 
> [4] 
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling  wrote:

>
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case that
> the BRs are inconsistent with [4].
>
>
I could simply move [4] to a "recommended practice" (SHOULD) until the
ballot comes into force, then move it back to "required". That implies that
the bugs which have been opened for this specific issue (responding
"unknown" - not to be confused with "returns 1 byte") will be closed as
INVALID.

Are there strong objections to this course of action?

- Wayne

[4]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 01/10/2019 00:45, Wayne Thayer via dev-security-policy wrote:
> I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob
> identified.

Thanks Wayne.  I've offered to endorse.

> I also want to acknowledge the feedback from Google on the timing of this.
> I can appreciate the framing of this as a new policy that's been added
> without due process, but I view this as a clarification of existing
> requirements.

I view [4] as new policy that's been added without due process.  I would 
have preferred to see your CABForum ballot [1] resolve this in the BRs 
first, so that CAs weren't faced with conflicting requirements.

> Some CAs have already been held accountable for this requirement [2]
> and some that have been paying close attention adhere to
> it. Others were struggling to determine what to do. Under these
> circumstances, it made no sense to me to roll back the policy, so the only
> reasonable course was to clarify it in favor of the consensus that emerged
> from this thread.

Some CAs (including Sectigo, as I mentioned in an earlier message) are 
currently compliant with (quoting you [1])...
   "During a lengthy discussion on the mozilla.dev.security.policy forum,
it was discovered that BR section 4.9.10 combined with BR
section 7.1.2.5 prevents a CA from responding “good” for a
precertificate." [1]

...but are not compliant with [4].

If/when your CABForum ballot [1] passes and (after the IPR period) takes 
effect, it will become possible for CAs to comply with [4] without 
falling out of compliance with the root program policies of Apple, 
Microsoft, etc, which incorporate the BRs but don't have a BR policy 
override equivalent to [4]).  Until then, what does Mozilla expect CAs 
to do?

> I'm still open to making changes to our "required practice" on
> precertificates, but having caught up on the thread I don't think any
> further changes are necessary.

I propose that you update [4] to say that Mozilla won't treat 
non-compliance with [4] as an "incident" whilst it remains the case that 
the BRs are inconsistent with [4].

> - Wayne
> 
> [1] https://cabforum.org/pipermail/servercert-wg/2019-September/00.html
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ

[4] 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob
identified.

I also want to acknowledge the feedback from Google on the timing of this.
I can appreciate the framing of this as a new policy that's been added
without due process, but I view this as a clarification of existing
requirements. Some CAs have already been held accountable for this
requirement [2] and some that have been paying close attention adhere to
it. Others were struggling to determine what to do. Under these
circumstances, it made no sense to me to roll back the policy, so the only
reasonable course was to clarify it in favor of the consensus that emerged
from this thread.

I'm still open to making changes to our "required practice" on
precertificates, but having caught up on the thread I don't think any
further changes are necessary.

- Wayne

[1] https://cabforum.org/pipermail/servercert-wg/2019-September/00.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ

On Wed, Sep 25, 2019 at 3:59 AM Clint Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Clint Wilson via dev-security-policy]

On Wed, Sep 25, 2019, 06:30 Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 24 Sep 2019, at 07:35, Clint Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> > […] it seems like one useful change for us
> > here may be to issue those final certs without the SCTs rather than
> > abandoning the pre-cert as we do today. We'd obviously still need to
> > re-attempt issuance of another cert with the SCT list (as that's what a
> > vast majority of customers expect), but reducing the number of orphaned
> > pre-certs seems like a reasonably good thing, even if inconsequential for
> > how we interact with the (pre-cert || cert).
>
> Perhaps I’m misunderstanding, but wouldn’t the generation of a set of
> certificates (at least two in that set - one with SCTs embedded, and one
> without) end up with several certificates signed by the same Issuing CA,
> but with identical serial numbers? This would violate RFC 5280 Section
> 4.1.2.2. For publicly trusted CAs, a (pre-cert, cert) pair does not violate
> that condition by virtue of BR Section 7.1.2.5. Combining the two
> documents, it would seem that the number of certificates following a
> pre-certificate issuance is strictly limited to one.
>
> Again - I may have misunderstood: apologies if this is the case -
> corrections welcome.
>
> Regards,
>
> Neil


Sorry, I think the misunderstanding is my fault. You're correct if the same
pre-cert was used for two subsequent leaf signings.
What I meant was where now we would abandon retrying signing of the leaf
due to failure in retrieval of the SCTs, we would instead sign the leaf
without SCTs, then start the entire process over again once CT logs were
available (new tbsCert, new pre-cert, new leaf).
So same subject/sAN contents, but not the same serial number.

Cheers!
Clint
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 24 Sep 2019, at 07:35, Clint Wilson via dev-security-policy 
>  wrote:
> 
> 
> […] it seems like one useful change for us
> here may be to issue those final certs without the SCTs rather than
> abandoning the pre-cert as we do today. We'd obviously still need to
> re-attempt issuance of another cert with the SCT list (as that's what a
> vast majority of customers expect), but reducing the number of orphaned
> pre-certs seems like a reasonably good thing, even if inconsequential for
> how we interact with the (pre-cert || cert).

Perhaps I’m misunderstanding, but wouldn’t the generation of a set of 
certificates (at least two in that set - one with SCTs embedded, and one 
without) end up with several certificates signed by the same Issuing CA, but 
with identical serial numbers? This would violate RFC 5280 Section 4.1.2.2. For 
publicly trusted CAs, a (pre-cert, cert) pair does not violate that condition 
by virtue of BR Section 7.1.2.5. Combining the two documents, it would seem 
that the number of certificates following a pre-certificate issuance is 
strictly limited to one.

Again - I may have misunderstood: apologies if this is the case - corrections 
welcome.

Regards,

Neil
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Clint Wilson via dev-security-policy]

On Tue, Sep 24, 2019 at 5:06 AM Ryan Sleevi  wrote:

>
>
> On Tue, Sep 24, 2019 at 2:36 AM Clint Wilson  wrote:
>
>> On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> Agreed especially with the final paragraph here.
>> Apologies if this is too tangential, but one potential change I see
>> coming out of this discussion is around CT Log "outages". That is, separate
>> from the misconfiguration issues we've seen, one other instance where
>> sometimes pre-certificates are generated without an associated certificate
>> is when CT logs necessary for meeting a browser CT policy aren't available
>> (as Andy points out). Even if for very brief windows, today we occasionally
>> see windows where quite a few pre-certs can be generated but final
>> certificate issuance abandoned due to lack of SCTs (which is purely an
>> implementation choice as to when to abandon retries, I think).
>>
>
> Right. I think that's the substance of it. It's unclear to me what the
> benefit is of abandoning versus retrying later. I suspect it's a question
> of what the CA's window would be for (validation + SCTs), and if it's
> easier to kick it back into a validation flow if the SCT window elapses.
> Does that guess sound right?
>

Yeah, that's exactly right. That's also partially because we don't cache
CAA for 8 hours, so we could instead widen the window of retries as well.

>
>
>> Thinking through this discussion, it seems like one useful change for us
>> here may be to issue those final certs without the SCTs rather than
>> abandoning the pre-cert as we do today. We'd obviously still need to
>> re-attempt issuance of another cert with the SCT list (as that's what a
>> vast majority of customers expect), but reducing the number of orphaned
>> pre-certs seems like a reasonably good thing, even if inconsequential for
>> how we interact with the (pre-cert || cert). Does that seem like a
>> reasonable change in process to make?
>>
>
> It's not clear to me why this would be good or desirable? It doesn't seem
> to benefit the client/relying party ecosystem any. And it seems like it'd
> be more work for the CA to do.
>
> Perhaps I'm just not familiar with the set of CA problems it would solve?
> Could you help me out?
>

So I'm not totally confident that it is good or desirable, but my thought
was more along the lines of cognitive benefits than operational. It's
apparently somewhat difficult to grok that "cert" interactions need to
apply to pre-certs, so if CAs moved away from abandoning pre-certs
(wherever possible), then a lot of the behavior changes discussed here
would happen automatically. That is, we have to put in a fix for ensuring
services are available either way for (pre-certs || certs), but if there is
more reliably (pre-cert && cert) available then the services are (from what
I can see) already available for CAs. Maybe that's a change that can occur
ahead of patches for the misconfiguration issues.
Since all of that's relatively short-term benefits, I'm probably not
approaching this the best way, but that was the thought.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Erwann Abalea via dev-security-policy]

Bonjour,

Le vendredi 20 septembre 2019 22:20:02 UTC+2, Curt Spann a écrit :
[...]
> My interpretation is a “revoked” OCSP response should be used in the 
> following conditions:
[...]
> 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.

A CA is not revoked, only certificates are. A CA can have several certificates, 
all sharing the same subject name while public keys may be identical or 
different, chaining to identical or different Trust Anchors, and some of the 
certificates issued to the CA might have been revoked while others are still 
valid. Returning a revoked answer whenever a CA certificate is revoked 
regardless of the status of all the other certificates is not going to work.

RFC6960 includes some provisions in clause 2.7 regarding CA key compromise, and 
in such condition, the OCSP responder MAY return a revoked status.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Clint Wilson via dev-security-policy]

On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Sep 23, 2019 at 11:53 PM Andy Warner via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > The practice of revoking non-issued certificates would therefore lead to
> > CRL growth which would further make reliable revocation checking on
> > bandwidth constrained clients more difficult.
>
>
> As others have pointed out, it sounds like GTS is confused. This only
> applies if you need to revoke them.
>
> I’m not sure how many times it bears repeating, but the suggestion that you
> need to revoke if you issued a precert, but not the cert, is patently
> absurd. Among other things, as you point out, it causes both CRL and OCSP
> growth.
>
> Luckily, every browser participating has seemingly tried to make it clear
> that’s not expected. So one objection handled :)
>
> 2. There seem to be a number of assumptions that precertificate issuance
> > and certificate issuance is roughly atomic. In reality, a quorum of SCTs
> is
> > required prior to final certificate issuance, so that is not the case.
>
>
> Could you point to an example? All of the conversation I’ve seen has
> highlighted that they are sequential, and can suffer a variety of delays or
> errors. This is why the conversation has been about the least error prone
> approach, in that it leads to the most consistent externally observable
> results.
>
> I admit, I’m honestly not sure what part of the conversation is being
> referred to here.
>
> As a result of this, the existence of a precertificate is possible without
> > a final certificate having been issued.
>
>
> Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
> proposed language further considers that, but emphasizes that by producing
> and logging the precertificate, then regardless of the issue, the CA should
> be prepared to provision services for it for the duration.
>
> If you find yourself continually generating precertificates, that suggests
> an operational/design issue, which you can remediate based on which is
> cheaper for you: fixing the pipeline to be reliable (as many reliability
> issues seen, to date, have been on the CA side) or continue to provision
> services when things go bad. Either works, you can choose.
>
> The important part is you need to treat (pre-cert || cert) in scope for all
> your activities. You must be capable of revoking. You must be capable of
> searching your databases. You must be capable of validating.
>

Agreed especially with the final paragraph here.
Apologies if this is too tangential, but one potential change I see coming
out of this discussion is around CT Log "outages". That is, separate from
the misconfiguration issues we've seen, one other instance where sometimes
pre-certificates are generated without an associated certificate is when CT
logs necessary for meeting a browser CT policy aren't available (as Andy
points out). Even if for very brief windows, today we occasionally see
windows where quite a few pre-certs can be generated but final certificate
issuance abandoned due to lack of SCTs (which is purely an implementation
choice as to when to abandon retries, I think).
Thinking through this discussion, it seems like one useful change for us
here may be to issue those final certs without the SCTs rather than
abandoning the pre-cert as we do today. We'd obviously still need to
re-attempt issuance of another cert with the SCT list (as that's what a
vast majority of customers expect), but reducing the number of orphaned
pre-certs seems like a reasonably good thing, even if inconsequential for
how we interact with the (pre-cert || cert). Does that seem like a
reasonable change in process to make?


>
> 3. This raises the question of how much time a CA has from the time they
> > issue a precertificate to when the final certificate must be issued.
>
>
> It doesn’t, because it’s a flawed understanding that’s been repeatedly
> addressed: you don’t have to issue the final certificate. But you MUST be
> prepared to provision services as if you had.
>
> In general, this means you provision and distribute those services ahead of
> time. My reply to Dimitris earlier today provided a road map to an error
> prone design, as well as two different ways of accomplishing compliant
> design. Given that GTS is responding to that thread, I’m surprised to see
> it come up again so quickly, as it seems like GTS may not have understood?
>
>
> Likewise, there is the question of how soon the revocation information must
> > be produced and reachable by an interested party (e.g. someone who has
> > never seen the certificate in question but still wants to know the status
> > of that certificate). [Aside, Wayne, you specifically said relying
> parties
> > earlier, did you intend to say interested party or relying party? We have
> > some additional questions if relying party was actually intended, as
> using
> > 

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Tue, Sep 24, 2019 at 2:36 AM Clint Wilson  wrote:

> On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
>> proposed language further considers that, but emphasizes that by producing
>> and logging the precertificate, then regardless of the issue, the CA
>> should
>> be prepared to provision services for it for the duration.
>>
>> If you find yourself continually generating precertificates, that suggests
>> an operational/design issue, which you can remediate based on which is
>> cheaper for you: fixing the pipeline to be reliable (as many reliability
>> issues seen, to date, have been on the CA side) or continue to provision
>> services when things go bad. Either works, you can choose.
>>
>> The important part is you need to treat (pre-cert || cert) in scope for
>> all
>> your activities. You must be capable of revoking. You must be capable of
>> searching your databases. You must be capable of validating.
>>
>
> Agreed especially with the final paragraph here.
> Apologies if this is too tangential, but one potential change I see coming
> out of this discussion is around CT Log "outages". That is, separate from
> the misconfiguration issues we've seen, one other instance where sometimes
> pre-certificates are generated without an associated certificate is when CT
> logs necessary for meeting a browser CT policy aren't available (as Andy
> points out). Even if for very brief windows, today we occasionally see
> windows where quite a few pre-certs can be generated but final certificate
> issuance abandoned due to lack of SCTs (which is purely an implementation
> choice as to when to abandon retries, I think).
>

Right. I think that's the substance of it. It's unclear to me what the
benefit is of abandoning versus retrying later. I suspect it's a question
of what the CA's window would be for (validation + SCTs), and if it's
easier to kick it back into a validation flow if the SCT window elapses.
Does that guess sound right?


> Thinking through this discussion, it seems like one useful change for us
> here may be to issue those final certs without the SCTs rather than
> abandoning the pre-cert as we do today. We'd obviously still need to
> re-attempt issuance of another cert with the SCT list (as that's what a
> vast majority of customers expect), but reducing the number of orphaned
> pre-certs seems like a reasonably good thing, even if inconsequential for
> how we interact with the (pre-cert || cert). Does that seem like a
> reasonable change in process to make?
>

It's not clear to me why this would be good or desirable? It doesn't seem
to benefit the client/relying party ecosystem any. And it seems like it'd
be more work for the CA to do.

Perhaps I'm just not familiar with the set of CA problems it would solve?
Could you help me out?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 23, 2019 at 11:53 PM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The practice of revoking non-issued certificates would therefore lead to
> CRL growth which would further make reliable revocation checking on
> bandwidth constrained clients more difficult.


As others have pointed out, it sounds like GTS is confused. This only
applies if you need to revoke them.

I’m not sure how many times it bears repeating, but the suggestion that you
need to revoke if you issued a precert, but not the cert, is patently
absurd. Among other things, as you point out, it causes both CRL and OCSP
growth.

Luckily, every browser participating has seemingly tried to make it clear
that’s not expected. So one objection handled :)

2. There seem to be a number of assumptions that precertificate issuance
> and certificate issuance is roughly atomic. In reality, a quorum of SCTs is
> required prior to final certificate issuance, so that is not the case.


Could you point to an example? All of the conversation I’ve seen has
highlighted that they are sequential, and can suffer a variety of delays or
errors. This is why the conversation has been about the least error prone
approach, in that it leads to the most consistent externally observable
results.

I admit, I’m honestly not sure what part of the conversation is being
referred to here.

As a result of this, the existence of a precertificate is possible without
> a final certificate having been issued.


Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
proposed language further considers that, but emphasizes that by producing
and logging the precertificate, then regardless of the issue, the CA should
be prepared to provision services for it for the duration.

If you find yourself continually generating precertificates, that suggests
an operational/design issue, which you can remediate based on which is
cheaper for you: fixing the pipeline to be reliable (as many reliability
issues seen, to date, have been on the CA side) or continue to provision
services when things go bad. Either works, you can choose.

The important part is you need to treat (pre-cert || cert) in scope for all
your activities. You must be capable of revoking. You must be capable of
searching your databases. You must be capable of validating.

3. This raises the question of how much time a CA has from the time they
> issue a precertificate to when the final certificate must be issued.


It doesn’t, because it’s a flawed understanding that’s been repeatedly
addressed: you don’t have to issue the final certificate. But you MUST be
prepared to provision services as if you had.

In general, this means you provision and distribute those services ahead of
time. My reply to Dimitris earlier today provided a road map to an error
prone design, as well as two different ways of accomplishing compliant
design. Given that GTS is responding to that thread, I’m surprised to see
it come up again so quickly, as it seems like GTS may not have understood?


Likewise, there is the question of how soon the revocation information must
> be produced and reachable by an interested party (e.g. someone who has
> never seen the certificate in question but still wants to know the status
> of that certificate). [Aside, Wayne, you specifically said relying parties
> earlier, did you intend to say interested party or relying party? We have
> some additional questions if relying party was actually intended, as using
> it in that context seems to redefine what a relying party is.]


I cannot see how it redefined relying party, as anyone who decides to trust
GTS becomes a relying party of GTS, and does not change anything.

The question of how soon has been mentioned earlier, but again is addressed
by earlier replies. We’ve seen the problems with CAs arguing CDN
distribution. There is no reasonable way that the relying party community
can or should accept the phased rollout delays as compliant, particularly
with a 24 hour revocation timeline (for example).

A common approach to this is to pregenerate responses for distribution,
with edge caches (5019-style) that can talk to an authoritative origin
(6960-style) under the hood. If a client queries for the status, the edge
cache serves it if it’s a cache hit, otherwise communicates back to the
origin and pulls into the cache. This is perhaps unsurprising, as it’s the
model many active CDNs use, functioning as it were as a reverse proxy with
caching (and the ability to globally evict from the cache).

Since the CA already needs to ensure that they can have a globally
consistent response distributed within 24-hours, and that any time spent
synchronizing is time that the CA itself cannot use to investigate/respond,
this design discourages CAs from multihour rollouts (and that’s a good
thing). If you can’t meet those timelines, then you’re setting yourself up
for a CA incident that other CAs will have designed around.

If you 

Re: DigiCert OCSP services returns 1 byte

[Curt Spann via dev-security-policy]

> The CRL question is not about it being a requirement, but rather the fact
> that it could / would lead to disparate treatment between CRL and OCSP for
> the same certificate, which does not feel right.

The CRL would only grow if the (pre-cert || cert) needed to be revoke for any 
reason. CRLs only contain a list of revoked (pre-cert || cert) and don’t 
attempt to address whether the (pre-cert || cert) has been issued.

- Curt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Andy Warner via dev-security-policy]

The CRL question is not about it being a requirement, but rather the fact
that it could / would lead to disparate treatment between CRL and OCSP for
the same certificate, which does not feel right.

On the CT quorum issue, we use a mix of the most available sharded logs and
that is the failure rate we're observing. We have a few ideas for
improvements we're working on. If other operators are seeing much different
success rates, we'd love to compare notes. We're using the published best
practices, spreading load and using sharded logs, so an implementation
issue is not obvious if there is one. That said, other groups within Google
including the CT team also exchange messages with CT logs in fairly high
volumes, so we may experience atypically high rate-limiting due to all
being bucketed together.

CAA validations are only good for 8 hours, so the suggestion of a year
misses the much shorter timeline that needs to be honored for CAA.

--
Andy Warner
Google Trust Services

On Mon, Sep 23, 2019 at 3:57 PM Kurt Roeckx  wrote:

> On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via
> dev-security-policy wrote:
> >
> > 1. The new text added to the Mozilla Recommended and Required Practices
> for this topic states only OCSP status is required for precertificates.
> Many CAs provide both CRLs and OCSP services and it would be problematic if
> these two mechanisms provided different answers to the same question.
> >
> > The practice of revoking non-issued certificates would therefore lead to
> CRL growth which would further make reliable revocation checking on
> bandwidth constrained clients more difficult.
>
> There have been suggestions to revoke them, but it's my
> understanding that there is no such requirement.
>
> > 2. There seem to be a number of assumptions that precertificate issuance
> and certificate issuance is roughly atomic. In reality, a quorum of SCTs is
> required prior to final certificate issuance, so that is not the case.
>
> I don't see anybody suggesting that, nor how it's relevant.
>
> With all the uptime requirements on the logs and the number of
> available logs, I don't see why you should have a failure rate
> of 1 in 2000, and that more seems like an implementation problem.
>
> > 3. This raises the question of how much time a CA has from the time they
> issue a precertificate to when the final certificate must be issued. When
> there are logs ecosystem issues that are beyond the control of a CA, the
> gap can easily be orders of magnitude higher than normal operating
> conditions.
>
> At what is the issue with that?
>
> > * Clarifications
> >
> > This in turn raises the question if CAs can re-use authorization data
> such as CAA records or domain authorizations from the precertificate? If a
> final certificate has not been issued due to a persistent quorum failure,
> and that failure persists longer than the validity of the used
> authorization data, can the authorizations that were done prior to the
> precertificate issuance be re-used?
>
> So 1 year is sometimes not enough to get SCTs?
>
>
> Kurt
>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Kurt Roeckx via dev-security-policy]

On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via dev-security-policy 
wrote:
> 
> 1. The new text added to the Mozilla Recommended and Required Practices for 
> this topic states only OCSP status is required for precertificates. Many CAs 
> provide both CRLs and OCSP services and it would be problematic if these two 
> mechanisms provided different answers to the same question. 
> 
> The practice of revoking non-issued certificates would therefore lead to CRL 
> growth which would further make reliable revocation checking on bandwidth 
> constrained clients more difficult.

There have been suggestions to revoke them, but it's my
understanding that there is no such requirement.

> 2. There seem to be a number of assumptions that precertificate issuance and 
> certificate issuance is roughly atomic. In reality, a quorum of SCTs is 
> required prior to final certificate issuance, so that is not the case.

I don't see anybody suggesting that, nor how it's relevant.

With all the uptime requirements on the logs and the number of
available logs, I don't see why you should have a failure rate
of 1 in 2000, and that more seems like an implementation problem.

> 3. This raises the question of how much time a CA has from the time they 
> issue a precertificate to when the final certificate must be issued. When 
> there are logs ecosystem issues that are beyond the control of a CA, the gap 
> can easily be orders of magnitude higher than normal operating conditions.

At what is the issue with that?

> * Clarifications
> 
> This in turn raises the question if CAs can re-use authorization data such as 
> CAA records or domain authorizations from the precertificate? If a final 
> certificate has not been issued due to a persistent quorum failure, and that 
> failure persists longer than the validity of the used authorization data, can 
> the authorizations that were done prior to the precertificate issuance be 
> re-used?

So 1 year is sometimes not enough to get SCTs?


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Andy Warner via dev-security-policy]

The last thing we intended was for our prior mail to be interpreted as negative 
and without substance.  That said, it is clear our mail was not received in the 
light in which it was intended.

We would like to rectify that. We have been closely monitoring this thread and 
as it began to converge on a conclusion we started planning for each of our CA 
environments what if any changes would be required and what solutions compliant 
with our understanding of the conclusions would look like.

With that background, our understanding is that the goal of this change is to 
make it easier to monitor the issuance and revocation practices of a CA based 
on the existence of precertificates, i.e. extending the use of certificate 
revocation data to include this monitoring use case. We see value in this and 
are supportive of the overall change, as it is clear that CT, as a whole, has 
made significant quality improvement to the WebPKI as a whole and this provides 
additional incremental benefit.

However, we see several challenges that we want to discuss, in particular:

1. The new text added to the Mozilla Recommended and Required Practices for 
this topic states only OCSP status is required for precertificates. Many CAs 
provide both CRLs and OCSP services and it would be problematic if these two 
mechanisms provided different answers to the same question. 

The practice of revoking non-issued certificates would therefore lead to CRL 
growth which would further make reliable revocation checking on bandwidth 
constrained clients more difficult.

Though this tax may be deemed acceptable, there is a clear impact and GTS feels 
that increasing CRL sizes for this use case is not in the best interest of 
users. We can see both sides of the argument, but we think a bit more detail is 
required to ensure our implementations align with best practices and user 
interests.

2. There seem to be a number of assumptions that precertificate issuance and 
certificate issuance is roughly atomic. In reality, a quorum of SCTs is 
required prior to final certificate issuance, so that is not the case.

CAs are rate limited by logs or logs experience availability issues that make 
achieving quorum require retries or fail altogether. GTS, for example, 
experiences approximately 0.05% delays / order abandonment related to an 
inability to achieve quorum.

As a result of this, the existence of a precertificate is possible without a 
final certificate having been issued. With the wider availability of sharded 
logs, this number has been improving, but it continues to be our most common 
cause of issuance delay or order abandonment.

3. This raises the question of how much time a CA has from the time they issue 
a precertificate to when the final certificate must be issued. When there are 
logs ecosystem issues that are beyond the control of a CA, the gap can easily 
be orders of magnitude higher than normal operating conditions.

Likewise, there is the question of how soon the revocation information must be 
produced and reachable by an interested party (e.g. someone who has never seen 
the certificate in question but still wants to know the status of that 
certificate). [Aside, Wayne, you specifically said relying parties earlier, did 
you intend to say interested party or relying party? We have some additional 
questions if relying party was actually intended, as using it in that context 
seems to redefine what a relying party is.]

This “reachable” part is particularly meaningful in that when using a CDN there 
are often phased roll outs that can take hours to complete. Today, the BRs 
leave this ambiguous, the only statement in this area is that new information 
must be published every four days:

"The CA SHALL update information provided via an Online Certificate Status 
Protocol at least every four days. OCSP responses from this service MUST have a 
maximum expiration time of ten days."

With this change, it would seem there needs to be a lower bound defined for how 
quickly the information needs to be available if it is to be an effective 
monitoring tool.

* Clarifications

This in turn raises the question if CAs can re-use authorization data such as 
CAA records or domain authorizations from the precertificate? If a final 
certificate has not been issued due to a persistent quorum failure, and that 
failure persists longer than the validity of the used authorization data, can 
the authorizations that were done prior to the precertificate issuance be 
re-used? If the precertificate is a promise to issue the exact same cert, it 
would seem to imply yes, but there are plenty or real world scenarios where 
that would not be sensible or in-line with the requester's intent. If the CAA 
record changes between initial validation for the precertificate and 
re-validation for actual issuance if there were delays, what is the correct 
course of action? 

* Process

On Thursday last week, Wayne added the topic to Recommended and Required 

Re: DigiCert OCSP services returns 1 byte

[Dimitris Zacharopoulos via dev-security-policy]

On 2019-09-23 5:00 μ.μ., Ryan Sleevi via dev-security-policy wrote:

No. That’s the more dangerous approach which I’ve tried repeatedly to
dissuade. You should produce, and distribute, the Good response with the
pre-certificate.


Understood. Thank you for the clear guidance.

Dimitris.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 23, 2019 at 8:50 AM Dimitris Zacharopoulos 
wrote:

>
>
> On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote:
>
> 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.
>

Got it.

The point in trying to communicate is that with 2.2, the issuance of a
precertificate is proof that it is “not non-issued”. This double negative
is hard to parse, but it is essential: The gap comes up if you assume it’s
trying to measure the issuance of C, the certificate, but it isn’t - it’s
measuring when the CA doesn’t know if that serial number has been assigned.
Because it’s measured by non-issuance, and the precertificate is proof of
“not non-issuance”

The only time where 6960 gets tricky is covered in Section 5: if a CA
chooses to use authoritative revoked for non-issued and it uses sequential
serial numbers. 5019 explains why you shouldn’t (and why you cannot,
effectively), and 6960 leaves it optional. However, since no CA uses
sequential serial numbers, there’s no reason to generate definitive revoked
messages for “non-issued” certificates, and the existence of a
precertificate is proof that it is “not non-issued”

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.
>

No. That’s the more dangerous approach which I’ve tried repeatedly to
dissuade. You should produce, and distribute, the Good response with the
pre-certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Dimitris Zacharopoulos via dev-security-policy]

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



On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos 
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

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos 
wrote:

>
>
> On 2019-09-23 1:37 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
> > dev-security-policy  wrote:
> >
> >> On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
> >>> On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
> >>> mailto:ji...@it.auth.gr>> wrote:
> >>>
> >>>  
> >>>
> >>>  Using the following practice as described in RFC 6960 should not
> >>>  be a violation of the BRs. That is, answering revoked where a
> >>>  pre-certificate has been issued but not the final certificate
> >>>  should be OK as long as the response contains the Extended Revoked
> >>>  extension and the revocationReason is |certificateHold|. With this
> >>>  practice, it is very clear that the final certificate has
> >>>  not been issued, so would this be considered a violation of the
> >>>  Mozilla policy?
> >>>
> >>> Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
> >>> responder to return a certificateHold reason in a response for a
> >>> precertificate. As you noted, the BRs forbid certificate suspension.
> >>> Mozilla assumes that a certificate corresponding to every
> >>> precertificate exists, so the OCSP response would be interpreted as
> >>> applying to a certificate and thus violating the BRs.
> >>>
> >>> In practice, I also think that Ryan has raised a good point about OCSP
> >>> response caching. If a revoked response for a precertificate were
> >>> supplied by a CA, would the Subscriber need to wait until that
> >>> response expires before using the certificate, or else risk that some
> >>> user agent has cached the revoked response?
> >> Dear Wayne,
> >>
> >> This list has discussed about compatibility issues several times in the
> >> past, so we must consider how Mozilla supports the majority of clients.
> >> RFC 6960 does not just mandate that the revocationReason is
> >> |certificateHold|. It requires a certain revocation date AND a specific
> >> extension that unambiguously point to a "non-issued" Certificate, not a
> >> "Suspended" Certificate in general. This means that there is technical
> >> language to distinguish the case of a Certificate being "suspended" and
> >> a Certificate being "non-issued".
> >>
> >> OCSP response caching is equally problematic for "unknown" responses
> >> which are also cached. The behavior of clients in sight of an "unknown"
> >> or "revoked"-with-additional-info response, should be more or less the
> >> same (i.e. don't trust the certificate).
> >>
> >> Neither the Mozilla policy language nor the ||BRs support the assumption
> >> that whenever we have an OCSP response of "certificateHold", this means
> >> the certificate is "Suspended". My interpretation is that if a response
> >> provides all of the following information:
> >> - status --> revoked
> >> - revocation reason --> certificateHold
> >> - revocationTime --> January 1, 1970
> >> - MUST NOT include a CRL references extension or any CRL entry
> extensions
> >> - includes the extended revoke extension
> >>
> >> then this is the consistent semantics for a "non-issued" certificate,
> >> not about a Certificate that was "issued" and then "suspended".
> >>
> >> Is this a reasonable interpretation?
> >
> > I do not believe this is a reasonable interpretation, precisely because
> > 6960 uses this status so that the revocation is temporary, and attackers
> > can not use this to cause responders to mark serials they have not yet
> used
> > as revoked.
>
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Dimitris Zacharopoulos via dev-security-policy]

On 2019-09-23 1:37 μ.μ., Ryan Sleevi via dev-security-policy wrote:

On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:


On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:

On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
mailto:ji...@it.auth.gr>> wrote:

 

 Using the following practice as described in RFC 6960 should not
 be a violation of the BRs. That is, answering revoked where a
 pre-certificate has been issued but not the final certificate
 should be OK as long as the response contains the Extended Revoked
 extension and the revocationReason is |certificateHold|. With this
 practice, it is very clear that the final certificate has
 not been issued, so would this be considered a violation of the
 Mozilla policy?

Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
responder to return a certificateHold reason in a response for a
precertificate. As you noted, the BRs forbid certificate suspension.
Mozilla assumes that a certificate corresponding to every
precertificate exists, so the OCSP response would be interpreted as
applying to a certificate and thus violating the BRs.

In practice, I also think that Ryan has raised a good point about OCSP
response caching. If a revoked response for a precertificate were
supplied by a CA, would the Subscriber need to wait until that
response expires before using the certificate, or else risk that some
user agent has cached the revoked response?

Dear Wayne,

This list has discussed about compatibility issues several times in the
past, so we must consider how Mozilla supports the majority of clients.
RFC 6960 does not just mandate that the revocationReason is
|certificateHold|. It requires a certain revocation date AND a specific
extension that unambiguously point to a "non-issued" Certificate, not a
"Suspended" Certificate in general. This means that there is technical
language to distinguish the case of a Certificate being "suspended" and
a Certificate being "non-issued".

OCSP response caching is equally problematic for "unknown" responses
which are also cached. The behavior of clients in sight of an "unknown"
or "revoked"-with-additional-info response, should be more or less the
same (i.e. don't trust the certificate).

Neither the Mozilla policy language nor the ||BRs support the assumption
that whenever we have an OCSP response of "certificateHold", this means
the certificate is "Suspended". My interpretation is that if a response
provides all of the following information:
- status --> revoked
- revocation reason --> certificateHold
- revocationTime --> January 1, 1970
- MUST NOT include a CRL references extension or any CRL entry extensions
- includes the extended revoke extension

then this is the consistent semantics for a "non-issued" certificate,
not about a Certificate that was "issued" and then "suspended".

Is this a reasonable interpretation?


I do not believe this is a reasonable interpretation, precisely because
6960 uses this status so that the revocation is temporary, and attackers
can not use this to cause responders to mark serials they have not yet used
as revoked.


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. 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."


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:

> On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
> > On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
> > mailto:ji...@it.auth.gr>> wrote:
> >
> > 
> >
> > Using the following practice as described in RFC 6960 should not
> > be a violation of the BRs. That is, answering revoked where a
> > pre-certificate has been issued but not the final certificate
> > should be OK as long as the response contains the Extended Revoked
> > extension and the revocationReason is |certificateHold|. With this
> > practice, it is very clear that the final certificate has
> > not been issued, so would this be considered a violation of the
> > Mozilla policy?
> >
> > Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
> > responder to return a certificateHold reason in a response for a
> > precertificate. As you noted, the BRs forbid certificate suspension.
> > Mozilla assumes that a certificate corresponding to every
> > precertificate exists, so the OCSP response would be interpreted as
> > applying to a certificate and thus violating the BRs.
> >
> > In practice, I also think that Ryan has raised a good point about OCSP
> > response caching. If a revoked response for a precertificate were
> > supplied by a CA, would the Subscriber need to wait until that
> > response expires before using the certificate, or else risk that some
> > user agent has cached the revoked response?
>
> Dear Wayne,
>
> This list has discussed about compatibility issues several times in the
> past, so we must consider how Mozilla supports the majority of clients.
> RFC 6960 does not just mandate that the revocationReason is
> |certificateHold|. It requires a certain revocation date AND a specific
> extension that unambiguously point to a "non-issued" Certificate, not a
> "Suspended" Certificate in general. This means that there is technical
> language to distinguish the case of a Certificate being "suspended" and
> a Certificate being "non-issued".
>
> OCSP response caching is equally problematic for "unknown" responses
> which are also cached. The behavior of clients in sight of an "unknown"
> or "revoked"-with-additional-info response, should be more or less the
> same (i.e. don't trust the certificate).
>
> Neither the Mozilla policy language nor the ||BRs support the assumption
> that whenever we have an OCSP response of "certificateHold", this means
> the certificate is "Suspended". My interpretation is that if a response
> provides all of the following information:
> - status --> revoked
> - revocation reason --> certificateHold
> - revocationTime --> January 1, 1970
> - MUST NOT include a CRL references extension or any CRL entry extensions
> - includes the extended revoke extension
>
> then this is the consistent semantics for a "non-issued" certificate,
> not about a Certificate that was "issued" and then "suspended".
>
> Is this a reasonable interpretation?


I do not believe this is a reasonable interpretation, precisely because
6960 uses this status so that the revocation is temporary, and attackers
can not use this to cause responders to mark serials they have not yet used
as revoked.

>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Dimitris Zacharopoulos via dev-security-policy]

On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos 
mailto:ji...@it.auth.gr>> wrote:




Using the following practice as described in RFC 6960 should not
be a violation of the BRs. That is, answering revoked where a
pre-certificate has been issued but not the final certificate
should be OK as long as the response contains the Extended Revoked
extension and the revocationReason is |certificateHold|. With this
practice, it is very clear that the final certificate has
not been issued, so would this be considered a violation of the
Mozilla policy?

Yes, I think it would be a violation of Mozilla policy for a CA's OCSP 
responder to return a certificateHold reason in a response for a 
precertificate. As you noted, the BRs forbid certificate suspension. 
Mozilla assumes that a certificate corresponding to every 
precertificate exists, so the OCSP response would be interpreted as 
applying to a certificate and thus violating the BRs.


In practice, I also think that Ryan has raised a good point about OCSP 
response caching. If a revoked response for a precertificate were 
supplied by a CA, would the Subscriber need to wait until that 
response expires before using the certificate, or else risk that some 
user agent has cached the revoked response?


Dear Wayne,

This list has discussed about compatibility issues several times in the 
past, so we must consider how Mozilla supports the majority of clients. 
RFC 6960 does not just mandate that the revocationReason is 
|certificateHold|. It requires a certain revocation date AND a specific 
extension that unambiguously point to a "non-issued" Certificate, not a 
"Suspended" Certificate in general. This means that there is technical 
language to distinguish the case of a Certificate being "suspended" and 
a Certificate being "non-issued".


OCSP response caching is equally problematic for "unknown" responses 
which are also cached. The behavior of clients in sight of an "unknown" 
or "revoked"-with-additional-info response, should be more or less the 
same (i.e. don't trust the certificate).


Neither the Mozilla policy language nor the ||BRs support the assumption 
that whenever we have an OCSP response of "certificateHold", this means 
the certificate is "Suspended". My interpretation is that if a response 
provides all of the following information:

- status --> revoked
- revocation reason --> certificateHold
- revocationTime --> January 1, 1970
- MUST NOT include a CRL references extension or any CRL entry extensions
- includes the extended revoke extension

then this is the consistent semantics for a "non-issued" certificate, 
not about a Certificate that was "issued" and then "suspended".


Is this a reasonable interpretation?

Dimitris.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Curt Spann via dev-security-policy]

Great feedback. This is exactly the type of input needed to get clarity around 
operating OCSP responder services for certificates in the WebPKI ecosystem.

> I think an important part missing from this, overall, is to highlight that 
> these clauses only apply with respect to definitive responses. That is, this 
> only applies to the set of responses for which a pre-certificate exists (and 
> thus a matching certificate is presumed to exist) or for where a certificate 
> actually exists.

Agreed, these clauses need to apply to definitive responses (pre-cert || cert).

> Presuming the OCSP responder supports the requestor CertID algorithm :)

Correct.

> I'm not sure I understand where the "ONLY" clause comes from? 6960 and 5280 
> both presuppose the existence of other sources of revocation, beyond those 
> enumerated within the AIA. For 6960, Section 2.2 leaves this a bit up in the 
> air. So I don't think either the policies or text currently require this 
> "ONLY" clause, but I do think we want to nail down the situations here. As it 
> relates specifically to the (precert || cert) case, the BRs treat the 
> responder as a singular "the", so I don't think the ONLY applies... so I 
> think this whole thing washes out as "not allowed" for the case of (precert 
> || cert), and is met by "unauthorized", as well as possible transport-layer 
> options (RFC 5019 is somewhat silent, AFAICT, on this)

My interpretation incorrectly presumed only OCSP as an option. I was attempting 
to address the NOTE in RFC 6960 from Section 2.2 but I failed to account for 
CRLs:

NOTE: The "revoked" status indicates that a certificate with the
 requested serial number should be rejected, while the "unknown"
 status indicates that the status could not be determined by
 this responder, thereby allowing the client to decide whether
 it wants to try another source of status information (such as a
 CRL). 

> Agreed, with a caveat. This is a MAY derived from Section 2.7, and so I 
> wasn't sure if the suggestion was enumerating it as a MUST ("should be used") 
> or merely acknowledging it as a valid situation for revoked.


I was acknowledging it as a valid situation for revoked and did pull from 
Section 2.7.

> If the assumption of policy is that the existence of a pre-certificate is 
> proof of equivalent issuance, then the only situation this arises is if and 
> only if the CA is running an online signing service in line with 6960, rather 
> than the pre-distribution approach of RFC 5019 that the scale of the Web PKI 
> effectively ensures is necessary, and only in the cases where a 
> pre-certificate /doesn't/ exist.

I must admit I was focused on RFC 6960 and should have been including RFC 5019 
in my interpretation.

> So to recap:
> - In RFC 5019, it's clear that one of the core goals of 5019 is to not 
> require the creation of definitive responses for the entire serial space. So 
> we're only talking (pre-cert || cert) definitive cases.
> - In RFC 6960, it's clear that one of the core goals of the extended response 
> is to leave it /optional/ (MAY) for CAs to respond Revoked, and for serial 
> numbers they have no record of having issued. So we're talking !(pre-cert || 
> cert) cases.

Well said.

- Curt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 20, 2019 at 4:20 PM Curt Spann via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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.
>

I think an important part missing from this, overall, is to highlight that
these clauses only apply with respect to definitive responses. That is,
this only applies to the set of responses for which a pre-certificate
exists (and thus a matching certificate is presumed to exist) or for where
a certificate actually exists.

For situations where neither a pre-certificate nor the actual certificate
exist, a responder isn't required to respond with a definitive response.
This is important to highlight, because the BRs allow for the use of
either/both of the 6960-profile of OCSP, or the 5019 (Lightweight) profile
of OCSP. The latter is important, because it more realistically reflects
what the majority of CAs implement, and we've seen that running online
signing via 6960 is fraught with peril (e.g. Andrew Ayer's excellent
analysis in 2016 -
https://groups.google.com/d/msg/mozilla.dev.security.policy/x3TOIJL7MGw/0fzCI3q3BQAJ
).

In a 5019, the response of "unauthorized" is specifically extended to
account for some of these operational concerns, within Section 2.2.3.

So it was unclear if you were attempting to exhaustively list the statuses
that a CA might generate, or exhaustively list the statuses relevant to the
subset of (pre-cert || cet). For the rest, I'll assume the latter - that
we're only talking about "proof of existence" well, existing.


> 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).
>

Presuming the OCSP responder supports the requestor CertID algorithm :)


> 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.
>

I'm not sure I understand where the "ONLY" clause comes from? 6960 and 5280
both presuppose the existence of other sources of revocation, beyond those
enumerated within the AIA. For 6960, Section 2.2 leaves this a bit up in
the air. So I don't think either the policies or text currently require
this "ONLY" clause, but I do think we want to nail down the situations
here. As it relates specifically to the (precert || cert) case, the BRs
treat the responder as a singular "the", so I don't think the ONLY
applies... so I think this whole thing washes out as "not allowed" for the
case of (precert || cert), and is met by "unauthorized", as well as
possible transport-layer options (RFC 5019 is somewhat silent, AFAICT, on
this)


> 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.
>

Agreed


> 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.
>

Agreed, with a caveat. This is a MAY derived from Section 2.7, and so I
wasn't sure if the suggestion was enumerating it as a MUST ("should be
used") or merely acknowledging it as a valid situation for 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]
>

This is where we get messy, and what I was trying to untangle above.

If the assumption of policy is that the existence of a pre-certificate is
proof of equivalent issuance, then the only situation this arises is if and
only if the CA is running an online signing service in line with 6960,
rather than the pre-distribution approach of RFC 5019 that the scale of the
Web PKI effectively ensures is necessary, and only in the cases where a
pre-certificate /doesn't/ exist.

This isn't entirely pedantry on "issuance" either - as called out in 

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

I'll share this publicly, so that there's no suggestion that personally or
professionally Google Trust Services is treated any differently than any
other CA. As a publicly trusted CA, I personally find this a deeply
disappointing post towards positive engagement. It's disappointing because
it lacks substance and yet makes broad (and negative) claims, and while it
highlights the importance of avoiding a "sub-standard solution", it doesn't
actually offer any meaningful or concrete technical feedback or even
highlight concerns, only an intent to delay discussion.

However, my greatest concern is the misrepresentation about the nature of
requirements and recommendations, which are the /only/ binding thing for a
publicly trusted CA in Mozilla's program. This, coupled with the suggestion
of a "bylaw change" (which is ambiguous as to what is meant here, but might
be presumed to mean a change in a CA/B Forum ballot), is concerning,
because it seems to suggest a movement from a public discussion to a
private discussion, and seems very contrary to the spirit of an open and
productive discussion, and seems to match a tactic used by several
concerning CAs to delay necessary or positive improvements.

Perhaps these aren't intended, and I realize that GTS' involvement in
m.d.s.p. to date has largely been limited to Incident Responses, and so as
a first response, it may still be a learning experience. I know Ryan Hurst
was much more engaged and prolific here, in the past and in an official
capacity, and much more engaged on technical substantive and positive
contributions, and his contributions were often very valuable. I'm glad to
see GTS is, like every other CA in the Mozilla program, following the
conversation, and like some of the CAs in the program, moving to a point
where they actively participate in the discussions. These are good things,
and while some are already required, it's good to see GTS actually step up.
But as a first message, it leaves a lot to be desired, both in terms of
when and in terms of what.

I appreciate the commitment to post and share further details, and look
forward to understanding GTS' concerns. I understand that there can be
challenges in getting approvals, and I can understand and appreciate CAs'
face challenges in public engagement, even though they're publicly trusted.
Yet that should still remain a common expectation of all publicly trusted
CAs. We know that when CAs present it as overly burdensome to engage
publicly, a number of behaviours tend to emerge that are overall harmful to
public trust. I hope you can take this feedback as a positive exhortation
to encourage the good, while highlighting deep concerns with the substance,
approach, and proposals and why it's worked out very poorly over the past
decade+.

If the concern is around extended revoked, I wholly agree there are
concerns there. I'm not sure I'm wholly onboard with Curt's processing
model either, and will respond separately to that, but I think it's a huge
and positive contribution that Curt's made, because it helps provide
something concrete to talk about. However, when there are concerns, it's
better for the discussion to plainly state that, rather than the spectre of
vague concerns. If it's something else, it helps to know what it is, and
I'm not sure a conversation hamstrung by 2-3+ day turnarounds, as currently
seems to be the suggestion, really helps show a CA being agile enough to
lead with good practices.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Andy Warner via dev-security-policy]

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

Re: DigiCert OCSP services returns 1 byte

[Curt Spann via dev-security-policy]

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

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos 
wrote:

> 
>
> Using the following practice as described in RFC 6960 should not be a
> violation of the BRs. That is, answering revoked where a pre-certificate
> has been issued but not the final certificate should be OK as long as the
> response contains the Extended Revoked extension and the revocationReason
> is certificateHold. With this practice, it is very clear that the final
> certificate has
> not been issued, so would this be considered a violation of the Mozilla
> policy?
>
Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
responder to return a certificateHold reason in a response for a
precertificate. As you noted, the BRs forbid certificate suspension.
Mozilla assumes that a certificate corresponding to every precertificate
exists, so the OCSP response would be interpreted as applying to a
certificate and thus violating the BRs.

In practice, I also think that Ryan has raised a good point about OCSP
response caching. If a revoked response for a precertificate were supplied
by a CA, would the Subscriber need to wait until that response expires
before using the certificate, or else risk that some user agent has cached
the revoked response?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 20, 2019 at 9:58 AM Rob Stradling  wrote:

> On 19/09/2019 21:01, Ryan Sleevi wrote:
> 
> > It would be helpful for one of the relevant documents, or another
> > document, or even an errata, to clarify that OCSP services can be
> > offered for pre-certificates.  It’s merely a question of clarifying
> > the technical requirements about how an OCSP service should operate,
> > as those requirements currently can be read to not allow OCSP
> > responses for non-certificates.
> >
> >
> > I'm still not sure I agree with the conflict, which is the key. In
> > either event, we're arguably discussing a profile / the operational
> > constraints specific to a given CA, and not something general with the
> > protocol. Whether or not a pre-certificate is treated as equivalent
> > issuance is, ultimately, a policy question.
>
> Tim, Ryan,
>
> I just started a thread on the TRANS list about this.  Please could I
> ask you to take this discussion there?
>

I've replied there as to why I think it belongs here, and is inappropriate
for there.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 19/09/2019 21:01, Ryan Sleevi wrote:

> It would be helpful for one of the relevant documents, or another
> document, or even an errata, to clarify that OCSP services can be
> offered for pre-certificates.  It’s merely a question of clarifying
> the technical requirements about how an OCSP service should operate,
> as those requirements currently can be read to not allow OCSP
> responses for non-certificates.
> 
> 
> I'm still not sure I agree with the conflict, which is the key. In 
> either event, we're arguably discussing a profile / the operational 
> constraints specific to a given CA, and not something general with the 
> protocol. Whether or not a pre-certificate is treated as equivalent 
> issuance is, ultimately, a policy question.

Tim, Ryan,

I just started a thread on the TRANS list about this.  Please could I 
ask you to take this discussion there?

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 16/09/2019 18:08, Andrew Ayer wrote:
> On Fri, 13 Sep 2019 08:22:21 +
> Rob Stradling via dev-security-policy
>  wrote:
> 
>> Thinking aloud...
>> Does anything need to be clarified in 6962-bis though?
> 
> Yes, it's long past time that we clarified what this means:

Thanks Andrew.  I'll start a thread on the TRANS list to discuss this.

> "This signature indicates the CA's intent to issue the certificate.  This
> intent is considered binding (i.e., misissuance of the precertificate is
> considered equivalent to misissuance of the corresponding certificate)."
> 
> The goal is that a precertificate signature creates an unrebuttable
> presumption that the CA has issued the corresponding certificate. If a
> CA issues a precertificate, outside observers will treat the CA as if
> it had issued the corresponding certificate - whether or not the CA
> really did - so the CA should behave accordingly.
> 
> It's worth explicitly mentioning the implications of this:
> 
> * The CA needs to operate revocation services for the corresponding
> certificate as if the certificate had been issued.
> 
> * If the corresponding certificate would be misissued, the CA will be
> treated as if it had really issued that certificate.
> 
> Are there any other implications that 6962-bis should call out
> explicitly?
> 
> Regards,
> Andrew
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Dimitris Zacharopoulos via dev-security-policy]

Dear Wayne,

According to section 2.2 of RFC 6960, an OCSP responder may respond 
"revoked" for a "non-issued" Certificate. It even allows this response 
for "unknown" Certificates in order to support backwards compatibility 
with implementations of RFC 2560.


In addition to that, section 4.4.8 labeled "Extended Revoked Definition" 
says:


"This extension MUST be included in the OCSP response when that response 
contains a "revoked" status for a non-issued certificate".


Also, from section 2.2 
When a responder sends a "revoked" response to a status request for a 
non-issued certificate, the responder MUST include the extended revoked 
definition response extension (Section 4.4.8) in the response, 
indicating that the OCSP responder supports the extended definition of 
the "revoked" state to also cover non-issued certificates. In addition, 
the SingleResponse related to this non-issued certificate:


1. the responder MUST include the extended revoked definition response
   extension
2. In addition, 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 (Section 4.4.2) or any
   CRL entry extensions (Section 4.4.5).

By reading the BRs (section 6.9.13), it is clear that TLS Certificates 
are not allowed to be "suspended". However, if an RFC 6960 compliant 
OCSP responder responds with "revoked" for an unknown serial number and 
then issues a certificate with the same requested serial number, it will 
later return a response "good". This seems to be an allowed practice 
therefore it should be OK for a responder to change a "revoked" status 
to "good". In addition to that, 6960 demands that for non-issued 
Certificates, the responder must use the revocationReason "certificateHold".


To summarize:

 * The BRs reference RFC 6960
 * The BRs forbid to have Certificates "suspended" (i.e.
   revocationReason |certificateHold|)
 * revoked-for-unknown must contain the Extended Revoked extension, so
   a client knows that this was a response for a non-issued certificate.

Using the following practice as described in RFC 6960 should not be a 
violation of the BRs. That is, answering revoked where a pre-certificate 
has been issued but not the final certificate should be OK as long as 
the response contains the Extended Revoked extension and the 
revocationReason is |certificateHold|. With this practice, it is very 
clear that the final certificate has
not been issued, so would this be considered a violation of the Mozilla 
policy?


I added this as a comment to https://github.com/mozilla/pkipolicy/issues/189
because I know that this mailing list messes up the formatting.


Thanks,
Dimitris.

On 2019-09-19 8:02 μ.μ., Wayne Thayer via dev-security-policy wrote:

I have gone ahead and added a section titled "Precertificates" [1] to the
Required Practices wiki page.

I have also updated a policy issue [2] suggesting that this be moved into
the Root Store policy, and added a new issue [3] suggesting that we clarify
the acceptable use of the "unknown" OCSP response.

I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR
7.1.2.5.

- Wayne

[1]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
[2] https://github.com/mozilla/pkipolicy/issues/138
[3] https://github.com/mozilla/pkipolicy/issues/189

On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer  wrote:


Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
and Ryan's:

The current implementation of Certificate Transparency does not provide

any way for Relying Parties to determine if a certificate corresponding to
a given precertificate has or has not been issued. It is only safe to
assume that a certificate corresponding to every precertificate exists.

RFC 6962 states “The signature on the TBSCertificate indicates the
certificate authority's intent to issue a certificate.  This intent is
considered binding (i.e., misissuance of the Precertificate is considered
equal to misissuance of the final certificate).”

However, BR 7.1.2.5 states “For purposes of clarification, a
Precertificate, as described in RFC 6962 – Certificate Transparency, shall
not be considered to be a “certificate” subject to the requirements of RFC
5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile under these Baseline Requirements.”

Mozilla interprets the BR language as a specific exception allowing CAs
to issue a precertificate containing the same serial number as the
subsequent certificate [1]. Otherwise, Mozilla infers from the existence of
a precertificate that a corresponding certificate has been issued.

This means, for example, that:

* A CA must provide OCSP services and responses in accordance with
Mozilla policy for all certificates presumed to exist based on 

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Thu, Sep 19, 2019 at 2:55 PM Tim Hollebeek 
wrote:

> I also don’t think it’s helpful to try to redefine long-standing and
> well-understood terminology like what it means to issue a certificate.  In
> fact, I just checked, and using a definition like “reserving a serial
> number” causes many of the issuance requirements in RFC 5280 to be
> non-sensical.
>

It was DigiCert that introduced me to this way of thinking, when they
similarly argued that revocation is the process of marking a serial number
revoked within an internal database, rather than the publication of a CRL
or OCSP response.
https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/7hkz9iJDAQAJ


> It would be helpful for one of the relevant documents, or another
> document, or even an errata, to clarify that OCSP services can be offered
> for pre-certificates.  It’s merely a question of clarifying the technical
> requirements about how an OCSP service should operate, as those
> requirements currently can be read to not allow OCSP responses for
> non-certificates.
>

I'm still not sure I agree with the conflict, which is the key. In either
event, we're arguably discussing a profile / the operational constraints
specific to a given CA, and not something general with the protocol.
Whether or not a pre-certificate is treated as equivalent issuance is,
ultimately, a policy question.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

I think “IETF does not define policy” is about as true as “individuals 
represent themselves at IETF.”  But that’s a longer rathole.

 

I also don’t think it’s helpful to try to redefine long-standing and 
well-understood terminology like what it means to issue a certificate.  In 
fact, I just checked, and using a definition like “reserving a serial number” 
causes many of the issuance requirements in RFC 5280 to be non-sensical.

 

It would be helpful for one of the relevant documents, or another document, or 
even an errata, to clarify that OCSP services can be offered for 
pre-certificates.  It’s merely a question of clarifying the technical 
requirements about how an OCSP service should operate, as those requirements 
currently can be read to not allow OCSP responses for non-certificates.

 

Not sure what reason there would be to oppose such a simple clarification that 
aligns the relevant requirements with the desired policy, especially since it 
is backwards compatible.

 

-Tim

 

From: Ryan Sleevi  
Sent: Thursday, September 19, 2019 2:17 PM
To: Tim Hollebeek 
Cc: Rob Stradling ; Alex Cohn ; 
mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 
; Jeremy Rowley 
Subject: Re: DigiCert OCSP services returns 1 byte

 

 

 

On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

I think that's fine as Mozilla and/or the CABF can and should override RFCs 
when it makes sense to do so, but I think it would also be helpful in the long 
term to fix the discrepancy, especially as CT is likely to be used in more 
certificate ecosystems in the future.

 

Isn't the core tenet that the IETF does not define policy? This seems very well 
rooted in policy, as you note.

 

The question does not seem to be about whether or not 
precertificates-are-certificates (and, in a -bis world, they're clearly a 
SignedData-thing-that-isn't), but what constitutes the act of issuance: is it 
signing a thing (whether a TBSCertificate or something other, like a 
precertificate under 6962 or 6962-bis)? Is it reserving the serial number and 
assigning it in the system?

 

In any event, if/when CT is used in other systems, they'll be using different 
CT logs, so they'll really be entirely different ecosystems. It seems that the 
policy management authority (i.e. the equivalent to browsers, in the Web PKI) 
for those ecosystems can provide clarity, and it further emphasizes why a 
single CA certificate should not participate in multiple PMAs, to reduce the 
risk of and avoid conflicts and/or misunderstandings.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think that's fine as Mozilla and/or the CABF can and should override
> RFCs when it makes sense to do so, but I think it would also be helpful in
> the long term to fix the discrepancy, especially as CT is likely to be used
> in more certificate ecosystems in the future.


Isn't the core tenet that the IETF does not define policy? This seems very
well rooted in policy, as you note.

The question does not seem to be about whether or not
precertificates-are-certificates (and, in a -bis world, they're clearly a
SignedData-thing-that-isn't), but what constitutes the act of issuance: is
it signing a thing (whether a TBSCertificate or something other, like a
precertificate under 6962 or 6962-bis)? Is it reserving the serial number
and assigning it in the system?

In any event, if/when CT is used in other systems, they'll be using
different CT logs, so they'll really be entirely different ecosystems. It
seems that the policy management authority (i.e. the equivalent to
browsers, in the Web PKI) for those ecosystems can provide clarity, and it
further emphasizes why a single CA certificate should not participate in
multiple PMAs, to reduce the risk of and avoid conflicts and/or
misunderstandings.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

> Thanks Wayne.  You're right.
>
> (I read the "SHOULD NOT" requirement, forgot it had been superseded, and
> didn't read further.  I wonder if it would be reasonable to remove the
> superseded requirement from the BRs now, given that it was superseded over
> 6 years ago?)

Removing out of date requirements was one of the things I did in my spring 
cleanup branch, but I don't know if I caught this one.  There's some even 
older, more obsolete text in there.

-Tim


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

Sorry for being unclear.

If the IETF goes the direction of "pre-certificates are not certificates", then 
we find ourselves in a world where the RFCs say that they should not get OCSP 
services, but Mozilla policy (and potentially the BRs) says that they should.

I think that's fine as Mozilla and/or the CABF can and should override RFCs 
when it makes sense to do so, but I think it would also be helpful in the long 
term to fix the discrepancy, especially as CT is likely to be used in more 
certificate ecosystems in the future.

Note that this doesn't mean that CT-bis has to state that pre-certificates are 
certificates, but it (or something later, or another draft ...) should at 
mention that OCSP responses for pre-certificates are allowed.

-Tim

> -Original Message-
> From: Rob Stradling 
> Sent: Monday, September 16, 2019 5:28 AM
> To: Tim Hollebeek 
> Cc: Jeremy Rowley ; Alex Cohn
> ; mozilla-dev-security-pol...@lists.mozilla.org; Wayne
> Thayer 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On 13/09/2019 19:24, Tim Hollebeek wrote:
> > Yes, but I think this clarifies things in the wrong direction.
> 
> Hi Tim.  I'm not clear what you mean.
> 
> I was talking specifically and only about what IETF could/should do regarding
> this matter.  Which part did you disagree with, and why?
> 
> > -Tim
> >
> >> -Original Message-
> >> From: Rob Stradling 
> >> Sent: Friday, September 13, 2019 4:22 AM
> >> To: Tim Hollebeek ; Jeremy Rowley
> >> ; Alex Cohn 
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >> 
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> >> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> >>> So, this is something that would be helpfully clarified via either
> >>> an IETF draft,
> >>
> >> There's already a 6962-bis draft [1] in IESG Last Call, which (when
> >> we finally complete it!) will obsolete RFC6962.  6962-bis redefines
> >> precertificates so that they're not actually X.509 certificates.
> >> Therefore, I don't think a "clarify RFC6962" draft is necessary.
> >>
> >> Thinking aloud...
> >> Does anything need to be clarified in 6962-bis though?
> >> A (non-X.509) 6962-bis precertificate contains the serial number that
> >> will appear in the certificate (if or when that certificate is
> >> issued),
> >> so: Should the CA be forbidden, permitted or required to operate
> >> revocation services for that serial number once the 6962-bis
> >> precertificate has been produced but before the certificate has been
> >> issued?  (And is this a technical matter for 6962-bis to address, or
> >> a policy matter that's out of scope for the 6962-bis document?)
> >>
> >>
> >> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> >>
> >>> or clarifications in the BRs.  There are various things in the OCSP
> >>> RFCs and
> >> even the BRs that can be read as precluding good OCSP responses for
> >> pre- certificates, although the situation is unclear since the
> >> relevant sections are blissfully ignorant of CT, and the correct
> >> behavior here was unfortunately left out of RFC 6962, which should have
> clarified this.
> >>>
> >>> Happy to help draft something.  There are some interesting
> >>> complexities
> >> once you dig deeper.
> >>>
> >>> -Tim
> >>>
> >>>> -Original Message-
> >>>> From: dev-security-policy
> >>>>  On Behalf Of Jeremy
> >>>> Rowley via dev-security-policy
> >>>> Sent: Thursday, September 12, 2019 1:46 PM
> >>>> To: Alex Cohn 
> >>>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >>>> 
> >>>> Subject: RE: DigiCert OCSP services returns 1 byte
> >>>>
> >>>> The language says you have to provide the response for the cert as
> >>>> if it exists, but the reality is that sending a response for the
> >>>> precert is the same as calculating the result for the certificate
> >>>> as if it exists and sending that. They are the same thing because
> >>>> the precert is treated the same as the final cert if the final cert 
> >>>> doesn’t
> exist.
> >>>>
> >>>> I believe the intent is that a CT-naïve OCSP checker would work
> >>>> normally when presented with a precert

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

I have gone ahead and added a section titled "Precertificates" [1] to the
Required Practices wiki page.

I have also updated a policy issue [2] suggesting that this be moved into
the Root Store policy, and added a new issue [3] suggesting that we clarify
the acceptable use of the "unknown" OCSP response.

I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR
7.1.2.5.

- Wayne

[1]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
[2] https://github.com/mozilla/pkipolicy/issues/138
[3] https://github.com/mozilla/pkipolicy/issues/189

On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer  wrote:

> Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
> and Ryan's:
>
> The current implementation of Certificate Transparency does not provide
>> any way for Relying Parties to determine if a certificate corresponding to
>> a given precertificate has or has not been issued. It is only safe to
>> assume that a certificate corresponding to every precertificate exists.
>>
>> RFC 6962 states “The signature on the TBSCertificate indicates the
>> certificate authority's intent to issue a certificate.  This intent is
>> considered binding (i.e., misissuance of the Precertificate is considered
>> equal to misissuance of the final certificate).”
>>
>> However, BR 7.1.2.5 states “For purposes of clarification, a
>> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
>> not be considered to be a “certificate” subject to the requirements of RFC
>> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
>> Revocation List (CRL) Profile under these Baseline Requirements.”
>>
>> Mozilla interprets the BR language as a specific exception allowing CAs
>> to issue a precertificate containing the same serial number as the
>> subsequent certificate [1]. Otherwise, Mozilla infers from the existence of
>> a precertificate that a corresponding certificate has been issued.
>>
>> This means, for example, that:
>>
>> * A CA must provide OCSP services and responses in accordance with
>> Mozilla policy for all certificates presumed to exist based on the presence
>> of a Precertificate, even if the certificate does not actually exist
>> * A CA must be able to revoke a certificate presumed to exist, if
>> revocation of the certificate is required under Mozilla policy, even if the
>> certificate does not actually exist.
>> * If any corresponding certificate with the same serial number and issuer
>> exists, and can not be verified to match the precertificate using the
>> algorithms in RFC 6962, it will be considered misissued.
>> * In examining historical issuance, the CA must consider both final
>> certificates and precertificates, even if the precertificate did not
>> ultimately result in the issuance of a certificate.
>>
>
> I propose adding this language to our "Required Practices" wiki page [2],
> then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
> serial numbers. That still leaves some uncertainty about the use of the
> "unknown" response for precertificates (and in general), although Ryan made
> some good points about why using this status beyond the very narrow scope
> described in RFC 6960 section 2.2 is a bad idea.
>
> Once again, I will greatly appreciate your feedback on this topic. Since
> this is a practice and not official policy, I'll go ahead and update the
> wiki when I sense that we're in agreement here.
>
> - Wayne
>
> [1] https://cabforum.org/pipermail/public/2014-January/002694.html
> [2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
>
> On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>>
>> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org > dev-security-policy@lists.mozilla.org>> wrote:
>> >
>> >>
>> >>
>> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> >> dev-security-policy@lists.mozilla.org> wrote:
>> >>>
>> >>> Hi Kurt.  I agree, hence why I proposed:
>> >>>
>> >>>  "- I would also like to see BR 4.9.10 revised to say something
>> roughly
>> >>> along these lines:
>> >>>   'If the OCSP responder receives a status request for a serial number
>> >>>that has not been allocated by the CA, then the responder SHOULD
>> NOT
>> >>>respond with a "good" status.’"
>> >>
>> >> I suppose one issue there is for CAs which allocate the serial number
>> very
>> >> early on in the issuance workflow - signing a dummy certificate with an
>> >> untrusted key, for instance, but not committing the CA to actually
>> >> producing either a pre-certificate or certificate (e.g, because the
>> >> applicant has insufficient funds to complete the process). It would not
>> >> seem correct to start answering 

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Thanks Curt. Reading between the lines of Ryan's and your response, I'm
thinking that we should specifically ban or limit the scope of "unknown"
responses somewhere - perhaps in the BRs. Otherwise I think RFC 6960 leaves
some room for a CA to argue that they are permitted to use that response in
situations such as the one you described.

On Wed, Sep 18, 2019 at 3:48 PM Curt Spann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> My interpretation is once a precertificate has been signed with the
> issuing CA key the corresponding OCSP service should only respond with
> "good" or "revoked". In this case an "unknown" response indicates the
> specific serial number for the issuing CA has not been assigned which isn’t
> the case. Since the serial number has been assigned the OCSP responder
> should know about the status of that serial number for the issuing CA. If
> there are no issues with the precertificate that would require its
> revocation the OCSP responder should respond with “good”. If the
> precertificate is classified as a misissuance (or any other reason that
> would require revocation) the OCSP responder should respond with “revoked”.
>
> - Curt
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Curt Spann via dev-security-policy]

My interpretation is once a precertificate has been signed with the issuing CA 
key the corresponding OCSP service should only respond with "good" or 
"revoked". In this case an "unknown" response indicates the specific serial 
number for the issuing CA has not been assigned which isn’t the case. Since the 
serial number has been assigned the OCSP responder should know about the status 
of that serial number for the issuing CA. If there are no issues with the 
precertificate that would require its revocation the OCSP responder should 
respond with “good”. If the precertificate is classified as a misissuance (or 
any other reason that would require revocation) the OCSP responder should 
respond with “revoked”.

- Curt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
and Ryan's:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
> However, BR 7.1.2.5 states “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a precertificate containing the same serial number as the subsequent
> certificate [1]. Otherwise, Mozilla infers from the existence of a
> precertificate that a corresponding certificate has been issued.
>
> This means, for example, that:
>
> * A CA must provide OCSP services and responses in accordance with Mozilla
> policy for all certificates presumed to exist based on the presence of a
> Precertificate, even if the certificate does not actually exist
> * A CA must be able to revoke a certificate presumed to exist, if
> revocation of the certificate is required under Mozilla policy, even if the
> certificate does not actually exist.
> * If any corresponding certificate with the same serial number and issuer
> exists, and can not be verified to match the precertificate using the
> algorithms in RFC 6962, it will be considered misissued.
> * In examining historical issuance, the CA must consider both final
> certificates and precertificates, even if the precertificate did not
> ultimately result in the issuance of a certificate.
>

I propose adding this language to our "Required Practices" wiki page [2],
then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
serial numbers. That still leaves some uncertainty about the use of the
"unknown" response for precertificates (and in general), although Ryan made
some good points about why using this status beyond the very narrow scope
described in RFC 6960 section 2.2 is a bad idea.

Once again, I will greatly appreciate your feedback on this topic. Since
this is a practice and not official policy, I'll go ahead and update the
wiki when I sense that we're in agreement here.

- Wayne

[1] https://cabforum.org/pipermail/public/2014-January/002694.html
[2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>> wrote:
> >
> >>
> >>
> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>>
> >>> Hi Kurt.  I agree, hence why I proposed:
> >>>
> >>>  "- I would also like to see BR 4.9.10 revised to say something roughly
> >>> along these lines:
> >>>   'If the OCSP responder receives a status request for a serial number
> >>>that has not been allocated by the CA, then the responder SHOULD NOT
> >>>respond with a "good" status.’"
> >>
> >> I suppose one issue there is for CAs which allocate the serial number
> very
> >> early on in the issuance workflow - signing a dummy certificate with an
> >> untrusted key, for instance, but not committing the CA to actually
> >> producing either a pre-certificate or certificate (e.g, because the
> >> applicant has insufficient funds to complete the process). It would not
> >> seem correct to start answering (affirmatively) OCSP requests where no
> >> artefact has been signed by a trusted key.
> >>
> >
> > Why does a CA need to sign something to allocate a serial? Could you
> expand
> > a bit more on that?
> >
>
> Yes - on further consideration, I could have been a lot clearer. I didn’t
> mean that a CA _has_ to sign something to allocate a serial in some
> internal database; merely that the allocation of a serial number, in
> itself, isn’t the trigger (in my opinion, of course) for any OCSP server to
> start responding to the (Issuer, Serial Number) request with successful
> response codes.
>
> What I meant was that some workflows allocate a serial number, sign a
> dummy certificate containing that serial number (with an untrusted key),
> which then 

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org 
> > wrote:
> 
>> 
>> 
>>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> Hi Kurt.  I agree, hence why I proposed:
>>> 
>>>  "- I would also like to see BR 4.9.10 revised to say something roughly
>>> along these lines:
>>>   'If the OCSP responder receives a status request for a serial number
>>>that has not been allocated by the CA, then the responder SHOULD NOT
>>>respond with a "good" status.’"
>> 
>> I suppose one issue there is for CAs which allocate the serial number very
>> early on in the issuance workflow - signing a dummy certificate with an
>> untrusted key, for instance, but not committing the CA to actually
>> producing either a pre-certificate or certificate (e.g, because the
>> applicant has insufficient funds to complete the process). It would not
>> seem correct to start answering (affirmatively) OCSP requests where no
>> artefact has been signed by a trusted key.
>> 
> 
> Why does a CA need to sign something to allocate a serial? Could you expand
> a bit more on that?
> 

Yes - on further consideration, I could have been a lot clearer. I didn’t mean 
that a CA _has_ to sign something to allocate a serial in some internal 
database; merely that the allocation of a serial number, in itself, isn’t the 
trigger (in my opinion, of course) for any OCSP server to start responding to 
the (Issuer, Serial Number) request with successful response codes.

What I meant was that some workflows allocate a serial number, sign a dummy 
certificate containing that serial number (with an untrusted key), which then 
flows through with linting checks, and so on. But the decision to sign the said 
certificate with a trusted key has not yet been made (officially). But when any 
object (precertificate, certificate) containing that allocated serial number 
gets signed with a trusted key, it is a reasonable expectation for relying 
parties to be able to query OCSP services and not get a “Never heard of it” 
answer (whether that’s a RFC 6960 4.4.8 response, or an “unauthorized”, or 
whatever).

In other words, Rob’s original language which refers purely to the 
(CA-internal) allocation of the serial number as the triggering event seems not 
to cover all relevant cases. Not that I’ve been able to come up with any better 
language, I should add.

Regards,

Neil
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > Hi Kurt.  I agree, hence why I proposed:
> >
> >   "- I would also like to see BR 4.9.10 revised to say something roughly
> > along these lines:
> >'If the OCSP responder receives a status request for a serial number
> > that has not been allocated by the CA, then the responder SHOULD NOT
> > respond with a "good" status.’"
>
> I suppose one issue there is for CAs which allocate the serial number very
> early on in the issuance workflow - signing a dummy certificate with an
> untrusted key, for instance, but not committing the CA to actually
> producing either a pre-certificate or certificate (e.g, because the
> applicant has insufficient funds to complete the process). It would not
> seem correct to start answering (affirmatively) OCSP requests where no
> artefact has been signed by a trusted key.
>

Why does a CA need to sign something to allocate a serial? Could you expand
a bit more on that?


> It seems to me that the trigger point to start answering OCSP requests for
> a (Issuer, Serial Number) request would be when the serial number has been
> allocated AND an artefact has been signed by an issuer private key.
>
> In other words, a CA might well allocate a serial number, which, if all
> goes well, will find its way into a certificate; but until a publicly
> trusted signature has been made on a TBSCertificate containing that serial
> number, an OCSP responder is behaving properly were it to answer “Never
> heard of that serial number for that Issuer”.
>

I'm not sure I follow why that seems to be?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy 
>  wrote:
> 
> Hi Kurt.  I agree, hence why I proposed:
> 
>   "- I would also like to see BR 4.9.10 revised to say something roughly
> along these lines:
>'If the OCSP responder receives a status request for a serial number
> that has not been allocated by the CA, then the responder SHOULD NOT
> respond with a "good" status.’"

I suppose one issue there is for CAs which allocate the serial number very 
early on in the issuance workflow - signing a dummy certificate with an 
untrusted key, for instance, but not committing the CA to actually producing 
either a pre-certificate or certificate (e.g, because the applicant has 
insufficient funds to complete the process). It would not seem correct to start 
answering (affirmatively) OCSP requests where no artefact has been signed by a 
trusted key.

It seems to me that the trigger point to start answering OCSP requests for a 
(Issuer, Serial Number) request would be when the serial number has been 
allocated AND an artefact has been signed by an issuer private key.

In other words, a CA might well allocate a serial number, which, if all goes 
well, will find its way into a certificate; but until a publicly trusted 
signature has been made on a TBSCertificate containing that serial number, an 
OCSP responder is behaving properly were it to answer “Never heard of that 
serial number for that Issuer”.

Regards,

Neil
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 17/09/2019 08:01, Kurt Roeckx via dev-security-policy wrote:
> On 2019-09-16 14:02, Rob Stradling wrote:
>>
>> ISTM that this "certificate presumed to exist" concept doesn't play
>> nicely with the current wording of BR 4.9.10:
>>     'If the OCSP responder receives a request for status of a certificate
>>  that has not been issued, then the responder SHOULD NOT respond with
>>  a "good" status.'
>>
>> If a certificate (with embedded SCTs and no CT poison extension) is
>> "presumed to exist" but the CA has not actually issued it, then to my
>> mind that's a "certificate that has not been issued"; and therefore, the
>> OCSP 'responder SHOULD NOT respond with a "good" status'.
> 
> The problem of course is that you don't query OCSP about a certificate, 
> you query it about a serial number. And that serial number has been 
> issued. So maybe the BRs should say serial number instead of certificate?

Hi Kurt.  I agree, hence why I proposed:

   "- I would also like to see BR 4.9.10 revised to say something roughly
along these lines:
'If the OCSP responder receives a status request for a serial number
 that has not been allocated by the CA, then the responder SHOULD NOT
 respond with a "good" status.'"

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 16/09/2019 23:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote:

> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in
> question:
>     (1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
>     (2) SHOULD NOT respond "good" (see BR 4.9.10).
> 
> If I'm reading BR 4.9.10 correctly, the situation is worse because it 
> goes on to state "Effective 1 August 2013, OCSP responders for CAs which 
> are not Technically Constrained in line with Section 7.1.5 MUST NOT 
> respond with a "good" status for such certificates." (referring to 
> 'certificates that have not been issued' from the prior paragraph)

Thanks Wayne.  You're right.

(I read the "SHOULD NOT" requirement, forgot it had been superseded, and 
didn't read further.  I wonder if it would be reasonable to remove the 
superseded requirement from the BRs now, given that it was superseded 
over 6 years ago?)

> If the desired outcome is for CAs to respond "good" to a precertificate 
> without a corresponding certificate, we could override the BRs in 
> Mozilla policy, but I'd want to get the BRs updated quickly as Rob 
> suggested to avoid audit findings.

+1

> The other piece of this policy that's still unclear to me relates to the 
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA 
> to provide an "unknown" OCSP response for an issued certificate? If not, 
> should it be? The implication here would be that CAs responding 
> "unknown" to precertificates without corresponding certificates are 
> doing the right thing, despite prior precedent indicating that this is a 
> violation. [1]

This is making my brain hurt.

> - Wayne
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
> 
> Clearly that's impossible, which leads to the question: Which of these
> two conflicting requirements should a CA ignore in order to be as
> un-non-compliant as possible?  Which leads me to BR 7.1.2.5
> :
>     'For purposes of clarification, a Precertificate, as described
> in RFC
>      6962 – Certificate Transparency, shall not be considered to be a
>      “certificate” subject to the requirements of RFC 5280'
> 
> Since the first mention of "certificates" in the OCSP Protocol Overview
> (RFC6960 section 2) cross-references RFC5280, I believe that this
> 'shall
> not be considered to be a "certificate"' declaration can be assumed to
> extend to the OCSP requirements too.  And therefore, the balance tilts
> in favour of implementing 'SHOULD NOT respond "good"' and ignoring
> 'MUST
> respond "good"'.
> 
> I can't say I like this conclusion, but nonetheless it is the
> conclusion
> that my reading of the BRs forces me to reach.  I realize that what the
> BRs actually say may not reflect precisely what was intended by
> CABForum; nonetheless, CAs are measured by what the BRs actually say.
> 
> IDEAS FOR FIXING IT:
> 
> Long-term:
>     - In CT v2 (6962-bis), precertificates are not X.509 certificates,
> which removes Schrödinger from the equation.  :-)
> 
> Short-term:
>     - I think BR 7.1.2.5, as written, is decidedly unhelpful and should
> be revised to have a much smaller scope.  Surely only the serial number
> uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
> not the entirety of RFC5280?
>     - I would also like to see BR 4.9.10 revised to say something
> roughly
> along these lines:
>     'If the OCSP responder receives a status request for a serial number
>      that has not been allocated by the CA, then the responder
> SHOULD NOT
>      respond with a "good" status.'
> 
> P.S. Full disclosure: Sectigo currently provides an (unsigned)
> "unauthorized" OCSP response when a precert exists but the
> corresponding
> cert doesn't, but in all honesty I'm not currently persuaded that an
> Incident Report is warranted.
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com 
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 16, 2019 at 6:59 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling  wrote:
>
> > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> > 
> >
> > If a certificate (with embedded SCTs and no CT poison extension) is
> > "presumed to exist" but the CA has not actually issued it, then to my
> > mind that's a "certificate that has not been issued"; and therefore, the
> > OCSP 'responder SHOULD NOT respond with a "good" status'.
> >
> > However, this is Schrödinger's "certificate that has not been issued",
> > because a Precertificate has been issued that has the same serial number
> > (as the "certificate presumed to exist" that doesn't actually exist).
> >
> > And so at this point ISTM that the OCSP responder is expected to
> > implement two conflicting requirements for the serial number in question:
> >(1) MUST respond "good", because an unrevoked/unexpired
> > precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> > response).
> >(2) SHOULD NOT respond "good" (see BR 4.9.10).
> >
> >
> If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
> on to state "Effective 1 August 2013, OCSP responders for CAs which are not
> Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
> "good" status for such certificates." (referring to 'certificates that have
> not been issued' from the prior paragraph)
>
> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in Mozilla
> policy, but I'd want to get the BRs updated quickly as Rob suggested to
> avoid audit findings.
>

We've had CAs argue, for better or worse, that they've "revoked" a
certificate by setting a revoked flag within their database, which then
will eventually result in the production of CRLs and signed OCSP responses
to reflect that status, and then distribute those responses to their CDNs
for the distribution points. In this model, the CA is arguing "revoked" is
on the basis of a change within their database, rather than the artifacts
produced from such a change. Some have even had online services (via HTML
forms) where you could check specific serial numbers, with CAPTCHAs, to
compare the database vs the produced/signed artifacts.

Similarly, we've had CAs argue that they've had certificates that were
issued, but were not active, based on a status change in their database,
where 'active' meant that they signed the certificate. This again suggests
a flow where "issued" is the status of committing to the database, rather
than producing the signed artifact.

For better or worse, if we accept that definition, which admittedly opens a
new set of issues to work through, the act of assigning the serial number
and TBSCertificate is the act of issuance, rather than the production of
the signed artifact. For better or worse, the BRs support as much with the
discussion of revocation, because the CAs that argued this highlighted that
the act of distributing OCSP/CRL responses is "publishing" the revocation
(hence the language in 4.9.5 regarding timeframes, and the language in
4.9.7 about publishing CRLs).

Recall that these issues highlighted here were not new or unexpected. If
you dig through the discussion of Ballot 134, you'll find Brian Smith
rightfully flagged these issues, which were the result of somewhat rushed
attempts to get language in the BRs. Much like Qualified Auditors within
Policy, it may be worth treating this as an exception and being deliberate
in how any matters of note or qualifications are treated, while better
language is proposed?

You can find the past discussion at
https://cabforum.org/pipermail/public/2014-September/003930.html . Brian
Smith, formerly of Mozilla, highlighted issues with the attempts to carve
out just duplicate serials, perhaps best in
https://cabforum.org/pipermail/public/2014-September/004006.html

If you look at that past discussion, you can also see debates about the
ASN.1 / SignedData approach being used, and how Precerts-are-not-Certs in
the same way that OCSPResponses-are-not-certs, even if all three used the
SignedData construct, is another interpretation, at which point, this issue
also washes out. You can also find discussions of alternative approaches,
which specified the exact encoding conditions in which a duplicate serial
would be permitted (treating precerts-as-actually-certs, rather than
precerts-as-committments-of-equivalent-certs)


> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
> provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding "unknown"
> to precertificates without corresponding certificates are doing the right
> thing, despite prior precedent indicating that 

Re: DigiCert OCSP services returns 1 byte

[Kurt Roeckx via dev-security-policy]

On 2019-09-16 14:02, Rob Stradling wrote:


ISTM that this "certificate presumed to exist" concept doesn't play
nicely with the current wording of BR 4.9.10:
'If the OCSP responder receives a request for status of a certificate
 that has not been issued, then the responder SHOULD NOT respond with
 a "good" status.'

If a certificate (with embedded SCTs and no CT poison extension) is
"presumed to exist" but the CA has not actually issued it, then to my
mind that's a "certificate that has not been issued"; and therefore, the
OCSP 'responder SHOULD NOT respond with a "good" status'.


The problem of course is that you don't query OCSP about a certificate, 
you query it about a serial number. And that serial number has been 
issued. So maybe the BRs should say serial number instead of certificate?



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Jakob Bohm via dev-security-policy]

On 17/09/2019 00:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling  wrote:
> 
>> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
>> 
>>
>> If a certificate (with embedded SCTs and no CT poison extension) is
>> "presumed to exist" but the CA has not actually issued it, then to my
>> mind that's a "certificate that has not been issued"; and therefore, the
>> OCSP 'responder SHOULD NOT respond with a "good" status'.
>>
>> However, this is Schrödinger's "certificate that has not been issued",
>> because a Precertificate has been issued that has the same serial number
>> (as the "certificate presumed to exist" that doesn't actually exist).
>>
>> And so at this point ISTM that the OCSP responder is expected to
>> implement two conflicting requirements for the serial number in question:
>> (1) MUST respond "good", because an unrevoked/unexpired
>> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
>> response).
>> (2) SHOULD NOT respond "good" (see BR 4.9.10).
>>
>>
> If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
> on to state "Effective 1 August 2013, OCSP responders for CAs which are not
> Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
> "good" status for such certificates." (referring to 'certificates that have
> not been issued' from the prior paragraph)
> 
> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in Mozilla
> policy, but I'd want to get the BRs updated quickly as Rob suggested to
> avoid audit findings.
> 
> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
> provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding "unknown"
> to precertificates without corresponding certificates are doing the right
> thing, despite prior precedent indicating that this is a violation. [1]
> 

In any networked system, delays are inevitable.

If data (in this case replication status data) is to be reliably
replicated, there will be a further delay to ensure that bad data is
not forced onto all mirrors too quickly (Consider earlier incident(s)
where corrupted revocation data was rolled out to all the servers used
by a CA.  Also consider the delay in the recent rollout of incident-
initiated revocations by GTS).

Thus it is technically inevitable that some revocation servers will
respond "unknown" for a freshly issued (as in signed) certificate.

So the real question is which of the various steps in a CT-logged
issuance are allowed to happen while the certificate status is
replicated to all the OCSP and CRL servers operated by a CA.

It is of cause possible to pretend that a signed but not yet submitted
certificate and/or preCertificate doesn't exist, creating a strict
serialization of steps:

  1. Allocate serial number and other content.
  2. Replicate this allocation to survive crashes.
  3. Sign the preCertificate, canned "good" OCSP responses and a fresh
CRL (if the CRL contains extensions describing the valid serial
numbers).
  4. Replicate the preCertificate and OCSP responses to survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature).
  5. Wait for all those OCSP responses and CRLs to reach all mirrors.
  6. Record the completion of this rollout in the replicated dataset.
  7. Submit the preCertificate to CT logs (which unnecessarily check
that the mirrors report "good" instead of "unknown" according to
the strict policy);
  8. Wait for all the CT logs to return SCTs.
  9. Replicate the SCTs to survive crashes.
(failure during this step will require extracting SCTs from the
CT logs or revoking the preCertificate and starting over).
 10. Sign the actual certificate and any further canned OCSP responses
   and CRLs that refer to the contents or signature of the actual
   certificate.
 11. Replicate the actual certificate and any new revocation data to
   survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature,
alternatively revoke and start over).
 12. Wait for any such OCSP responses and CRLs to reach all mirrors.
 13. Record the completion of this rollout in the replicated dataset.
(Failure during this step results in having to check the rollout 
status again).
 14. Submit the actual certificate to CT logs and await acknowledgement.
 15. Finally send the actual certificate to the subscriber.

My alternative 4 paragraph proposal (rest was rationale) was to accept
the existence of delays, aim for eventual consistency, maximize overlap
between the operations by allowing the initial CT submission to happen
before all revocation 

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling  wrote:

> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> 
>
> If a certificate (with embedded SCTs and no CT poison extension) is
> "presumed to exist" but the CA has not actually issued it, then to my
> mind that's a "certificate that has not been issued"; and therefore, the
> OCSP 'responder SHOULD NOT respond with a "good" status'.
>
> However, this is Schrödinger's "certificate that has not been issued",
> because a Precertificate has been issued that has the same serial number
> (as the "certificate presumed to exist" that doesn't actually exist).
>
> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in question:
>(1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
>(2) SHOULD NOT respond "good" (see BR 4.9.10).
>
>
If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
on to state "Effective 1 August 2013, OCSP responders for CAs which are not
Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
"good" status for such certificates." (referring to 'certificates that have
not been issued' from the prior paragraph)

If the desired outcome is for CAs to respond "good" to a precertificate
without a corresponding certificate, we could override the BRs in Mozilla
policy, but I'd want to get the BRs updated quickly as Rob suggested to
avoid audit findings.

The other piece of this policy that's still unclear to me relates to the
"unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
provide an "unknown" OCSP response for an issued certificate? If not,
should it be? The implication here would be that CAs responding "unknown"
to precertificates without corresponding certificates are doing the right
thing, despite prior precedent indicating that this is a violation. [1]

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390


> Clearly that's impossible, which leads to the question: Which of these
> two conflicting requirements should a CA ignore in order to be as
> un-non-compliant as possible?  Which leads me to BR 7.1.2.5:
>'For purposes of clarification, a Precertificate, as described in RFC
> 6962 – Certificate Transparency, shall not be considered to be a
> “certificate” subject to the requirements of RFC 5280'
>
> Since the first mention of "certificates" in the OCSP Protocol Overview
> (RFC6960 section 2) cross-references RFC5280, I believe that this 'shall
> not be considered to be a "certificate"' declaration can be assumed to
> extend to the OCSP requirements too.  And therefore, the balance tilts
> in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST
> respond "good"'.
>
> I can't say I like this conclusion, but nonetheless it is the conclusion
> that my reading of the BRs forces me to reach.  I realize that what the
> BRs actually say may not reflect precisely what was intended by
> CABForum; nonetheless, CAs are measured by what the BRs actually say.
>
> IDEAS FOR FIXING IT:
>
> Long-term:
>- In CT v2 (6962-bis), precertificates are not X.509 certificates,
> which removes Schrödinger from the equation.  :-)
>
> Short-term:
>- I think BR 7.1.2.5, as written, is decidedly unhelpful and should
> be revised to have a much smaller scope.  Surely only the serial number
> uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
> not the entirety of RFC5280?
>- I would also like to see BR 4.9.10 revised to say something roughly
> along these lines:
>'If the OCSP responder receives a status request for a serial number
> that has not been allocated by the CA, then the responder SHOULD NOT
> respond with a "good" status.'
>
> P.S. Full disclosure: Sectigo currently provides an (unsigned)
> "unauthorized" OCSP response when a precert exists but the corresponding
> cert doesn't, but in all honesty I'm not currently persuaded that an
> Incident Report is warranted.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 16, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 16/09/2019 19:08, Andrew Ayer wrote:
> > On Fri, 13 Sep 2019 08:22:21 +
> > Rob Stradling via dev-security-policy
> >  wrote:
> >
> >> Thinking aloud...
> >> Does anything need to be clarified in 6962-bis though?
> >
> > Yes, it's long past time that we clarified what this means:
> >
> > "This signature indicates the CA's intent to issue the certificate.  This
> > intent is considered binding (i.e., misissuance of the precertificate is
> > considered equivalent to misissuance of the corresponding certificate)."
> >
> > The goal is that a precertificate signature creates an unrebuttable
> > presumption that the CA has issued the corresponding certificate. If a
> > CA issues a precertificate, outside observers will treat the CA as if
> > it had issued the corresponding certificate - whether or not the CA
> > really did - so the CA should behave accordingly.
> >
> > It's worth explicitly mentioning the implications of this:
> >
> > * The CA needs to operate revocation services for the corresponding
> > certificate as if the certificate had been issued.
> >
> > * If the corresponding certificate would be misissued, the CA will be
> > treated as if it had really issued that certificate.
> >
> > Are there any other implications that 6962-bis should call out
> > explicitly?
> >
> > Regards,
> > Andrew
> >
>
> How about the following (Mozilla) policy rules:
>
> If a CA submits a preCertificate to CT, then it MUST ensure that one of
> the following is true no more than 96 hours after submitting the
> preCertificate and no more than 24 hours after signing the corresponding
> actual certificate:
>

This seems like a significantly worse change than Andrew's proposal,
because we can, do, and should expect better of CAs. A requirement like
this, captured in policy, actively discourages improvements to the status
quo, by explicitly encouraging delays.

It also seems to tie in a number of much broader, more impacting changes
that aren't immediately correlated, and thus would further delay productive
changes and clarifications. For example, magic values are very undesirable,
so we should try to avoid those.

I'm much more supportive of Andrew's change, as originally written. There
are other natural implications that may be worth expanding on, based on
some CAs' failures to think through them:

* If any corresponding certificate with the same serial number and issuer
exists, and can not be verified to match the precertificate using the
algorithms in 6962(-bis), it will be considered misissued.
  - This covers duplicate serial numbers, which may result if a CA fails to
mark the serial 'used' or 'issued' in their database
  - This logically implies that improperly (DER) encoding the SCT extension
within the final certificate is a BR compliance issue, while /not/ taking a
position on whether those SCTs conform to policy (e.g. number of logs or
diversity of logs), if/when Mozilla should adopt such a policy
  - This also covers situations where CAs reordered the extensions between
the issuance of a precertificate and the final certificate, as we saw some
CAs do, by suggesting it's a misissuance to do so; implicitly, it's stating
these are "different final certificates" - two certs with the same serial
with different extensions

* In examining historical issuance, the CA must consider both final
certificates and precertificates, even if the precertificate did not
ultimately result in the issuance of a certificate
  - We've seen multiple CAs "forget" to scan because they signed a precert,
but didn't mark a cert as 'active' or 'didn't issue the final certificate',
despite there still being misissuance.
  - However, CAs are also permitted to omit logging of certificates (e.g.
the policy does not /require/ logging of precerts /or/ certs, and both
Apple and Google permit local Enterprises to disable this), so it's not
sufficient to scan only precerts or final certs, but the union of both, to
ensure no omissions

Based on CA's failures, those two logical consequences stand out from
Andrew's proposal, which captures much of the spirit and intent.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Jakob Bohm via dev-security-policy]

On 16/09/2019 19:08, Andrew Ayer wrote:
> On Fri, 13 Sep 2019 08:22:21 +
> Rob Stradling via dev-security-policy
>  wrote:
> 
>> Thinking aloud...
>> Does anything need to be clarified in 6962-bis though?
> 
> Yes, it's long past time that we clarified what this means:
> 
> "This signature indicates the CA's intent to issue the certificate.  This
> intent is considered binding (i.e., misissuance of the precertificate is
> considered equivalent to misissuance of the corresponding certificate)."
> 
> The goal is that a precertificate signature creates an unrebuttable
> presumption that the CA has issued the corresponding certificate. If a
> CA issues a precertificate, outside observers will treat the CA as if
> it had issued the corresponding certificate - whether or not the CA
> really did - so the CA should behave accordingly.
> 
> It's worth explicitly mentioning the implications of this:
> 
> * The CA needs to operate revocation services for the corresponding
> certificate as if the certificate had been issued.
> 
> * If the corresponding certificate would be misissued, the CA will be
> treated as if it had really issued that certificate.
> 
> Are there any other implications that 6962-bis should call out
> explicitly?
> 
> Regards,
> Andrew
> 

How about the following (Mozilla) policy rules:

If a CA submits a preCertificate to CT, then it MUST ensure that one of 
the following is true no more than 96 hours after submitting the 
preCertificate and no more than 24 hours after signing the corresponding 
actual certificate:

 - The corresponding actual certificate has been signed and submitted to 
  CT (regardless if said submission was accepted), and all CA provided 
  revocation mechanisms and servers report that the actual certificate 
  is valid and not revoked.

 - The corresponding actual certificate has been signed, SHOULD have 
  been submitted to CT (regardless if said submission was accepted) and 
  was later revoked.  All CA provided revocation mechanisms and servers 
  MUST report that the actual certificate exists and SHOULD report that 
  it has been revoked at a time no earlier than 1 second before the 
  notBefore time in the preCertificate (other policy requirements or BRs 
  state that they MUST so report before a different deadline).

 - The corresponding actual certificate has not been signed and MUST not 
  be subsequently signed.  All CA provided revocation mechanisms and 
  servers must report that the certificate serial number was revoked at 
  least 60 seconds before the time specified as "notBefore" in the 
  preCertificate.

Rationale:
 - Requirements explicitly refer to revocation of the corresponding 
  actual certificate, not the (perhaps differently signed) 
  preCertificate.

 - 96 hours is the existing BR deadline for updating revocation servers.

 - 24 hours is reasonable time for rolling out the "certificate good" 
  status throughout a CA infrastructure, before taking actions such 
  as submitting the actual certificate to CT.  In practice, a CA will 
  need to do this faster if it wants to provide the actual certificate 
  to subscribers faster than this.

 - If a CA wishes to make an actually/possibly signed certificate never 
  valid, it can report it as revoked 1 or 0 seconds before the notBefore 
  time.  This is appropriate where a problem report indicates that the 
  certificate should never have been issued, or if signing the actual 
  certificate was initiated but the result was not successfully stored.

 - Revocation times of 2 to 59 seconds before notBefore are reserved for 
  use in future policies.

 - A CA system can be compliant while having only transaction-level 
  reliability.

 - This caters to fast online CAs that complete the entire process in a 
  few minutes or seconds.

 - This also caters to CAs that keep the private CA key offline and 
  require human confirmation of signing actions.  Such a CA may perform 
  human confirmation of PreCertificate signing on a Friday, only accept 
  problem report revocations during the weekend, then manually confirm 
  signing of actual certificate, CRL and canned OCSP responses on 
  Monday.  Root CAs with signing ceremonies would be a typical case.  
  Dedicated high security issuing SubCAs would be another case.

 - This also caters to the scenario where a usually fast online CA
  experiences a technical glitch that prevents completion of issuance,
  followed by a few days to detect the situation and revoke the non-
  issued certificates.

 - It also caters to the scenario of a CT log failing to issue the
  expected CT proofs, and the CA timing out the wait for that CT log
  after 24 to 72 hours.

 - It also caters to the scenario where a CT log fails to accept
  submission of the signed actual certificate.

 - Issuing a CT logged certificate but keeping it locked up in the CA
  building explicitly becomes a policy violation after just a few days,
  because it is then explicitly required to be published 

Re: DigiCert OCSP services returns 1 byte

[Andrew Ayer via dev-security-policy]

On Fri, 13 Sep 2019 08:22:21 +
Rob Stradling via dev-security-policy
 wrote:

> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?

Yes, it's long past time that we clarified what this means:

"This signature indicates the CA's intent to issue the certificate.  This
intent is considered binding (i.e., misissuance of the precertificate is
considered equivalent to misissuance of the corresponding certificate)."

The goal is that a precertificate signature creates an unrebuttable
presumption that the CA has issued the corresponding certificate. If a
CA issues a precertificate, outside observers will treat the CA as if
it had issued the corresponding certificate - whether or not the CA
really did - so the CA should behave accordingly.

It's worth explicitly mentioning the implications of this:

* The CA needs to operate revocation services for the corresponding
certificate as if the certificate had been issued.

* If the corresponding certificate would be misissued, the CA will be
treated as if it had really issued that certificate.

Are there any other implications that 6962-bis should call out
explicitly?

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:

> Here's some suggested wording for the last paragraph:
> 
>> This means, for example, that (i) a CA must provide OCSP services
>> and responses in accordance with Mozilla policy for all certificates
>> presumed to exist based on the presence of a Precertificate, even if the
>> certificate does not actually exist, and (ii) a CA must be able to revoke
>> a certificate presumed to exist, if revocation of the certificate is required
>> under Mozilla policy, even if the certificate does not actually exist.

[Speaking only for myself]

Wayne, Andrew,

Please treat this message as a sincere attempt both to understand what 
the current requirements actually are and to seek to clarify what the 
requirements should be.

ISTM that this "certificate presumed to exist" concept doesn't play 
nicely with the current wording of BR 4.9.10:
   'If the OCSP responder receives a request for status of a certificate
that has not been issued, then the responder SHOULD NOT respond with
a "good" status.'

If a certificate (with embedded SCTs and no CT poison extension) is 
"presumed to exist" but the CA has not actually issued it, then to my 
mind that's a "certificate that has not been issued"; and therefore, the 
OCSP 'responder SHOULD NOT respond with a "good" status'.

However, this is Schrödinger's "certificate that has not been issued", 
because a Precertificate has been issued that has the same serial number 
(as the "certificate presumed to exist" that doesn't actually exist).

And so at this point ISTM that the OCSP responder is expected to 
implement two conflicting requirements for the serial number in question:
   (1) MUST respond "good", because an unrevoked/unexpired 
precertificate exists (and because BR 4.9.9 mandates a signed OCSP 
response).
   (2) SHOULD NOT respond "good" (see BR 4.9.10).

Clearly that's impossible, which leads to the question: Which of these 
two conflicting requirements should a CA ignore in order to be as 
un-non-compliant as possible?  Which leads me to BR 7.1.2.5:
   'For purposes of clarification, a Precertificate, as described in RFC
6962 – Certificate Transparency, shall not be considered to be a
“certificate” subject to the requirements of RFC 5280'

Since the first mention of "certificates" in the OCSP Protocol Overview 
(RFC6960 section 2) cross-references RFC5280, I believe that this 'shall 
not be considered to be a "certificate"' declaration can be assumed to 
extend to the OCSP requirements too.  And therefore, the balance tilts 
in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST 
respond "good"'.

I can't say I like this conclusion, but nonetheless it is the conclusion 
that my reading of the BRs forces me to reach.  I realize that what the 
BRs actually say may not reflect precisely what was intended by 
CABForum; nonetheless, CAs are measured by what the BRs actually say.

IDEAS FOR FIXING IT:

Long-term:
   - In CT v2 (6962-bis), precertificates are not X.509 certificates, 
which removes Schrödinger from the equation.  :-)

Short-term:
   - I think BR 7.1.2.5, as written, is decidedly unhelpful and should 
be revised to have a much smaller scope.  Surely only the serial number 
uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed, 
not the entirety of RFC5280?
   - I would also like to see BR 4.9.10 revised to say something roughly 
along these lines:
   'If the OCSP responder receives a status request for a serial number
that has not been allocated by the CA, then the responder SHOULD NOT
respond with a "good" status.'

P.S. Full disclosure: Sectigo currently provides an (unsigned) 
"unauthorized" OCSP response when a precert exists but the corresponding 
cert doesn't, but in all honesty I'm not currently persuaded that an 
Incident Report is warranted.

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 13/09/2019 19:24, Tim Hollebeek wrote:
> Yes, but I think this clarifies things in the wrong direction.

Hi Tim.  I'm not clear what you mean.

I was talking specifically and only about what IETF could/should do 
regarding this matter.  Which part did you disagree with, and why?

> -Tim
> 
>> -Original Message-
>> From: Rob Stradling 
>> Sent: Friday, September 13, 2019 4:22 AM
>> To: Tim Hollebeek ; Jeremy Rowley
>> ; Alex Cohn 
>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>> 
>> Subject: Re: DigiCert OCSP services returns 1 byte
>>
>> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
>>> So, this is something that would be helpfully clarified via either an
>>> IETF draft,
>>
>> There's already a 6962-bis draft [1] in IESG Last Call, which (when we 
>> finally
>> complete it!) will obsolete RFC6962.  6962-bis redefines precertificates so 
>> that
>> they're not actually X.509 certificates.
>> Therefore, I don't think a "clarify RFC6962" draft is necessary.
>>
>> Thinking aloud...
>> Does anything need to be clarified in 6962-bis though?
>> A (non-X.509) 6962-bis precertificate contains the serial number that will
>> appear in the certificate (if or when that certificate is issued),
>> so: Should the CA be forbidden, permitted or required to operate revocation
>> services for that serial number once the 6962-bis precertificate has been
>> produced but before the certificate has been issued?  (And is this a 
>> technical
>> matter for 6962-bis to address, or a policy matter that's out of scope for 
>> the
>> 6962-bis document?)
>>
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
>>
>>> or clarifications in the BRs.  There are various things in the OCSP RFCs and
>> even the BRs that can be read as precluding good OCSP responses for pre-
>> certificates, although the situation is unclear since the relevant sections 
>> are
>> blissfully ignorant of CT, and the correct behavior here was unfortunately 
>> left
>> out of RFC 6962, which should have clarified this.
>>>
>>> Happy to help draft something.  There are some interesting complexities
>> once you dig deeper.
>>>
>>> -Tim
>>>
>>>> -Original Message-
>>>> From: dev-security-policy
>>>>  On Behalf Of Jeremy
>>>> Rowley via dev-security-policy
>>>> Sent: Thursday, September 12, 2019 1:46 PM
>>>> To: Alex Cohn 
>>>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>>>> 
>>>> Subject: RE: DigiCert OCSP services returns 1 byte
>>>>
>>>> The language says you have to provide the response for the cert as if
>>>> it exists, but the reality is that sending a response for the precert
>>>> is the same as calculating the result for the certificate as if it
>>>> exists and sending that. They are the same thing because the precert
>>>> is treated the same as the final cert if the final cert doesn’t exist.
>>>>
>>>> I believe the intent is that a CT-naïve OCSP checker would work
>>>> normally when presented with a precert or a certificate. Afterall, a
>>>> precert is really just a certificate with a special extension.
>>>>
>>>> From: Alex Cohn 
>>>> Sent: Thursday, September 12, 2019 9:25 AM
>>>> To: Jeremy Rowley 
>>>> Cc: Wayne Thayer ; mozilla-dev-security-
>>>> pol...@lists.mozilla.org
>>>> Subject: Re: DigiCert OCSP services returns 1 byte
>>>>
>>>> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via
>>>> dev-security-policy
>>>> mailto:dev-security-
>>>> pol...@lists.mozilla.org>> wrote:
>>>> This means, for example, that (i) a CA must provide OCSP services and
>>>> responses in accordance with the Mozilla policy for all
>>>> pre-certificates as if corresponding certificate exists and (ii) a CA
>>>> must be able to revoke a pre- certificate if revocation of the
>>>> certificate is required under the Mozilla policy and the
>>>> corresponding certificate doesn't actually exist and therefore cannot be
>> revoked.
>>>>
>>>> Should a CA using a precertificate signing certificate be required to
>>>> provide OCSP services for their precertificates? Or is it on the
>>>> relying party to calculate the proper OCSP request for the final
>>>> certifi

Re: DigiCert OCSP services returns 1 byte

[Andrew Ayer via dev-security-policy]

Hi Wayne,

> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with Mozilla policy for all Precertificates as if
> > the corresponding certificate exists, and (ii) a CA must be able to revoke
> > a Precertificate if revocation of the certificate is required under Mozilla
> > policy and the corresponding certificate doesn’t actually exist and
> > therefore cannot be revoked.
> >
> 
> I will again welcome everyone's constructive feedback on this proposal, and
> when there are no further comments I'll add this to our wiki.

I'm concerned that the last paragraph could be interpreted as requiring
CAs to operate OCSP services for the literal precertificates issued by
dedicated precert signing CAs, rather than the corresponding
certificates. This is not intended or useful, and as Tim Shirley
notes it would double the OCSP signing load for any CA using precert
signing CAs.

I think it's better to frame the language not as operating OCSP
services for precertificates themselves, but for certificates presumed
to exist based on the presence of a precertifiate (even if the
certificate doesn't actually exist).

Here's some suggested wording for the last paragraph:

> This means, for example, that (i) a CA must provide OCSP services
> and responses in accordance with Mozilla policy for all certificates
> presumed to exist based on the presence of a Precertificate, even if the
> certificate does not actually exist, and (ii) a CA must be able to revoke
> a certificate presumed to exist, if revocation of the certificate is required
> under Mozilla policy, even if the certificate does not actually exist.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Thanks everyone for your feedback! I'm sensing that the proposed language
is generally helpful. I've made two updates:

* Accepted Jeremy's proposed language for the examples in the last
paragraph.
* attempted to address Tim Shirley's point that a precertificate is not
literally "proof" that a certificate exists by changing that sentence to
"Otherwise, Mozilla infers from the existence of a precertificate that a
corresponding certificate has been issued, even when we have no evidence of
the certificate."

The new statement of "required practice" reads:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given Precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every Precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
> However, BR 7.1.2.5 state “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a Precertificate containing the same serial number as the subsequent
> certificate. Otherwise, Mozilla infers from the existence of a
> Precertificate that a corresponding certificate has been issued, even when
> we have no evidence of the certificate.
>
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with Mozilla policy for all Precertificates as if
> the corresponding certificate exists, and (ii) a CA must be able to revoke
> a Precertificate if revocation of the certificate is required under Mozilla
> policy and the corresponding certificate doesn’t actually exist and
> therefore cannot be revoked.
>

I will again welcome everyone's constructive feedback on this proposal, and
when there are no further comments I'll add this to our wiki.

- Wayne

On Fri, Sep 13, 2019 at 11:24 AM Tim Hollebeek 
wrote:

> Yes, but I think this clarifies things in the wrong direction.
>
> -Tim
>
> > -Original Message-
> > From: Rob Stradling 
> > Sent: Friday, September 13, 2019 4:22 AM
> > To: Tim Hollebeek ; Jeremy Rowley
> > ; Alex Cohn 
> > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > 
> > Subject: Re: DigiCert OCSP services returns 1 byte
> >
> > On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > > So, this is something that would be helpfully clarified via either an
> > > IETF draft,
> >
> > There's already a 6962-bis draft [1] in IESG Last Call, which (when we
> finally
> > complete it!) will obsolete RFC6962.  6962-bis redefines precertificates
> so that
> > they're not actually X.509 certificates.
> > Therefore, I don't think a "clarify RFC6962" draft is necessary.
> >
> > Thinking aloud...
> > Does anything need to be clarified in 6962-bis though?
> > A (non-X.509) 6962-bis precertificate contains the serial number that
> will
> > appear in the certificate (if or when that certificate is issued),
> > so: Should the CA be forbidden, permitted or required to operate
> revocation
> > services for that serial number once the 6962-bis precertificate has been
> > produced but before the certificate has been issued?  (And is this a
> technical
> > matter for 6962-bis to address, or a policy matter that's out of scope
> for the
> > 6962-bis document?)
> >
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> >
> > > or clarifications in the BRs.  There are various things in the OCSP
> RFCs and
> > even the BRs that can be read as precluding good OCSP responses for pre-
> > certificates, although the situation is unclear since the relevant
> sections are
> > blissfully ignorant of CT, and the correct behavior here was
> unfortunately left
> > out of RFC 6962, which should have clarified this.
> > >
> > > Happy to help draft something.  There are some interesting complexities
> > once you dig deeper.
> > >
> > > -Tim
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> &

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

Yes, but I think this clarifies things in the wrong direction.

-Tim

> -Original Message-
> From: Rob Stradling 
> Sent: Friday, September 13, 2019 4:22 AM
> To: Tim Hollebeek ; Jeremy Rowley
> ; Alex Cohn 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > So, this is something that would be helpfully clarified via either an
> > IETF draft,
> 
> There's already a 6962-bis draft [1] in IESG Last Call, which (when we finally
> complete it!) will obsolete RFC6962.  6962-bis redefines precertificates so 
> that
> they're not actually X.509 certificates.
> Therefore, I don't think a "clarify RFC6962" draft is necessary.
> 
> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?
> A (non-X.509) 6962-bis precertificate contains the serial number that will
> appear in the certificate (if or when that certificate is issued),
> so: Should the CA be forbidden, permitted or required to operate revocation
> services for that serial number once the 6962-bis precertificate has been
> produced but before the certificate has been issued?  (And is this a technical
> matter for 6962-bis to address, or a policy matter that's out of scope for the
> 6962-bis document?)
> 
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> 
> > or clarifications in the BRs.  There are various things in the OCSP RFCs and
> even the BRs that can be read as precluding good OCSP responses for pre-
> certificates, although the situation is unclear since the relevant sections 
> are
> blissfully ignorant of CT, and the correct behavior here was unfortunately 
> left
> out of RFC 6962, which should have clarified this.
> >
> > Happy to help draft something.  There are some interesting complexities
> once you dig deeper.
> >
> > -Tim
> >
> >> -Original Message-
> >> From: dev-security-policy
> >>  On Behalf Of Jeremy
> >> Rowley via dev-security-policy
> >> Sent: Thursday, September 12, 2019 1:46 PM
> >> To: Alex Cohn 
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >> 
> >> Subject: RE: DigiCert OCSP services returns 1 byte
> >>
> >> The language says you have to provide the response for the cert as if
> >> it exists, but the reality is that sending a response for the precert
> >> is the same as calculating the result for the certificate as if it
> >> exists and sending that. They are the same thing because the precert
> >> is treated the same as the final cert if the final cert doesn’t exist.
> >>
> >> I believe the intent is that a CT-naïve OCSP checker would work
> >> normally when presented with a precert or a certificate. Afterall, a
> >> precert is really just a certificate with a special extension.
> >>
> >> From: Alex Cohn 
> >> Sent: Thursday, September 12, 2019 9:25 AM
> >> To: Jeremy Rowley 
> >> Cc: Wayne Thayer ; mozilla-dev-security-
> >> pol...@lists.mozilla.org
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> >> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via
> >> dev-security-policy
> >> mailto:dev-security-
> >> pol...@lists.mozilla.org>> wrote:
> >> This means, for example, that (i) a CA must provide OCSP services and
> >> responses in accordance with the Mozilla policy for all
> >> pre-certificates as if corresponding certificate exists and (ii) a CA
> >> must be able to revoke a pre- certificate if revocation of the
> >> certificate is required under the Mozilla policy and the
> >> corresponding certificate doesn't actually exist and therefore cannot be
> revoked.
> >>
> >> Should a CA using a precertificate signing certificate be required to
> >> provide OCSP services for their precertificates? Or is it on the
> >> relying party to calculate the proper OCSP request for the final
> >> certificate and send that instead? In other words, should we expect a
> >> CT-naïve OCSP checker to work normally when presented, e.g., with
> https://crt.sh/?id=1868433277?
> >>
> >> Alex
> >> ___
> >> dev-security-policy mailing list
> >> dev-security-policy@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-security-policy
> >>
> >> ___
> >> dev-security-policy maili

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

Tim Shirley did a good job of pointing it out.  The relevant OCSP RFCs talk 
about issued certificates, which pre-certificates aren’t.  This isn’t a policy 
matter, it’s a matter of a plain reading of the relevant RFCs, and trying to 
align that with what people want them to say as opposed to what they actually 
say.

 

Whatever the policy is, and I’m actually supportive of Wayne’s policy goals, 
the CT and OCSP RFCs actually have requirements that potentially contradict 
those goals, especially under some interpretations.

 

I’d like to fix the relevant requirements to allow to the policy that there 
seems to be a growing consensus for.

 

-Tim

 

From: Ryan Sleevi  
Sent: Thursday, September 12, 2019 6:44 PM
To: Tim Hollebeek 
Cc: Jeremy Rowley ; Alex Cohn ; 
mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 

Subject: Re: DigiCert OCSP services returns 1 byte

 

Without wanting to be antagonistic, I've come to learn I can count on you to 
suggest that X deserves clarification because it's ambiguous, but I've also 
learned I have trouble learning where the ambiguity exists or why. Recall that 
part of this confusion, regrettably, came from an earnest attempt to try and 
helpfully clarify the BRs with respect to precertificates, so I've come to view 
clarifications as just as much, if not more, risky than the original language.

 

The question about whether and how a pre-certificate is viewed is definitely a 
matter for policy, and so I'm definitely opposed to attempting to address it in 
IETF drafts, and somewhat opposed to clarifying it in the BRs, since really, 
it's a matter of policy.

 

Could you perhaps highlight which "various things in the OCSP RFCs" that might 
be read to conflict or preclude a good response? I think that's probably the 
best way to figure out what, where, is to understand how the interpretation 
came to be. It could be simply that the interpretation overlooked other 
sections, as we've seen in the past (e.g. with IP addresses in dNSName or with 
underscores), and so that seems like the best starting point.

 

On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

So, this is something that would be helpfully clarified via either an IETF 
draft, or clarifications in the BRs.  There are various things in the OCSP RFCs 
and even the BRs that can be read as precluding good OCSP responses for 
pre-certificates, although the situation is unclear since the relevant sections 
are blissfully ignorant of CT, and the correct behavior here was unfortunately 
left out of RFC 6962, which should have clarified this.

Happy to help draft something.  There are some interesting complexities once 
you dig deeper.

-Tim

> -Original Message-
> From: dev-security-policy  <mailto:dev-security-policy-boun...@lists.mozilla.org> > On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, September 12, 2019 1:46 PM
> To: Alex Cohn mailto:a...@alexcohn.com> >
> Cc: mozilla-dev-security-pol...@lists.mozilla.org 
> <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Wayne Thayer
> mailto:wtha...@mozilla.com> >
> Subject: RE: DigiCert OCSP services returns 1 byte
> 
> The language says you have to provide the response for the cert as if it 
> exists,
> but the reality is that sending a response for the precert is the same as
> calculating the result for the certificate as if it exists and sending that. 
> They are
> the same thing because the precert is treated the same as the final cert if 
> the
> final cert doesn’t exist.
> 
> I believe the intent is that a CT-naïve OCSP checker would work normally when
> presented with a precert or a certificate. Afterall, a precert is really just 
> a
> certificate with a special extension.
> 
> From: Alex Cohn mailto:a...@alexcohn.com> >
> Sent: Thursday, September 12, 2019 9:25 AM
> To: Jeremy Rowley  <mailto:jeremy.row...@digicert.com> >
> Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; 
> mozilla-dev-security-
> pol...@lists.mozilla.org <mailto:pol...@lists.mozilla.org> 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
>  <mailto:dev-security-policy@lists.mozilla.org> <mailto:dev-security- 
> <mailto:dev-security-> 
> pol...@lists.mozilla.org <mailto:pol...@lists.mozilla.org> >> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as if
> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
> certificate if revocation of the certificate is required under the Mozilla 
> policy
> and the corresponding certificate doesn't actually ex

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> So, this is something that would be helpfully clarified via either an IETF 
> draft,

There's already a 6962-bis draft [1] in IESG Last Call, which (when we 
finally complete it!) will obsolete RFC6962.  6962-bis redefines 
precertificates so that they're not actually X.509 certificates. 
Therefore, I don't think a "clarify RFC6962" draft is necessary.

Thinking aloud...
Does anything need to be clarified in 6962-bis though?
A (non-X.509) 6962-bis precertificate contains the serial number that 
will appear in the certificate (if or when that certificate is issued), 
so: Should the CA be forbidden, permitted or required to operate 
revocation services for that serial number once the 6962-bis 
precertificate has been produced but before the certificate has been 
issued?  (And is this a technical matter for 6962-bis to address, or a 
policy matter that's out of scope for the 6962-bis document?)


[1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

> or clarifications in the BRs.  There are various things in the OCSP RFCs and 
> even the BRs that can be read as precluding good OCSP responses for 
> pre-certificates, although the situation is unclear since the relevant 
> sections are blissfully ignorant of CT, and the correct behavior here was 
> unfortunately left out of RFC 6962, which should have clarified this.
> 
> Happy to help draft something.  There are some interesting complexities once 
> you dig deeper.
> 
> -Tim
> 
>> -Original Message-
>> From: dev-security-policy  On
>> Behalf Of Jeremy Rowley via dev-security-policy
>> Sent: Thursday, September 12, 2019 1:46 PM
>> To: Alex Cohn 
>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>> 
>> Subject: RE: DigiCert OCSP services returns 1 byte
>>
>> The language says you have to provide the response for the cert as if it 
>> exists,
>> but the reality is that sending a response for the precert is the same as
>> calculating the result for the certificate as if it exists and sending that. 
>> They are
>> the same thing because the precert is treated the same as the final cert if 
>> the
>> final cert doesn’t exist.
>>
>> I believe the intent is that a CT-naïve OCSP checker would work normally when
>> presented with a precert or a certificate. Afterall, a precert is really 
>> just a
>> certificate with a special extension.
>>
>> From: Alex Cohn 
>> Sent: Thursday, September 12, 2019 9:25 AM
>> To: Jeremy Rowley 
>> Cc: Wayne Thayer ; mozilla-dev-security-
>> pol...@lists.mozilla.org
>> Subject: Re: DigiCert OCSP services returns 1 byte
>>
>> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
>> mailto:dev-security-
>> pol...@lists.mozilla.org>> wrote:
>> This means, for example, that (i) a CA must provide OCSP services and
>> responses in accordance with the Mozilla policy for all pre-certificates as 
>> if
>> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
>> certificate if revocation of the certificate is required under the Mozilla 
>> policy
>> and the corresponding certificate doesn't actually exist and therefore cannot
>> be revoked.
>>
>> Should a CA using a precertificate signing certificate be required to provide
>> OCSP services for their precertificates? Or is it on the relying party to 
>> calculate
>> the proper OCSP request for the final certificate and send that instead? In
>> other words, should we expect a CT-naïve OCSP checker to work normally
>> when presented, e.g., with https://crt.sh/?id=1868433277?
>>
>> Alex
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

There's a problem with this framing, and this was the earlier reference to
Jeremy about Yu-gi-oh!

From that earlier response:
> Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

Or, to quote from RFC 6962:
>  The signature on the TBSCertificate indicates the
>   certificate authority's intent to issue a certificate.  This intent
>   is considered binding (i.e., misissuance of the Precertificate is
>   considered equal to misissuance of the final certificate).

I suspect part of the issue is the incorrect view of seeing "misissuance"
as "Issuing a certificate that does not comply with the profile", where
we've seen (most obvious through the many CA incident reports), that
"misissuance" is "Issuing a certificate that does not comply with the
policy" - that is, including services like AIA, OCSP, and, well, all the
many validation requirements.

From the point of view of browser policy, a pre-certificate is absolutely
evidence that an equivalent certificate exists. Anything less than that,
and a CA would (and CAs have) tried to argue that it's not really
misissuance, as long as they didn't actually issue the equivalent
certificate. The very point of pre-certificates is to indicate a binding
commitment, with cryptographic evidence, that they cannot dispute an
equivalent certificate "could" exist.

On Thu, Sep 12, 2019 at 8:21 PM Tim Shirley 
wrote:

> Why would a user agent view a pre-certificate as "evidence that an
> equivalent certificate exists"?  It's evidence that it might exist..  That
> the CA had the intent to make it exist at the time they signed the
> precertificate..  But I can't find anything in RFC 6962 that suggests to me
> that if the CA doesn't follow through on that intent that their systems are
> required to behave as if it does exist.
>
> And of course Mozilla could add a policy to require exactly that, as the
> proposed addition does.  But I'm struggling to see the practical value in
> doing so.
>
> Regards,
> Tim
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Thursday, September 12, 2019 6:40 PM
> To: Alex Cohn 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer <
> wtha...@mozilla.com>; Jeremy Rowley 
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> > < dev-security-policy@lists.mozilla.org> wrote:
> >
> > > This means, for example, that (i) a CA must provide OCSP services
> > > and responses in accordance with the Mozilla policy for all
> > > pre-certificates
> > as
> > > if corresponding certificate exists and (ii) a CA must be able to
> > > revoke
> > a
> > > pre-certificate if revocation of the certificate is required under
> > > the Mozilla policy and the corresponding certificate doesn't
> > > actually exist
> > and
> > > therefore cannot be revoked.
> > >
> >
> > Should a CA using a precertificate signing certificate be required to
> > provide OCSP services for their precertificates? Or is it on the
> > relying party to calculate the proper OCSP request for the final
> > certificate and send that instead? In other words, should we expect a
> > CT-naïve OCSP checker to work normally when presented, e.g., with
> > https://scanmail.trustwave.com/?c=4062=ysn63WDApoyhRKbM1KwsYGvdnm11Y
> > YNCq-2zZRHKOQ=5=https%3a%2f%2fcrt%2esh%2f%3fid%3d1868433277%3f
> >
>
> I think this may be the wrong framing. The issue is not about ensuring "a
> CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring
> that, from the point of view of a user agent that views a pre-certificate
> as evidence that an equivalent certificate exists, even if it's not known
> (or even if it was not actually issued), can they verify that OCSP services
> exist and are configured for that equivalent certificate?
>
> In this scenario, because RFC 6962 establishes that, even when using a
> Precertificate Signing Certificate, it will have been directly issued by
> the CA Certificate that will ultimately issue the "final" certificate (...
> or would be treated as if it had), then we have the (name-hash, key-hash)
> that Neil was referring to, and we can easily verify using that, for the
> serial number indicated in the pre-certificate, that th

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

But the pre-cert exists and the pre-cert is a cert. I should be able to tell 
the status of a pre-cert because it really is a certificate.

-Original Message-
From: dev-security-policy  On 
Behalf Of Tim Shirley via dev-security-policy
Sent: Thursday, September 12, 2019 6:21 PM
To: r...@sleevi.com; Alex Cohn 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley 
; Wayne Thayer 
Subject: RE: DigiCert OCSP services returns 1 byte

Why would a user agent view a pre-certificate as "evidence that an equivalent 
certificate exists"?  It's evidence that it might exist..  That the CA had the 
intent to make it exist at the time they signed the precertificate..  But I 
can't find anything in RFC 6962 that suggests to me that if the CA doesn't 
follow through on that intent that their systems are required to behave as if 
it does exist.

And of course Mozilla could add a policy to require exactly that, as the 
proposed addition does.  But I'm struggling to see the practical value in doing 
so.

Regards,
Tim

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, September 12, 2019 6:40 PM
To: Alex Cohn 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 
; Jeremy Rowley 
Subject: Re: DigiCert OCSP services returns 1 byte

On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy 
> < dev-security-policy@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OCSP services 
> > and responses in accordance with the Mozilla policy for all 
> > pre-certificates
> as
> > if corresponding certificate exists and (ii) a CA must be able to 
> > revoke
> a
> > pre-certificate if revocation of the certificate is required under 
> > the Mozilla policy and the corresponding certificate doesn't 
> > actually exist
> and
> > therefore cannot be revoked.
> >
>
> Should a CA using a precertificate signing certificate be required to 
> provide OCSP services for their precertificates? Or is it on the 
> relying party to calculate the proper OCSP request for the final 
> certificate and send that instead? In other words, should we expect a 
> CT-naïve OCSP checker to work normally when presented, e.g., with 
> https://scanmail.trustwave.com/?c=4062=ysn63WDApoyhRKbM1KwsYGvdnm11Y
> YNCq-2zZRHKOQ=5=https%3a%2f%2fcrt%2esh%2f%3fid%3d1868433277%3f
>

I think this may be the wrong framing. The issue is not about ensuring "a 
CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring 
that, from the point of view of a user agent that views a pre-certificate as 
evidence that an equivalent certificate exists, even if it's not known (or even 
if it was not actually issued), can they verify that OCSP services exist and 
are configured for that equivalent certificate?

In this scenario, because RFC 6962 establishes that, even when using a 
Precertificate Signing Certificate, it will have been directly issued by the CA 
Certificate that will ultimately issue the "final" certificate (...
or would be treated as if it had), then we have the (name-hash, key-hash) that 
Neil was referring to, and we can easily verify using that, for the serial 
number indicated in the pre-certificate, that the OCSP response can be verified 
using the issuer of the Precertificate Signing Certificate.

Have I overlooked some ambiguity?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062=ysn63WDApoyhRKbM1KwsYGvdnm11YYNCq7_hMxDGZg=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Tim Shirley via dev-security-policy]

Why would a user agent view a pre-certificate as "evidence that an equivalent 
certificate exists"?  It's evidence that it might exist..  That the CA had the 
intent to make it exist at the time they signed the precertificate..  But I 
can't find anything in RFC 6962 that suggests to me that if the CA doesn't 
follow through on that intent that their systems are required to behave as if 
it does exist.

And of course Mozilla could add a policy to require exactly that, as the 
proposed addition does.  But I'm struggling to see the practical value in doing 
so.

Regards,
Tim

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, September 12, 2019 6:40 PM
To: Alex Cohn 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 
; Jeremy Rowley 
Subject: Re: DigiCert OCSP services returns 1 byte

On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy 
> < dev-security-policy@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OCSP services 
> > and responses in accordance with the Mozilla policy for all 
> > pre-certificates
> as
> > if corresponding certificate exists and (ii) a CA must be able to 
> > revoke
> a
> > pre-certificate if revocation of the certificate is required under 
> > the Mozilla policy and the corresponding certificate doesn't 
> > actually exist
> and
> > therefore cannot be revoked.
> >
>
> Should a CA using a precertificate signing certificate be required to 
> provide OCSP services for their precertificates? Or is it on the 
> relying party to calculate the proper OCSP request for the final 
> certificate and send that instead? In other words, should we expect a 
> CT-naïve OCSP checker to work normally when presented, e.g., with 
> https://scanmail.trustwave.com/?c=4062=ysn63WDApoyhRKbM1KwsYGvdnm11Y
> YNCq-2zZRHKOQ=5=https%3a%2f%2fcrt%2esh%2f%3fid%3d1868433277%3f
>

I think this may be the wrong framing. The issue is not about ensuring "a 
CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring 
that, from the point of view of a user agent that views a pre-certificate as 
evidence that an equivalent certificate exists, even if it's not known (or even 
if it was not actually issued), can they verify that OCSP services exist and 
are configured for that equivalent certificate?

In this scenario, because RFC 6962 establishes that, even when using a 
Precertificate Signing Certificate, it will have been directly issued by the CA 
Certificate that will ultimately issue the "final" certificate (...
or would be treated as if it had), then we have the (name-hash, key-hash) that 
Neil was referring to, and we can easily verify using that, for the serial 
number indicated in the pre-certificate, that the OCSP response can be verified 
using the issuer of the Precertificate Signing Certificate.

Have I overlooked some ambiguity?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062=ysn63WDApoyhRKbM1KwsYGvdnm11YYNCq7_hMxDGZg=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Alex Cohn via dev-security-policy]

Neil's interpretation of my poorly-worded question was correct - thank you
and apologies for the confusion.

On Thu, Sep 12, 2019 at 5:39 PM Ryan Sleevi  wrote:

>
> On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Should a CA using a precertificate signing certificate be required to
>> provide OCSP services for their precertificates? Or is it on the relying
>> party to calculate the proper OCSP request for the final certificate and
>> send that instead? In other words, should we expect a CT-naïve OCSP
>> checker
>> to work normally when presented, e.g., with https://crt.sh/?id=1868433277
>> ?
>>
>
> I think this may be the wrong framing. The issue is not about ensuring "a
> CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring
> that, from the point of view of a user agent that views a pre-certificate
> as evidence that an equivalent certificate exists, even if it's not known
> (or even if it was not actually issued), can they verify that OCSP services
> exist and are configured for that equivalent certificate?
>

Fair point. The only relying parties likely to come across
precertificates in practice are CT log clients, and it's reasonable to
assume those will be prepared to handle edge cases like this. (How many
actually handle this correctly? crt.sh doesn't, as far as I can tell - OCSP
checks for the precert I posted earlier return "unauthorized", despite the
final certificate being good)


> In this scenario, because RFC 6962 establishes that, even when using a
> Precertificate Signing Certificate, it will have been directly issued by
> the CA Certificate that will ultimately issue the "final" certificate (...
> or would be treated as if it had), then we have the (name-hash, key-hash)
> that Neil was referring to, and we can easily verify using that, for the
> serial number indicated in the pre-certificate, that the OCSP response can
> be verified using the issuer of the Precertificate Signing Certificate.
>

That technique was what I was attempting to hint at with "on the relying
party to calculate the proper OCSP request for the final certificate".


> Have I overlooked some ambiguity?
>

Not that I can think of on further reflection. Just some
unanticipated-by-me edge cases :)

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

Without wanting to be antagonistic, I've come to learn I can count on you
to suggest that X deserves clarification because it's ambiguous, but I've
also learned I have trouble learning where the ambiguity exists or why.
Recall that part of this confusion, regrettably, came from an earnest
attempt to try and helpfully clarify the BRs with respect to
precertificates, so I've come to view clarifications as just as much, if
not more, risky than the original language.

The question about whether and how a pre-certificate is viewed is
definitely a matter for policy, and so I'm definitely opposed to attempting
to address it in IETF drafts, and somewhat opposed to clarifying it in the
BRs, since really, it's a matter of policy.

Could you perhaps highlight which "various things in the OCSP RFCs" that
might be read to conflict or preclude a good response? I think that's
probably the best way to figure out what, where, is to understand how the
interpretation came to be. It could be simply that the interpretation
overlooked other sections, as we've seen in the past (e.g. with IP
addresses in dNSName or with underscores), and so that seems like the best
starting point.

On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> So, this is something that would be helpfully clarified via either an IETF
> draft, or clarifications in the BRs.  There are various things in the OCSP
> RFCs and even the BRs that can be read as precluding good OCSP responses
> for pre-certificates, although the situation is unclear since the relevant
> sections are blissfully ignorant of CT, and the correct behavior here was
> unfortunately left out of RFC 6962, which should have clarified this.
>
> Happy to help draft something.  There are some interesting complexities
> once you dig deeper.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy 
> On
> > Behalf Of Jeremy Rowley via dev-security-policy
> > Sent: Thursday, September 12, 2019 1:46 PM
> > To: Alex Cohn 
> > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > 
> > Subject: RE: DigiCert OCSP services returns 1 byte
> >
> > The language says you have to provide the response for the cert as if it
> exists,
> > but the reality is that sending a response for the precert is the same as
> > calculating the result for the certificate as if it exists and sending
> that. They are
> > the same thing because the precert is treated the same as the final cert
> if the
> > final cert doesn’t exist.
> >
> > I believe the intent is that a CT-naïve OCSP checker would work normally
> when
> > presented with a precert or a certificate. Afterall, a precert is really
> just a
> > certificate with a special extension.
> >
> > From: Alex Cohn 
> > Sent: Thursday, September 12, 2019 9:25 AM
> > To: Jeremy Rowley 
> > Cc: Wayne Thayer ; mozilla-dev-security-
> > pol...@lists.mozilla.org
> > Subject: Re: DigiCert OCSP services returns 1 byte
> >
> > On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> > mailto:dev-security-
> > pol...@lists.mozilla.org>> wrote:
> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with the Mozilla policy for all pre-certificates
> as if
> > corresponding certificate exists and (ii) a CA must be able to revoke a
> pre-
> > certificate if revocation of the certificate is required under the
> Mozilla policy
> > and the corresponding certificate doesn't actually exist and therefore
> cannot
> > be revoked.
> >
> > Should a CA using a precertificate signing certificate be required to
> provide
> > OCSP services for their precertificates? Or is it on the relying party
> to calculate
> > the proper OCSP request for the final certificate and send that instead?
> In
> > other words, should we expect a CT-naïve OCSP checker to work normally
> > when presented, e.g., with https://crt.sh/?id=1868433277?
> >
> > Alex
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with the Mozilla policy for all pre-certificates
> as
> > if corresponding certificate exists and (ii) a CA must be able to revoke
> a
> > pre-certificate if revocation of the certificate is required under the
> > Mozilla policy and the corresponding certificate doesn't actually exist
> and
> > therefore cannot be revoked.
> >
>
> Should a CA using a precertificate signing certificate be required to
> provide OCSP services for their precertificates? Or is it on the relying
> party to calculate the proper OCSP request for the final certificate and
> send that instead? In other words, should we expect a CT-naïve OCSP checker
> to work normally when presented, e.g., with https://crt.sh/?id=1868433277?
>

I think this may be the wrong framing. The issue is not about ensuring "a
CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring
that, from the point of view of a user agent that views a pre-certificate
as evidence that an equivalent certificate exists, even if it's not known
(or even if it was not actually issued), can they verify that OCSP services
exist and are configured for that equivalent certificate?

In this scenario, because RFC 6962 establishes that, even when using a
Precertificate Signing Certificate, it will have been directly issued by
the CA Certificate that will ultimately issue the "final" certificate (...
or would be treated as if it had), then we have the (name-hash, key-hash)
that Neil was referring to, and we can easily verify using that, for the
serial number indicated in the pre-certificate, that the OCSP response can
be verified using the issuer of the Precertificate Signing Certificate.

Have I overlooked some ambiguity?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Tim Shirley via dev-security-policy]

Certainly we (as a CA who uses such precertificate-signing CAs) never 
interpreted RFC 6962 or the other requirements as mandating or even suggesting 
that, for either of the possible interpretations of Alex's question.  As soon 
as you hit the precertificate-signing CA in the validation path you've 
encountered a signed entity that is unusable in the public PKI, as it fails 
validation on a couple of fronts: it has the critical poison extension in the 
EKU and it has Basic Constraints set and yet was issued from a CA with 
path-length 0.  If we did need to provide OCSP responses for that hierarchy, 
that would mean generating and distributing twice as many OCSP responses, so if 
that became a requirement that would likely cause us to reconsider this 
implementation approach.

More generally speaking to the entirety of this thread though I'm wondering a 
couple of things:

1) Is there an actual goal or problem we're trying to solve by having a rule at 
all on whether an OCSP responder should respond UNKNOWN or GOOD on a 
precertificate where there is no certificate?  I understand the rationale for 
requiring that a CA be able to revoke a precertificate, since there's no way 
for a CA to prove that a corresponding certificate doesn't exist.  So if you 
can satisfy any of the criteria for which the BRs require revocation of a 
certificate today, an OCSP response of REVOKED on that serial number gives 
assurance that if any corresponding certificate DOES exist, it's now revoked.  
But what is the practical difference between an OCSP responder returning GOOD 
and it returning UNKNOWN unless a corresponding certificate exists?

2) How does the statement from RFC 6962 lead to the conclusion that a 
precertificate is "proof that a corresponding certificate has been issued".  Of 
course for a certain period of time (typically very short) that statement can't 
possibly be true because you need to create a precertificate before you can 
request SCTs and you need SCTs to create the certificate.  But ignoring that 
technicality, I read "This intent is considered binding (i.e., misissuance of 
the Precertificate is considered equal to misissuance of the final 
certificate)" as saying essentially "you'll be found guilty in a court of law 
if you commit a crime in your precertificate, whether or not you go through 
with it in a real certificate.  You signaled your intent, and we'll find you 
guilty based on that intent, if your intent was unlawful."  I could see where 
it might be ambiguous without the i.e. parenthetical between that 
interpretation and the interpretation that "binding intent" means a promise to 
issue a corresponding certificate.  But the i.e. parenthetical seems to have 
been added specifically to clear up that potential ambiguity.

Regards,
Tim

-Original Message-
From: dev-security-policy  On 
Behalf Of Neil Dunbar via dev-security-policy
Sent: Thursday, September 12, 2019 1:58 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte



> On 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> The language says you have to provide the response for the cert as if it 
> exists, but the reality is that sending a response for the precert is the 
> same as calculating the result for the certificate as if it exists and 
> sending that. They are the same thing because the precert is treated the same 
> as the final cert if the final cert doesn't exist.

I could be horribly mistaken, but I think Alex was asking is: in the event that 
precertificates are not signed by the issuing CA's private key, but rather by a 
separate signing key/certificate dedicated to that purpose (per RFC 6962, 
Section 3.1) - is there then an obligation to provide OCSP services for that, 
given that the (name-hash, key-hash) on the OCSP request would not be the same 
as that which would normally obtain for the final certificate, which is signed 
directly by the issuing CA key?

It would _seem_ right that it should, since a pre-certificate could reasonably 
be revoked prior to issuing the final certificate, for several reasons. Yet 
it's a reasonable follow-up question: would CAs who have such dedicated 
certificates make them available such that RPs could construct those OCSP 
requests?

> I believe the intent is that a CT-naïve OCSP checker would work normally when 
> presented with a precert or a certificate. Afterall, a precert is really just 
> a certificate with a special extension.

Would an OCSP server even be able to tell the difference? After all, it simply 
gets presented with a CA identifier (name-hash, key-hash) and a serial number. 
If it knows about that combination, it provides a response, but it's got no way 
of knowing, absent extra information in its database whether the request 
pertains to a pre-cert or cert - in general. But see above for th

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

So, this is something that would be helpfully clarified via either an IETF 
draft, or clarifications in the BRs.  There are various things in the OCSP RFCs 
and even the BRs that can be read as precluding good OCSP responses for 
pre-certificates, although the situation is unclear since the relevant sections 
are blissfully ignorant of CT, and the correct behavior here was unfortunately 
left out of RFC 6962, which should have clarified this.

Happy to help draft something.  There are some interesting complexities once 
you dig deeper.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, September 12, 2019 1:46 PM
> To: Alex Cohn 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> 
> Subject: RE: DigiCert OCSP services returns 1 byte
> 
> The language says you have to provide the response for the cert as if it 
> exists,
> but the reality is that sending a response for the precert is the same as
> calculating the result for the certificate as if it exists and sending that. 
> They are
> the same thing because the precert is treated the same as the final cert if 
> the
> final cert doesn’t exist.
> 
> I believe the intent is that a CT-naïve OCSP checker would work normally when
> presented with a precert or a certificate. Afterall, a precert is really just 
> a
> certificate with a special extension.
> 
> From: Alex Cohn 
> Sent: Thursday, September 12, 2019 9:25 AM
> To: Jeremy Rowley 
> Cc: Wayne Thayer ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> mailto:dev-security-
> pol...@lists.mozilla.org>> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as if
> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
> certificate if revocation of the certificate is required under the Mozilla 
> policy
> and the corresponding certificate doesn't actually exist and therefore cannot
> be revoked.
> 
> Should a CA using a precertificate signing certificate be required to provide
> OCSP services for their precertificates? Or is it on the relying party to 
> calculate
> the proper OCSP request for the final certificate and send that instead? In
> other words, should we expect a CT-naïve OCSP checker to work normally
> when presented, e.g., with https://crt.sh/?id=1868433277?
> 
> Alex
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> The language says you have to provide the response for the cert as if it 
> exists, but the reality is that sending a response for the precert is the 
> same as calculating the result for the certificate as if it exists and 
> sending that. They are the same thing because the precert is treated the same 
> as the final cert if the final cert doesn’t exist.

I could be horribly mistaken, but I think Alex was asking is: in the event that 
precertificates are not signed by the issuing CA’s private key, but rather by a 
separate signing key/certificate dedicated to that purpose (per RFC 6962, 
Section 3.1) - is there then an obligation to provide OCSP services for that, 
given that the (name-hash, key-hash) on the OCSP request would not be the same 
as that which would normally obtain for the final certificate, which is signed 
directly by the issuing CA key?

It would _seem_ right that it should, since a pre-certificate could reasonably 
be revoked prior to issuing the final certificate, for several reasons. Yet 
it’s a reasonable follow-up question: would CAs who have such dedicated 
certificates make them available such that RPs could construct those OCSP 
requests?

> I believe the intent is that a CT-naïve OCSP checker would work normally when 
> presented with a precert or a certificate. Afterall, a precert is really just 
> a certificate with a special extension.

Would an OCSP server even be able to tell the difference? After all, it simply 
gets presented with a CA identifier (name-hash, key-hash) and a serial number. 
If it knows about that combination, it provides a response, but it’s got no way 
of knowing, absent extra information in its database whether the request 
pertains to a pre-cert or cert - in general. But see above for the case of 
dedicated precertificate signing certificates.

Regards,

Neil


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

The language says you have to provide the response for the cert as if it 
exists, but the reality is that sending a response for the precert is the same 
as calculating the result for the certificate as if it exists and sending that. 
They are the same thing because the precert is treated the same as the final 
cert if the final cert doesn’t exist.

I believe the intent is that a CT-naïve OCSP checker would work normally when 
presented with a precert or a certificate. Afterall, a precert is really just a 
certificate with a special extension.

From: Alex Cohn 
Sent: Thursday, September 12, 2019 9:25 AM
To: Jeremy Rowley 
Cc: Wayne Thayer ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte

On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
This means, for example, that (i) a CA must provide OCSP services and responses 
in accordance with the Mozilla policy for all pre-certificates as if 
corresponding certificate exists and (ii) a CA must be able to revoke a 
pre-certificate if revocation of the certificate is required under the Mozilla 
policy and the corresponding certificate doesn't actually exist and therefore 
cannot be revoked.

Should a CA using a precertificate signing certificate be required to provide 
OCSP services for their precertificates? Or is it on the relying party to 
calculate the proper OCSP request for the final certificate and send that 
instead? In other words, should we expect a CT-naïve OCSP checker to work 
normally when presented, e.g., with https://crt.sh/?id=1868433277?

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Alex Cohn via dev-security-policy]

On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as
> if corresponding certificate exists and (ii) a CA must be able to revoke a
> pre-certificate if revocation of the certificate is required under the
> Mozilla policy and the corresponding certificate doesn't actually exist and
> therefore cannot be revoked.
>

Should a CA using a precertificate signing certificate be required to
provide OCSP services for their precertificates? Or is it on the relying
party to calculate the proper OCSP request for the final certificate and
send that instead? In other words, should we expect a CT-naïve OCSP checker
to work normally when presented, e.g., with https://crt.sh/?id=1868433277?

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

I think that's perfectly clear but I wanted to double check in case "perfectly 
clear" was me misreading it. One thing that does come up a lot is whether a CA 
has to revoke a pre-certificate if the certificate doesn't actually issue. I 
think this has been adequately answered on the bug lists but would be good to 
codify.

For the language maybe:

This means, for example, that (i) a CA must provide OCSP services and responses 
in accordance with the Mozilla policy for all pre-certificates as if 
corresponding certificate exists and (ii) a CA must be able to revoke a 
pre-certificate if revocation of the certificate is required under the Mozilla 
policy and the corresponding certificate doesn't actually exist and therefore 
cannot be revoked.



From: Wayne Thayer 
Sent: Wednesday, September 11, 2019 7:22:29 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: DigiCert OCSP services returns 1 byte

Correct. That's what I intended to convey with the last sentence:

This means, for example, that the requirements for OCSP for end-entity 
certificates apply even when a CA has issued a precertificate without issuing a 
corresponding certificate.


Do you have any suggestions for how I can improve/clarify?


On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:
Hey Wayne - I take it that this "Mozilla recognizes a precertificate as proof 
that a corresponding certificate has been issued" means a CA issuing a precert 
without the final cert must respond "good" unless the pre-cert is revoked? 
Responding unknown means the CA wouldn't know that they issued the cert, which 
means they disagree with the proof that a corresponding cert has been issued.

Jeremy

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, September 11, 2019 7:08 PM
To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: DigiCert OCSP services returns 1 byte

Mozilla has, to-date, not published policies related to Certificate 
Transparency, but this is a case where a clarification would be helpful. I 
propose adding the following language to our "Required Practices" wiki page
[1]:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to
> a given precertificate has or has not been issued. It is only safe to
> assume that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states "The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is
> considered equal to misissuance of the final certificate)."
>
>
>
> However, BR 7.1.2.5 state "For purposes of clarification, a
> Precertificate, as described in RFC 6962 - Certificate Transparency,
> shall not be considered to be a "certificate" subject to the
> requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and
> Certificate Revocation List (CRL) Profile under these Baseline Requirements."
>
> Mozilla interprets the BR language as a specific exception allowing
> CAs to issue a precertificate containing the same serial number as the
> subsequent certificate [2]. Mozilla recognizes a precertificate as
> proof that a corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in a 
future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
[2] https://cabforum.org/pipermail/public/2014-January/002694.html

On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy < 
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

> Let me try that again since I didn't explain my original post very well.
> Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
>
> What happened at DigiCert is that the OCSP service failed to return a
> signed response for a certificate where a pre-certificate existed by a
> certificate had not issued for whatever reason. The question asked was
> what type of OCSP services are required for a pre-cert if there is no
> other certificate. The answer we came up with is it should respond
> "G

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Correct. That's what I intended to convey with the last sentence:

This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

Do you have any suggestions for how I can improve/clarify?

On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley 
wrote:

> Hey Wayne - I take it that this "Mozilla recognizes a precertificate as
> proof that a corresponding certificate has been issued" means a CA issuing
> a precert without the final cert must respond "good" unless the pre-cert is
> revoked? Responding unknown means the CA wouldn't know that they issued the
> cert, which means they disagree with the proof that a corresponding cert
> has been issued.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Wednesday, September 11, 2019 7:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> Mozilla has, to-date, not published policies related to Certificate
> Transparency, but this is a case where a clarification would be helpful. I
> propose adding the following language to our "Required Practices" wiki page
> [1]:
>
> The current implementation of Certificate Transparency does not provide any
> > way for Relying Parties to determine if a certificate corresponding to
> > a given precertificate has or has not been issued. It is only safe to
> > assume that a certificate corresponding to every precertificate exists.
> >
> > RFC 6962 states “The signature on the TBSCertificate indicates the
> > certificate authority's intent to issue a certificate.  This intent is
> > considered binding (i.e., misissuance of the Precertificate is
> > considered equal to misissuance of the final certificate).”
> >
> >
> >
> > However, BR 7.1.2.5 state “For purposes of clarification, a
> > Precertificate, as described in RFC 6962 – Certificate Transparency,
> > shall not be considered to be a “certificate” subject to the
> > requirements of RFC
> > 5280 - Internet X.509 Public Key Infrastructure Certificate and
> > Certificate Revocation List (CRL) Profile under these Baseline
> Requirements.”
> >
> > Mozilla interprets the BR language as a specific exception allowing
> > CAs to issue a precertificate containing the same serial number as the
> > subsequent certificate [2]. Mozilla recognizes a precertificate as
> > proof that a corresponding certificate has been issued.
> >
> > This means, for example, that the requirements for OCSP for end-entity
> > certificates apply even when a CA has issued a precertificate without
> > issuing a corresponding certificate.
> >
>
> I plan to add this to the wiki next week. I also plan to include this in
> in a future update to our Root Store Policy.
>
> I will greatly appreciate your constructive feedback on this proposal.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
> [2] https://cabforum.org/pipermail/public/2014-January/002694.html
>
> On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Let me try that again since I didn't explain my original post very well.
> > Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
> >
> > What happened at DigiCert is that the OCSP service failed to return a
> > signed response for a certificate where a pre-certificate existed by a
> > certificate had not issued for whatever reason. The question asked was
> > what type of OCSP services are required for a pre-cert if there is no
> > other certificate. The answer we came up with is it should respond
> > "GOOD" based on the Mozilla policy, not Unknown or any other response.
> > Note that this was a bug in the DigiCert system but it lead to a fun
> internal discussion.
> > What I'm sharing is the outcome of the internal discussion - it's only
> > tangentially related to the bug, not the cause or remediation of it.
> >
> > Summary: Pre-certs require a standard OCSP response as if the pre-cert
> > was a normal cert. In fact, it's a mistake to ever think of pre-certs
> > as anything other than TLS certs, even if the poison extension exists.
> >
> > The question comes up because the BRs don't cover pre-certs. However,
> > as Ryan points out, the browsers sort-of cover this as does the
> > Mozilla policy. The browser say this is a promise to issue the cert
> > and mis-issuance of a pre-cer

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Hey Wayne - I take it that this "Mozilla recognizes a precertificate as proof 
that a corresponding certificate has been issued" means a CA issuing a precert 
without the final cert must respond "good" unless the pre-cert is revoked? 
Responding unknown means the CA wouldn't know that they issued the cert, which 
means they disagree with the proof that a corresponding cert has been issued.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, September 11, 2019 7:08 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte

Mozilla has, to-date, not published policies related to Certificate 
Transparency, but this is a case where a clarification would be helpful. I 
propose adding the following language to our "Required Practices" wiki page
[1]:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to 
> a given precertificate has or has not been issued. It is only safe to 
> assume that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the 
> certificate authority's intent to issue a certificate.  This intent is 
> considered binding (i.e., misissuance of the Precertificate is 
> considered equal to misissuance of the final certificate).”
>
>
>
> However, BR 7.1.2.5 state “For purposes of clarification, a 
> Precertificate, as described in RFC 6962 – Certificate Transparency, 
> shall not be considered to be a “certificate” subject to the 
> requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and 
> Certificate Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing 
> CAs to issue a precertificate containing the same serial number as the 
> subsequent certificate [2]. Mozilla recognizes a precertificate as 
> proof that a corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity 
> certificates apply even when a CA has issued a precertificate without 
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in a 
future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
[2] https://cabforum.org/pipermail/public/2014-January/002694.html

On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Let me try that again since I didn't explain my original post very well.
> Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
>
> What happened at DigiCert is that the OCSP service failed to return a 
> signed response for a certificate where a pre-certificate existed by a 
> certificate had not issued for whatever reason. The question asked was 
> what type of OCSP services are required for a pre-cert if there is no 
> other certificate. The answer we came up with is it should respond 
> "GOOD" based on the Mozilla policy, not Unknown or any other response. 
> Note that this was a bug in the DigiCert system but it lead to a fun internal 
> discussion.
> What I'm sharing is the outcome of the internal discussion - it's only 
> tangentially related to the bug, not the cause or remediation of it.
>
> Summary: Pre-certs require a standard OCSP response as if the pre-cert 
> was a normal cert. In fact, it's a mistake to ever think of pre-certs 
> as anything other than TLS certs, even if the poison extension exists.
>
> The question comes up because the BRs don't cover pre-certs. However, 
> as Ryan points out, the browsers sort-of cover this as does the 
> Mozilla policy. The browser say this is a promise to issue the cert 
> and mis-issuance of a pre-cert is the same as mis-issuance of a cert. 
> Although this isn't mis-issuance in the traditional profile sense, the 
> lack of OCSP services for the pre-cert is a violation of the Mozilla 
> policy. I couldn't figure out if it's a violation of the Chrome policy 
> since Chrome says it's a promise to issue a cert. If the cert hasn't 
> issued, then I'm not sure where that puts the OCSP service for Chrome. 
> Regardless, according to Mozilla's policy, the requirement is that 
> regardless of how long the cert takes to issue, the CA must provide 
> OCSP services for the pre-cert. The reason is Mozilla requires an OCSP 
> for each end-entity certificate listing an AIA in the certificate. Pre-certs 
> are end-entity certificat

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Mozilla has, to-date, not published policies related to Certificate
Transparency, but this is a case where a clarification would be helpful. I
propose adding the following language to our "Required Practices" wiki page
[1]:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
>
>
> However, BR 7.1.2.5 state “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a precertificate containing the same serial number as the subsequent
> certificate [2]. Mozilla recognizes a precertificate as proof that a
> corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in
a future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
[2] https://cabforum.org/pipermail/public/2014-January/002694.html

On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Let me try that again since I didn't explain my original post very well.
> Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
>
> What happened at DigiCert is that the OCSP service failed to return a
> signed response for a certificate where a pre-certificate existed by a
> certificate had not issued for whatever reason. The question asked was what
> type of OCSP services are required for a pre-cert if there is no other
> certificate. The answer we came up with is it should respond "GOOD" based
> on the Mozilla policy, not Unknown or any other response. Note that this
> was a bug in the DigiCert system but it lead to a fun internal discussion.
> What I'm sharing is the outcome of the internal discussion - it's only
> tangentially related to the bug, not the cause or remediation of it.
>
> Summary: Pre-certs require a standard OCSP response as if the pre-cert was
> a normal cert. In fact, it's a mistake to ever think of pre-certs as
> anything other than TLS certs, even if the poison extension exists.
>
> The question comes up because the BRs don't cover pre-certs. However, as
> Ryan points out, the browsers sort-of cover this as does the Mozilla
> policy. The browser say this is a promise to issue the cert and
> mis-issuance of a pre-cert is the same as mis-issuance of a cert. Although
> this isn't mis-issuance in the traditional profile sense, the lack of OCSP
> services for the pre-cert is a violation of the Mozilla policy. I couldn't
> figure out if it's a violation of the Chrome policy since Chrome says it's
> a promise to issue a cert. If the cert hasn't issued, then I'm not sure
> where that puts the OCSP service for Chrome. Regardless, according to
> Mozilla's policy, the requirement is that regardless of how long the cert
> takes to issue, the CA must provide OCSP services for the pre-cert. The
> reason is Mozilla requires an OCSP for each end-entity certificate listing
> an AIA in the certificate. Pre-certs are end-entity certificates.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, August 29, 2019 11:55 AM
> To: Peter Bowen ; Ryan Sleevi 
> Cc: Curt Spann ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> Yes. That was the point of my post. There is a requirement fo return an
> ocsp repsonse for a pre cert where the cert hasn't issued because of the
> Mozilla policy. Hence our failure was a Mozilla policy violation even if no
> practical system can use the response because no actual cert (without a
> posion extension) exists.
> __

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Let me try that again since I didn't explain my original post very well. 
Totally worth it since I got a sweet Yu-gi-oh reference out of fit. 

What happened at DigiCert is that the OCSP service failed to return a signed 
response for a certificate where a pre-certificate existed by a certificate had 
not issued for whatever reason. The question asked was what type of OCSP 
services are required for a pre-cert if there is no other certificate. The 
answer we came up with is it should respond "GOOD" based on the Mozilla policy, 
not Unknown or any other response. Note that this was a bug in the DigiCert 
system but it lead to a fun internal discussion. What I'm sharing is the 
outcome of the internal discussion - it's only tangentially related to the bug, 
not the cause or remediation of it.

Summary: Pre-certs require a standard OCSP response as if the pre-cert was a 
normal cert. In fact, it's a mistake to ever think of pre-certs as anything 
other than TLS certs, even if the poison extension exists.

The question comes up because the BRs don't cover pre-certs. However, as Ryan 
points out, the browsers sort-of cover this as does the Mozilla policy. The 
browser say this is a promise to issue the cert and mis-issuance of a pre-cert 
is the same as mis-issuance of a cert. Although this isn't mis-issuance in the 
traditional profile sense, the lack of OCSP services for the pre-cert is a 
violation of the Mozilla policy. I couldn't figure out if it's a violation of 
the Chrome policy since Chrome says it's a promise to issue a cert. If the cert 
hasn't issued, then I'm not sure where that puts the OCSP service for Chrome. 
Regardless, according to Mozilla's policy, the requirement is that regardless 
of how long the cert takes to issue, the CA must provide OCSP services for the 
pre-cert. The reason is Mozilla requires an OCSP for each end-entity 
certificate listing an AIA in the certificate. Pre-certs are end-entity 
certificates.
 
Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 29, 2019 11:55 AM
To: Peter Bowen ; Ryan Sleevi 
Cc: Curt Spann ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte

Yes. That was the point of my post. There is a requirement fo return an ocsp 
repsonse for a pre cert where the cert hasn't issued because of the Mozilla 
policy. Hence our failure was a Mozilla policy violation even if no practical 
system can use the response because no actual cert (without a posion extension) 
exists.

From: Peter Bowen 
Sent: Thursday, August 29, 2019 11:44:11 AM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; Curt Spann ; 
mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: DigiCert OCSP services returns 1 byte



On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy < 
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

> Thanks for posting this Curt.  We investigated and posted an incident 
> report on Bugzilla. The root cause was related to pre-certs and an 
> error in generating certificates for them. We're fixing the issue 
> (should be done shortly).  I figured it'd be good to document here why 
> pre-certs fall under the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my trap 
card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of this, 
since it's known I was not a fan of adding it to the BRs for precisely this 
sort of creative interpretation. I believe you're now the ... fourth... CA 
that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate is 
seen as a binding committment, for purposes of policy, by that CA, that it will 
or has issued an equivalent certificate.

Is there a requirement that a CA return a valid OCSP response for a pre-cert if 
they have not yet issued the equivalent certificate?

Is there a requirement that a CA return a valid OCSP response for a serial 
number that has never been assigned?  I know of several OCSP responders that 
return a HTTP error in this case.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Yes. That was the point of my post. There is a requirement fo return an ocsp 
repsonse for a pre cert where the cert hasn't issued because of the Mozilla 
policy. Hence our failure was a Mozilla policy violation even if no practical 
system can use the response because no actual cert (without a posion extension) 
exists.

From: Peter Bowen 
Sent: Thursday, August 29, 2019 11:44:11 AM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; Curt Spann ; 
mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: DigiCert OCSP services returns 1 byte



On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

> Thanks for posting this Curt.  We investigated and posted an incident
> report on Bugzilla. The root cause was related to pre-certs and an error in
> generating certificates for them. We're fixing the issue (should be done
> shortly).  I figured it'd be good to document here why pre-certs fall under
> the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my
trap card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this
argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of
this, since it's known I was not a fan of adding it to the BRs for
precisely this sort of creative interpretation. I believe you're now the
... fourth... CA that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

Is there a requirement that a CA return a valid OCSP response for a pre-cert if 
they have not yet issued the equivalent certificate?

Is there a requirement that a CA return a valid OCSP response for a serial 
number that has never been assigned?  I know of several OCSP responders that 
return a HTTP error in this case.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Oh, I wasnt arguing that this isnt an issue. The opposite in fact.  I was 
documenting why it is an issue  ie, that a ca can't argue this isnt a 
compliance concern.  It comes up a lot but I dont remember seeing it here.

From: Ryan Sleevi
Sent: Thursday, August 29, 11:38 AM
Subject: Re: DigiCert OCSP services returns 1 byte
To: Jeremy Rowley
Cc: Curt Spann, mozilla-dev-security-pol...@lists.mozilla.org




On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Thanks for posting this Curt.  We investigated and posted an incident report on 
Bugzilla. The root cause was related to pre-certs and an error in generating 
certificates for them. We're fixing the issue (should be done shortly).  I 
figured it'd be good to document here why pre-certs fall under the requirement 
so there's no confusion for other CAs.

Oh, Jeremy, you were going so well on the bug, but now you've activated my trap 
card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of this, 
since it's known I was not a fan of adding it to the BRs for precisely this 
sort of creative interpretation. I believe you're now the ... fourth... CA 
that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate is 
seen as a binding committment, for purposes of policy, by that CA, that it will 
or has issued an equivalent certificate.

1) Has DigiCert reviewed the existing incident reports from other CAs?
2) What process does DigiCert have to review all compliance issues, regardless 
of the CA, so that it can examine its own systems for similar issues or be 
aware of relevant discussions and/or ambiguities?

(And, yes, it's a trap)


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Peter Bowen via dev-security-policy]

On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Thanks for posting this Curt.  We investigated and posted an incident
> > report on Bugzilla. The root cause was related to pre-certs and an error
> in
> > generating certificates for them. We're fixing the issue (should be done
> > shortly).  I figured it'd be good to document here why pre-certs fall
> under
> > the requirement so there's no confusion for other CAs.
> >
>
> Oh, Jeremy, you were going so well on the bug, but now you've activated my
> trap card (since you love the memes :) )
>
> It's been repeatedly documented every time a CA tries to make this
> argument.
>
> Would you suggest we remove that from the BRs? I'm wholly supportive of
> this, since it's known I was not a fan of adding it to the BRs for
> precisely this sort of creative interpretation. I believe you're now the
> ... fourth... CA that's tried to skate on this?
>
> Multiple root programs have clarified: The existence of a pre-certificate
> is seen as a binding committment, for purposes of policy, by that CA, that
> it will or has issued an equivalent certificate.


Is there a requirement that a CA return a valid OCSP response for a
pre-cert if they have not yet issued the equivalent certificate?

Is there a requirement that a CA return a valid OCSP response for a serial
number that has never been assigned?  I know of several OCSP responders
that return a HTTP error in this case.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks for posting this Curt.  We investigated and posted an incident
> report on Bugzilla. The root cause was related to pre-certs and an error in
> generating certificates for them. We're fixing the issue (should be done
> shortly).  I figured it'd be good to document here why pre-certs fall under
> the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my
trap card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this
argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of
this, since it's known I was not a fan of adding it to the BRs for
precisely this sort of creative interpretation. I believe you're now the
... fourth... CA that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

1) Has DigiCert reviewed the existing incident reports from other CAs?
2) What process does DigiCert have to review all compliance issues,
regardless of the CA, so that it can examine its own systems for similar
issues or be aware of relevant discussions and/or ambiguities?

(And, yes, it's a trap)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Thanks for posting this Curt.  We investigated and posted an incident report on 
Bugzilla. The root cause was related to pre-certs and an error in generating 
certificates for them. We're fixing the issue (should be done shortly).  I 
figured it'd be good to document here why pre-certs fall under the requirement 
so there's no confusion for other CAs.   

It can get confusing because the BRs section 7.1.2.7 a pre-cert is "not 
considered a certificate subject to the requirements of RFC 5280". The scope of 
the BRs is also questionable since it's still only applicable to "certificates 
intended to bused for authenticating servers"  (BRs 1.1) . By virtue of the 
poison extension, precerts can never be applicable to authenticating servers. 
Initially, it's easy to think that pre-certs may not require OCSP or the same 
strict compliance

I reviewed the CT log policy and, unless I missed something, the policy there 
is silent on pre-certs and OCSP.

I think the requirement for pre-certs comes from two places. The requirements 
around revocation information originates from Mozilla policy 5.2 "CAs MUST NOT 
issue certificates that have: cRLDistributionPoints or OCSP 
authorityInfoAccess extensions for which no operational CRL or OCSP service 
exists." Then in Section 6 "For end-entity certificates, if the CA provides 
revocation information via an Online Certificate Status Protocol (OCSP) 
service:"

What this means that a CA including a crl distribution point or OCSP service in 
the pre-cert must provide the OCPS/CRL service for the pre-cert, even if 
there's no possible way the pre-cert can be used by Mozilla on a server. The 
idea we had is simply drop the revocation information from the precert. 
Unfortunately, this doesn't work either because the pre-cert must be identical 
to the certificate plus the poison extension.  This was probably obvious to 
anyone following CT over the years, but the discussion comes up every once in a 
while internally so I thought I'd document it externally so others can also 
chime in. 

Feel free to substitute SCT for pre-cert if you want to use correct terminology.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Curt Spann via dev-security-policy
Sent: Tuesday, August 27, 2019 2:05 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: DigiCert OCSP services returns 1 byte

Hello,

I created the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Our super unpublished RFC.  

Sadly no. We're still investigating, but it looks like it has to do with 
pre-certs and the way the system responds if when the actual cert never issued. 
We're working on an incident report. Funny enough (and not in the ha-ha way), 
the system works if the pre-cert was revoked but not if the pre-cert issued but 
something terrible happened between pre-cert issuance and real cert issuance.

-Original Message-
From: dev-security-policy  On 
Behalf Of Peter Gutmann via dev-security-policy
Sent: Tuesday, August 27, 2019 7:27 PM
To: mozilla-dev-security-pol...@lists.mozilla.org; Curt Spann 
Subject: Re: DigiCert OCSP services returns 1 byte

Curt Spann via dev-security-policy  
writes:

>I created the following bug:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1577014

Maybe it's an implementation of OCSP SuperDietLite, 1 = revoked, 0 = not 
revoked.

In terms of it being unsigned, you can get the same effect by setting 
respStatus = TRYLATER, no signature required.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Peter Gutmann via dev-security-policy]

Curt Spann via dev-security-policy  
writes:

>I created the following bug:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1577014

Maybe it's an implementation of OCSP SuperDietLite, 1 = revoked, 0 = not
revoked.

In terms of it being unsigned, you can get the same effect by setting
respStatus = TRYLATER, no signature required.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DigiCert OCSP services returns 1 byte

[Curt Spann via dev-security-policy]

Hello,

I created the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy