Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[[e-mail] (Martin Rex)]

I have strong doubts that regurgitating the entire previous
discussion is going to help.


Piyush Jain wrote:
> > 
> > If you want to describe "an OCSP responder no longer responding 'good'
> > for certificate serial numbers for which no records of issuance exist"
> > as "breaking compatibility with older clients", then yes, this is what
> > we want to do.
> 
> [Piyush] That is not what I implied.  There were alternatives proposed to
> address fraudulently-issued certificates in OCSP (none of them solved the
> problem completely BTW). 

OCSP is *NOT* about certificates and therefore the use of the term
"fraudulently-issued" certificate does not make any sense.

OCSP is about certificate serial status.  Everything else is
inferences by RPs, some of them bold, some of them flawed.


>
> The reason cited by you along with a few others was that any other proposal
> would require clients to be updated. This is what breaking backward
> compatibility means.

If you have an installed base with with a ratio of > 1000:1 for Cli:Srv,
and the choice for a protocol feature update between "having to update
all clients and server" and "having to update only servers", then
the latter has a significant deployment advantage.


> 
> > But in reality, this is change is about fixing a security problem that was
> > documented as such in rfc2560 for the "good" status.
> 
> [Piyush] What security problem?

   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval. 

This text is pretty explicit that "good" is potentially lame, equally lame
as infering "good" from the absence of a revocation on published CRLs.


>
> in RFC 2560 bis and repeated refusal to discuss how 2560bis solves any
> security problems.

rfc2560bis itself does not solve security problems.  We're in the IETF
not in the roman catholic church.

rfc2560bis describes a minimal mitigation that OCSP responder
implementations can adopt to discontinue reporting "good" for "not issued"
certs in a corherent and standardized fashion.


>
> I also see a creative way to circumvent responder trust issue by saying that
> servers indicate "non-issued" by setting the revocation date to 1970 but
> clients should not interpret the response as non-issued.

That is a lame argument.

If you look at the ASN.1 in rfc2560:

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

the "revocationTime" element in RevokedInfo is a mandatory element.
Since our "synthesized" certificateHold revocation status does not
originate from a CRL, we will have to define what value to convey
in revocationTime -- and choose a value that will not interfere with
any future "traditional" status information in case a certificate
with that serial gets issued.

Defining a simple fixed value for this field that can not possibly
cause any such confusion is an obvious, simple and straightforward
engineering solution.


> > 
> > > I believe that Stefan is trying to convey that requiring servers to
> > > return revoked in this context will make them non-compliant with 2560
> > > and 5019 as opposed to breaking interoperability with legacy clients.
> 
> 
> [Piyush] This part I agree with as I stated in my original post. Backward
> compatibility is wrong choice of words. Compliance with other standards is
> the right choice.
> Standards are not backward compatible. Implementations of standards are.

The issue of backwards compatibility also applies to changes of a standard.
If you either newly require different behaviour or prohibit previously
allowed or previously required behaviour, then a standards change is
backwards-incompabible.


Some Qualified Electronic Signature (QES) consumers (including legislation)
require OCSP responders to include a certificateHash as proof-of-issuance
in an OCSP response and require OCSP clients to verify that the
certificateHash is present in a "good" OCSP response and matches the
hash of the certificate under investigation -- as a means to work
around the shortcoming (security problems) inherent in CRLs and
rfc2560 OCSP.  However, such additional requirements are backwards
incompatible and require updating of the entire installed base,
so this approach is typically embraced only where there is not
installed base yet, or when updating the installed base is not
seen as a deterrent to adoption/deployment.


> 
> > The proposed change primarily intends to _standardize_ how to report
> > revoked/certificateHold for "not-issued" certificate serial numbers,
> > something that has been found useful (and already been used) in dealing
> > with certain kinds of security breaches of CAs/RAs.
> > 
> [Piyush] May be so. But that is not the goal cited for this update. Yes a
> few CA vendors may have adopted it but that no way indicates consensus among
> CA vendors.
> If you refer to CAB forum thread, most reputable CA vendors are reluctant to
> adopt it.

What is so difficult about the concept of standardizing/documenting:
"if you want to do this (e.g in case of emergency response), this is how:"


>
> > Returning an error code response status would be
> > just dumb for an authoritative OCSP responder.
> 
> [Piyush] Really. And why is that. It actually makes a lot of sense

No, it does not make any sense at all.  An error code is unsigned and
can be easily inserted into the communication by an attacker.  Which is
why there exists the fallback to CRL checking -- except that it is
impossible to discourage an RP from trusting a non-issued cert
through CRL checking, because the whole concept of revocation through
CRLs is fundamentally flawed and is unable to convey proof-of-issuance.


>
> and that is why CAs "who are not compromised" continue to return
> an error code for such responses.

These kinds of argument are based on two very flawed premises:

 (1) the premise that there exist only two possible states for a CA:
      (a) safe and pristine
      (b) full and thorough compromise of each and everything

 (2) that a huge PKI (100k+ entities) can be nuked and
     re-personalized after a CA compromise at close to zero cost and
     within the blink of an eye

and both premises exhibit a throrough cluelessness about security,
risk management and the real world.


> 
> > Should rfc5019 be interpreted to suggest for authoritative OCSP responders
> > to returning an error code for "not-issued" certs does not make such
> > behaviour any less dumb.
> > 
> [Piyush] The behavior that you are calling dumb has enabled the CAs to scale
> their OCSP infrastructure.
> What is dumb IMO is to continue to run the CA after being compromised and
> demanding that standards be updated to support such behavior.


"scale their OCSP infrastructure"?  *cough*

The TLS multiple OCSP response stapling extension is a design that scales.

On demand CRL downloading and on demand OCSP checking scales between
poorly and hardly.  AFAIK, Verisign put rfc5019 OCSP responder
behaviour into production in early 2004, but Windows XP and Windows 2003
will be end-of-lifed in 2014, never having had revocation checking
enabled by default in their entire lifetime.  And many RPs which do have
revocation checking enabled still soft-fail on OCSP lookup erros.
Non-negligible amounts of programmatic RPs (curl/wget?) probably still
have revocation checking unconfigured or disabled today.


-Martin