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

mrex@sap.com (Martin Rex) Wed, 24 October 2012 18:10 UTC

Return-Path: <mrex@sap.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7A021F884F for <pkix@ietfa.amsl.com>; Wed, 24 Oct 2012 11:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.054
X-Spam-Level:
X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLtNm-I9MMyG for <pkix@ietfa.amsl.com>; Wed, 24 Oct 2012 11:10:29 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E9AED21F8742 for <pkix@ietf.org>; Wed, 24 Oct 2012 11:10:28 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9OIAHci022590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Oct 2012 20:10:22 +0200 (MEST)
In-Reply-To: <CA+i=0E7KNTUu_388c3qBoWKet2w6a=8xrW5izx99KWsXU6hzhg@mail.gmail.com>
To: Erwann Abalea <eabalea@gmail.com>
Date: Wed, 24 Oct 2012 20:10:16 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20121024181016.503F21A2F3@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: Peter Rybar <peterryb@gmail.com>, pkix@ietf.org, Stefan Santesson <stefan@aaa-sec.com>
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2012 18:10:36 -0000

Erwann Abalea wrote:
> 
> Martin Rex <mrex@sap.com> wrote:
>>
>> 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.

OK. I don't see any convergence.  Let's agree that we disagree.

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

Once Diginotar realized that they may be fraudulent certs around
of which they have no records of issuance, they very probably started
replying "revoked" for *ANY* serial number not in their records,
and did not require anyone to demonstrate to them that the certificate
with that serial really exists.  Safety first.


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

That doesn't matter.  It was just to show you that the spec itself
does not require any certs that appear on a CRL to have actually
ever been issued -- just that they're unambiguously identified.


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

Maybe you completely misunderstood that requirement.
(btw. this is neither a PKIX nor an X.509 requirement).

The CA /Browser Forum Baseline Requirements v1.1 (14-Sep-2012)
https://www.cabforum.org/Baseline_Requirements_V1_1.pdf


  9.6 Certificate Serial Number

  CAs SHOULD generate non-sequential Certificate serial numbers
  that exhibit at least 20 bits of entropy


Non-sequential only means that when a CA issues certs (#n1) and (#n2)
with serial (sn1) and (sn2) and n2 = n1+1 then sn2 = sn1+1 should not apply.

It is, however, perfectly permissible and perfectly sensible that
for n2 > n1  sn2 > sn1 still applies so that ranges will still work,
i.e. to compose a SerialNumber (which is up to 160 bits), from a
strictly monotonically increasing part at the beginning, followed
by a cryptographically random part of at least 20 bits

(Personally, I would use more like 64 random bits, but I also don't
run large CAs that issue millions of certs -- because the size of
the serial significantly impacts the size of the CRLs.  Looking
at one of the CRLs issued by one of the US DOD CAs with more than
one million entries, the cert serials are 3 bytes...).


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


You _are_ splitting hairs.  How would a CA (and its OCSP server) distinguish
certs that are not on record as ever being issued from certs that
are not on record as ever being issued?



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

I don't use OCSP at all.  We're doing online authentication on
large servers, so OCSP, as it currently exists, is a total non-starter.
We do not even implement it.

The TLS extension for stapling multiple OCSP-response might become a
reason to revisit this decision.


> You'll find real dumb things in the logs.


Please don't tell me that this surprised you.  That had to be expected!
And that MUST NOT cause problems.  If a request is for a CA/issuer name
which the OCSP server is not authoritative for, then an unsigned "unknown"
response is just fine.  OCSP doesn't have the "recursion requested"
flag that DNS has.  (Well, unless you count the not well thought out
idea of a universal local OCSP responder).


The only thing that is a real (OCSP) design flaw is the idea that each and
every RP doing online authentication would perform OCSP requests.
That scales nowhere and was obvious from the beginning.

Switching from 1024-bit to 2048-bit RSA keys is probably going to
hit OCSP servers pretty hard (because of the 6x larger CPU-cycles
for the signature operation).
 

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


The operational paradigm of the OCSP protocol specified in rfc2560 
is that OCSP server MUST assume that the client is honest and
serious about his request.


A model where only the certificate holder performs OCSP requests for
his forward cert chain (as with the TLS extension for stapling
multiple OCSP responses) has the advantage that any such cert
holder could use this very certificate to sign the OCSP request --
in case the OCSP server wants some means to recognize requests
from clients that "have paid their due...".



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


X.509 08/2005 page 36: Section 8.5.2.3 Hold instruction code extension
   [...]
   This extension is always non-critical. No standard hold instruction
   codes are defined in this Directory Specification.


X.509 11/2008 page 37: Section 8.5.2.3 Hold instruction code extension

   This extension is always non-critical. No standard hold instruction
   codes are defined in this Directory Specification.

To me, that statement "No standard hold instruction codes are defined
in this Directory Specification." very much says that this feature
was removed from the standard (i.e. is no longer part of the spec).


>
> I don't know what motivated the removal of this extension in RFC5280,

Maybe there are others who understand the X.509 change the way I do?


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

That is non-sense.  No CA needs *your* permission to put whatever
serial it likes on its CRL.  That is entirely up to the discretion
of the CA.  There is no requirement in X.509 and PKIX that such
a serial refers to a cert that a CA has positive proof about
ever having issued.  And this is also entirely irrelevant for the
proper operation/function of the protocol.


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

OCSP isn't all flawed.  What is definitely flawed is the distribution
scheme for OCSP responses (RPs instead of certificate holders),
and the scheme for identifying authorized OCSP responders
(through information in the EE cert, rather than through a
 seperate key/chain hardwired into the CA cert), because the
current OCSP model breaks completely for a CA compromise
(which is a real pity!).


> 
>>> 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 **certificate** is a declaration (signed by the CA) about other
identities.

A CRL entry and an OCSP response are different, identifying only
a serial plus an optional issuer/CA name.  Therefore a revocation
of a serial does not declare things on identities it doesn't know
about -- on the contrary -- it is actually a refusal of the CA
to declare things on identities it doesn't know about.

A CA's OCSP responder who _has_ accessed to the logs of issued
certs, and which does _not_ reply "revoked,certificateHold" on
a serial that it does not find in the CA's issue logs,
is _actively_ declaring things about identities as valid
that it doesn't know about!  So you've actually bitten yourself
in the tail with that statement above.  ;-)


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

The revocation dates for serials that refer to "issued certs" on CRLs are
subject to the CA's Certificate practice statement (CPS), but I'm not
currently aware of any requirements by the specs.

For serials of certs that the CA can no identify as having issued,
the CPS does not apply, so anything goes.


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

Case 2 is dangerous because of the
"Can't happen -- nuke the whole PKI if it happens" approach of X.509.

For OCSP, this could be fixed by changing how an authorized OCSP signer
is identified, by hardwiring a seperate trust path into the CA cert,
rather than into the EE cert.


>
> The OCSP responder cannot distinguish between the two.

Then please let's stop making this useless distinction in the discussion
of the OCSP protocol!


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


The hard-fail option didn't work for the existing OCSP, how likely
is it that it would work for a brand-new optional protocol extension?

The "cert hash" option in the reply can not protect against any attacks,
whereas the "revoked,certificateHold" option for serials not on the
record of issued certs can at least protect against _some_ attacks.

Since there are several design flaws in play, there is not going to be
one single silver bullet that is going to solve all problems.

Not changing anything at all would mean that we will be stuck with the
known problems forever, which does not look like a sensible decision.
So lets try to fix the issues one at a time.  Every journey starts
with a first step.


-Martin