Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

[Erwann Abalea <[e-mail]>]

2012/10/23 Martin Rex <[e-mail]>

> Erwann Abalea wrote:
> > Martin Rex <[e-mail]> wrote:
> >>
> >> Erwann Abalea wrote:
> >> >> CertificateHold is EXACTLY the correct ReasonCode:
> >> >> It indicates that the CA has not issued a cert with the given serial
> >> >> *YET*, but it MAY eventually issue such a cert in the future
> >> >> (sometimes even in the _very_next_future_ ... i.e. it is about
> >> >>  to become visible to the OCSP responder, but not visible yet).
> >> >
> >> > No. It indicates that the corresponding (existent) certificate has
> been
> >> > put on hold.
> >> > You're asking the CA to assert a status for a non-existent
> certificate.
> >>
> >> Where exactly does X.509 or PKIX require that a serial on a CRL
> >> will have to refer to an existing cert, i.e. one that the CA has
> >> positive proof to have issued.  I (now) believe this is a completely
> >> flawed assumption.
> >
> > X.509, 7.3
> > revokedCertificates identifies certificates that have been revoked. The
> > revoked certificates are identified by their serial
> > numbers.
>
> It uses serial numbers (and an implied isser name) to identify
> certificates in order for disambiguation.
> This is not a requirement that the serial refers to a cert that the
> CA has positive proof to have consciously issued/signed with its key.


We disagree here, clearly.


> > CRL as in "Certificate Revocation List", not as in "inexistent
> Certificate
> > Revocation List".
> > Fraudulently producing certificates is bad, but producing a CRL for
> > nonexistent certificate is good?
>
> Unconvincing.
>
> The C is to clarify that the CRL does not revoke Apples and neither
> Oranges, but Certificates.  And in order to disambiguate between
> certs issued by the same CA, the list identifies/disambiguates
> certs by their serial number.
>
> You're arguing here that DigiNotar was "breaking" the OCSP protocol
> and hurting RPs when they decided to respond "revoked" to requests
> for certs for which they had no record of issuance.  I believe
> it was perfectly reasonable, fully conforming and actively
> helping RPs.
>

Wrong trial. I'm not arguing that DigiNotar broke anything by responding
"revoked" for existent certificates that shouldn't have been produced. I'm
arguing that responding "revoked" for a non existent certificate (that's
different that a "wrongly issued certificate unknown to the CA") cannot be
a CA responsibility.


> Do you realize that X.509 defines a "Revoked Group of certificates"
> crlExtension, with a "serialNumberRange" options.  There is *NO*
> requirement
> that the CA has positively created/issued all certs within the range
> before it can use that extension.  So the idea that a CRL can contain
> revocations for certs for which the CA does not have records of
> issuance is already part of X.509 08/2005!
>

Yes. But who uses that?
Public CAs are required to introduce entropy in the certificate serial
number to defeat prefix-chosen collisions, so the serial number of a
certificate is not sequential anymore.

Distinguishing why in particular a specific serial in not on the
> cert isse record (accidentally lost, fraudulently deleted,
> created by a precomputed hash collision, whathaveyou) would
> be splitting hairs over a total non-issue.


I'm not arguing about the reason a certificate isn't known to the CA, but
on existent vs non-existent (really non-existent) certificates.

> > CRLs and OCSP only assert a state to a certificate serial.
> > > Infering about existance/noexistance of certs is a logical fallacy.
> >
> >
> > The certificate is identified by its serial number (along with its issuer
> > name, of course). What is the meaning/value of a serial number that
> doesn't
> > identify anything?
>
>
> When an RP sends an OCSP with a particular serial, then the OCSP responder
> has to assume that the OCSP requestor is serious about his request
> and is actually looking at a *REAL* certificate.  So it is perfectly valid
> and reasonable for the OCSP responder to refer to that cert from the
> request by the very same serial and return a "revoked, certificateHold"
> status when it can not find this serial on the certificate issue logs.


Really? Do you have access to a real world OCSP responder? You'll find real
dumb things in the logs.
In no particular order:
 - wrong encoding: a '+' gets changed into a "%20" probably because it got
changed into a " " somewhere in the middle
 - wrong encoding: somewhere in the request you'll find data probably
coming from heap/stack corruption (part of environment, or other things)
 - unused URI elements: after the GET request you can find a '?' with a
query string
 - requests for a real certificate serial number but issued to another CA
served by the same OCSP platform (mixed issuer*Hash+serialNumber)
 - requests for a serial number close from a real one, differing only by a
few bits; this raised alarms, required a complete audit of the issuing
platform including authenticated logs, without any result
 - crafted requests with a lot of "/", or a lot of "A" in the base64
encoding, because it's a non authenticated web server, and surely an
attractive target
 - good requests with additional bytes after them, probably some bad use of
strlen() or similar function
 - requests with an unsupported hash algorithm, resulting into a
non-existent issuer*Hash+serialNumber combination, yet the responder has to
reply something; since july I can see some requests with GOST R34.11, all
improperly encoded

You find reasonable to assume that whatever is requested by any
unauthenticated RP corresponds to a real certificate and is a correctly
formed request. That's a wrong assumption and is contradicted by real
world. Yet, additional pressure is put on OCSP producers, not on OCSP
consumers.

> > > What's next? Ask CAs to sign the next OCSP response with a
> > > > "removeFromCRL"
> > > > code for dumb serial numbers for which they replied
> "certificateHold"?
> > > Why
> > > > not also add a holdInstructionCode extension to the OCSP response,
> and
> > > > define proper codes?
> > >
> > > removeFromCRL doesn't make sense in an OCSP response, because OCSP does
> > > not hand out CRLs.
> >
> > But holdInstructionCode could make sense, right?
>
> If you ignore for a moment that holdInstructionCode was removed
> from X.509 08/2005 _and_ rfc5280/PKIX, then id-holdinstruction-reject
> is another STRONG hint that certificateHold was defined intentionally
> with a very broad scope, even though certificateHold at early stages
> might have been motivated by a few, very specific use cases.
>

Reading X.509 11/2008 shows that holdInstructionCode hasn't been removed,
and isn't declared as deprecated. The description of this extension has
been the same since the 08/1997 edition.
I don't know what motivated the removal of this extension in RFC5280, as
it's not even deprecated. Same as privateKeyUsagePeriod. Do RFC5280
consider these extensions as non existent? (a real question)
id-holdinstruction-reject is still declared (in the ASN.1 module), and it
defined a RP behavior to adopt. It's logical to consider that rejecting a
certificates revoked with reason "certificateHold" is a valid behavior. But
that doesn't say that "certificateHold" can be used for whatever reason you
might find useful, and especially not to declare non-existent (really
non-existent) certificates as revoked.


> Sensible protocol designers will try to provide an abstraction for
> initial use cases in order to remain open and easily extensible
> for related usage scenarios in the future.  Having to retrofit
> agility into a protocol can otherwise be very painful.
>
> And while the original 3 basic CertStatus { good, revoked, unknown }
> were evidently short-sighted, the CRLEntry ReasonCode "certificateHold"
> does not suffer from such a limitiation - YMMV.
>
>
> >
> >>>
> >>> With my "CA" hat, I see that OCSP is a hidden cost, and you want to
> make
> >>> it more costly.
> >
> > I have nothing against a "positive assertion", maybe the hash of the
> > certificate for which the responder produces a good answer. If the
> > responder can have access to an issuance log and pick useful
> authoritative
> > information from it and optionally deliver it with the response, I'm
> fine.
> > Asking for a signed response from a bogus request is different. The
> thread
> > then slept into producing a revoked response for bogus requests, and
> > discussing about what could a plausible reason code and revocation date
> be.
>
> Personally, I consider the original OCSP design, where the RP
> rather than the certified entity obtains the OCSP response,
> a fairly useless protocol for online authentication.
>

I see OCSP as a light CRL. The OCSP thisUpdate/nextUpdate have the same
semantic as the CRL lastUpdate/nextUpdate, "good" can be a valid response
for non-existent certificates.
That's unfortunate, I agree. RFC5019 adds some balance, distributing good
practice between OCSP responders and RP.

With the TLS multiple-OCSP-stapling extension, where the cert bearer
> can obtain&refresh the OCSP responses for his own cert chain
> out-of-band, OCSP may become an alternative to CRL processing.
>

OCSP stapling with a blacklist based OCSP suffers the same problem. I'm not
saying that multi-stapling isn't to be pushed.


> > I believe that a well-behaving CA shouldn't produce a CRL containing
> random
> > serial numbers provided by anonymous requesters.
>
> A "CRL request" is a simple download request.  The RP does not convey
> any serials to the CA, and given the serial number space of 160 bits,
> it would be unfeasible for the CA to guess what cert serials an RP,
> who has just requested download of a CRL, is going to check between
> now an the next periodical CRL download.
>

My point was that a CRL is a signed object, a commitment from the
Authority. And the Authority shouldn't declare things on identities it
doesn't know about. A CRL is supposed to revoke known certificates, each
with a correct revocation date (and not something set at epoch 0, you can't
play with revocation dates at will), and possibly with a correct reason and
other extensions.

> By extension, I believe that a well-behaving OCSP responder shouldn't
> > assert anything authoritative (either good or revoked) about a random
> > serial number. That's a fail for the "good" response because an OCSP
> > responder can be based on a blacklist, I don't think that changing "good"
> > into "revoked" is the right way to solve this problem.
>
> A well-behaving OCSP responder is one that does not let RPs fall for
> fraudulent certs when it knows pretty damn well that the cert that
> the RP is requesting the status, for can not possibly be a bona fide
> certificate. An OCSP responder that lets RPs down so recklessly
> does not count as trustworthy on my scorecard. (Bad dog, no cookie).


We agree on this point, a well-behaving OCSP responder shouldn't declare
that a non-existent certificate is valid.
A difference lies in the "non-existent":
 - the serial number really corresponds to a non-existent certificate (even
with a perfect CA, such requests will exist)
 - the serial number corresponds to an existent certificate unknown to the
CA

Case 1 is MUCH more frequent. Case 2 is dangerous (DigiNotar, etc).
The OCSP responder cannot distinguish between the two.
For me, asking for the OCSP responder (often the CA itself) to declare than
a non-existent certificate (Case 1) is revoked is a bad practice, and it
even doesn't solve the problem.
Asking for OCSP responders to add something to "good" responses proving
they have access to a list of issued certificates (like the hash of the
certificate) is a better way to solve the problem. It must be backed-up
with rules or recommendations applied to RP to avoid a fallback to CRLs.

-- 
Erwann.