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

[[e-mail] (Martin Rex)]

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.


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

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.


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


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

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.

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.



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


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


-Martin