Subject: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate

From: "Piyush Jain" <[email-masked]>
Date: Tue, 15 Jan 2013 09:51:41 -0800

Hi list,

Here is the scenario.

-A certificate with serial number n is signed using the CA private key and
records of issuance are deleted from the database (RA/CA compromise or loss
of issuance records)
- CA issues another certificate with serial number n.

-Piyush

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Jan 2013 17:56:52 +0100 (CET)

Piyush Jain wrote:
> 
> Here is the scenario.
> 
> (1) A certificate with serial number n is signed using the CA private key
>     and records of issuance are deleted from the database (RA/CA
>     compromise or loss of issuance records)
> (2) CA issues another certificate with serial number n.

There is nothing new or unusal about this scenario.  The very similar
scenario, where a fraudulent cert is purposely created with the
serial of a valid existing cert has been explicitly described in
this discussion before (I know I did).

X.509/PKIX and CRLs/OCSP was designed with the assumption that serial
are unique.  We can not change that, because it would be fundamentally
backwards-incompatible.

Updating OCSP to account for this is easy, by including a certificate
hash in the "good" responses as a proof-of-existence.  Only updated
OCSP clients that require that proof-of-existence and verify it,
can notice such an attack, of course.

Negative assertions, such as crlEntries in CRLs and OCSP "revoked"
responses, should probably not include a certificate hash, because
the revocation of a cert serial must be applied to *ALL* certs
with that serial, not just the one that a CA might be aware to have issued.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 17 Jan 2013 09:54:33 -0800

Please accept my apologies Martin. I should've been explicit while posting
this question.
I meant in context of the current update. I know there are a lot of ways to
make the world a better place :), but we can only evaluate the proposals put
in front of us.

Based on your response below, can I conclude that a serial number (according
to current draft) could be both good and non-issued and consequently that a
responder that claims to return revoked for "non-issued" will return 'good'
for some serial numbers associated with "non-issued" certificates.

I would assume that if above is true then at the minimum, we need a
paragraph in security considerations section to capture this scenario.

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: Thursday, January 17, 2013 8:57 AM
> To: Piyush Jain
> Cc: [email-masked]
> Subject: Re: [pkix] what is status of a serial number associated with both
> "issued" ans "non-issued" certificate
> 
> Piyush Jain wrote:
> >
> > Here is the scenario.
> >
scenario,
> where a fraudulent cert is purposely created with the serial of a valid
existing
> cert has been explicitly described in this discussion before (I know I
did).
> 
> X.509/PKIX and CRLs/OCSP was designed with the assumption that serial are
> unique.  We can not change that, because it would be fundamentally
> backwards-incompatible.
> 
> Updating OCSP to account for this is easy, by including a certificate hash
in
> the "good" responses as a proof-of-existence.  Only updated OCSP clients
> that require that proof-of-existence and verify it, can notice such an
attack,
> of course.
> responses, should probably not include a certificate hash, because the
> revocation of a cert serial must be applied to *ALL* certs with that
serial, not
> just the one that a CA might be aware to have issued.
> 
> 
> -Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Jan 2013 20:20:26 +0100 (CET)

Piyush Jain wrote:
>
> Based on your response,  can I conclude that a serial number (according
> to current draft) could be both good and non-issued

Nope, that is impossible.  Due to the fundamental assumption of X.509
that IssuerAndSerial is unique, "issued" is a true boolean, and not
a tree-state.

> and consequently that a

You forgot once again that rfc2560 OCSP is purely about the status of
cert serial numbers, and *NOT* about the status of certificates!

What your thoughts prove is that infering the status of certificates from
the status of cert serials turns into a logical fallacy when the fundamental
assumption of X.509, that IssuerAndSerial are unique, is circumvented.

As it has been regurgitated several times by now, X.509 CRLs and rfc2560
OCSP are unable to properly deal with that situation.  CRLs are a lost cause,
but OCSP could be updated to convey a certificate hash as proof-of-issuance
in the OCSP response, so that updated OCSP clients can recognize the
certificate to which the certificate serial status really applies,
and therefore recognize and properly reject certificates with duplicated
IssuerAndSerials, that are not intended to exist, and to which the
cert serial status does not apply.

> paragraph in security considerations section to capture this scenario.

Due to the persistent misunderstanding by a few readers of rfc2560, that
OCSP would be about certificate status, although it clearly (and provably)
is *ONLY* about certificate _SERIAL_ status, probably warrants a
clarifying rewording of the abstract and protocol overview section,
and an explanation of the difference in the SecurityConsiderations section.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 17 Jan 2013 12:04:02 -0800

> Piyush Jain wrote:
> >
> > Based on your response,  can I conclude that a serial number
> > (according to current draft) could be both good and non-issued
> 
> Nope, that is impossible.  Due to the fundamental assumption of X.509 that
> IssuerAndSerial is unique, "issued" is a true boolean, and not a
tree-state.

[Piyush] I think that we agree that this fundamental assumption is
incorrect, keeping in mind the scenario I described. 
However to move forward, we need to either
- continue to believe this fundamental assumption. This would imply that
non-issued is Boolean state, but also imply that it can be verified by a
simple signature check if the certificate is available to the RP.
- trash the assumption. This would imply that a serial could be good and
non-issued at the same time.

I am okay with either, as long as it is captured in the spec and used as the
basis for future discussions. Switching from one to other, IMO is
non-productive and causes a lot of confusion.
> You forgot once again that rfc2560 OCSP is purely about the status of cert
> serial numbers, and *NOT* about the status of certificates!

[Piyush] I tried to keep it in mind :). Just trying to comprehend if "status
of serial number" has different meaning depending on whether you are the
client or the server. And if it is different, then designing a protocol to
connect the two becomes useless.

> What your thoughts prove is that infering the status of certificates from
the
> status of cert serials turns into a logical fallacy when the fundamental
[Piyush] +1.  Given that all the OCSP clients do it anyway, we need to think
of a way to address this.

> certificate to which the certificate serial status really applies, and
therefore
> recognize and properly reject certificates with duplicated
IssuerAndSerials,
> that are not intended to exist, and to which the cert serial status does
not
> apply.
[Piyush] As I said before, I wanted to keep this discussion focused on what
we have in front of us today. I will be happy to review/provide input if I
see a draft of this extended proposal.
Based on what you are saying, the current update is incomplete and is not
enough to address the problems that you describe above.

> OCSP would be about certificate status, although it clearly (and provably)
is
> *ONLY* about certificate _SERIAL_ status, probably warrants a clarifying
> rewording of the abstract and protocol overview section, and an
explanation
> of the difference in the SecurityConsiderations section.
> 

[Piyush] +1 to the second part of you sentence above.

---

From: Tom Gindin <[email-masked]>
Date: Thu, 17 Jan 2013 20:33:35 -0500

Piyush:

        Suppose we call the state of a certificate serial number which is 
used by both a non-recorded certificate and a valid certificate 
"collision".  I think that we should tell issuers to relieve serial number 
collisions rather than expect RP's to work around them, especially since 
there are many places in PKI standards where the combination of issuer and 
serial number is presumed unique, including CRL's and CMS' 
SignerIdentifier.  Is not the correct action for a CA to perform when it 
detects such a serial number to remove the collision by revoking the valid 
certificate with code "superseded" and (if it's still operating that 
issuer) issuing a new certificate with most of the valid certificate's 
attributes?  Once that is done, the serial number is revoked and the valid 
subject has a valid certificate. 
        This presumes that the CA doesn't revoke that issuer's key and 
start using a new key instead.  Even then, it can reissue a new 
certificate for the valid subject if it chooses.  There's some breakage, 
but less than having an irrevocable certificate around.

Tom Gindin

From:   "Piyush Jain" <[email-masked]>
To:     <[email-masked]>, 
Cc:     [email-masked]
Date:   01/17/2013 03:04 PM
Subject:        Re: [pkix] what is status of a serial number associated 
with both       "issued" ans "non-issued" certificate
Sent by:        [email-masked]

> Nope, that is impossible.  Due to the fundamental assumption of X.509 
that
tree-state.

I am okay with either, as long as it is captured in the spec and used as 
the
basis for future discussions. Switching from one to other, IMO is
non-productive and causes a lot of confusion.
> You forgot once again that rfc2560 OCSP is purely about the status of 
cert
> serial numbers, and *NOT* about the status of certificates!

[Piyush] I tried to keep it in mind :). Just trying to comprehend if 
"status
of serial number" has different meaning depending on whether you are the
client or the server. And if it is different, then designing a protocol to
connect the two becomes useless.

the
> assumption of X.509, that IssuerAndSerial are unique, is circumvented.
[Piyush] +1.  Given that all the OCSP clients do it anyway, we need to 
think
of a way to address this.

therefore
IssuerAndSerials,
not
> apply.
[Piyush] As I said before, I wanted to keep this discussion focused on 
what

is
explanation

> -Martin

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix