Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

["Piyush Jain" <[e-mail]>]

Couple of points Stefan

1) The responder is not broadcasting this to the whole world. Only to the
external person who is sending such a request. None of the pkix standards
say that if a revocation provider cites caCompromise as reason for
revocation for an issued certificated, all the certificates issued by that
CA should be considered revoked. On a side note, it might not be a bad thing
if the RP can authoritatively determine if the CA was compromised. However,
it does not apply in this case because it seems that any talk of responder
trust is taboo in the scope of this discussion.

2) CRL References is a single response extension which is part of OCSP. I
can't imagine how this proposed change affects an extension define within
OCSP can be out of scope.

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Friday, November 02, 2012 8:14 AM
> To: Piyush Jain; [e-mail]
> Subject: Re: [pkix] Proposed resolution to non-issued certificates -
2560bis
> 
> 
> 
> On 11/1/12 11:12 PM, "Piyush Jain" <[e-mail]> wrote:
> 
> >So far we've outlined 3 scenarios in which this response makes sense
> >1) Buggy Client
> >2) Malicious client
> >3) CA compromise
> >
> >For 1 and 2, the content of the response does not matter.
> >That leaves us with 3 in which case caCompromise is right choice. And
> >your conclusion is right. Once the CA is compromised, no certificates
> >issued by that CA could be trusted.
> 
> Right, so no external person should be able to cause the OCSP responder to
> claim that the CA is compromised, unless the CA is compromised.
> 
> 
> >
> >BTW, I hope that there will be guidance in the updated draft on what to
> >include in CRL References extension in such cases.
> >It might suffice to say that the responder MUST not include the CRL
> >References extension if it is issuing revoked for fraudulently-issued
> >certificates.
> 
> 
> No, that would be outside of the scope of the OCSP standard. This standard
> describes the OCSP protocol. It can't pose requirements on use of other
> services.
> 
> /Stefan
> 
> >
> >-Piyush
> >
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[e-mail]]
> >> Sent: Thursday, November 01, 2012 12:38 PM
> >> To: Piyush Jain; [e-mail]
> >> Subject: Re: [pkix] Proposed resolution to non-issued certificates -
> >2560bis
> >>
> >> To clear a few things up.
> >>
> >> The current draft does not reflect the straw-poll. It will be updated
> >> to capture that which is/will be agreed.
> >>
> >> CA compromise is a worse choice since it could be interpreted that no
> >certs
> >> from that CA can be trusted.
> >
> >
> >> certificateHold only affects that serialNumber and only temporary,
> >>thus it
> >is
> >> more suitable from a practical standpoint.
> >
> >
> >>
> >> Yes, combined with the optional extension, "good" will be a positive
> >> statement of the existence of the cert. This is perfectly compliant
> >> with
> >the
> >> current "good" text saying "Response extensions may be used to convey
> >> additional information on assertions made by the responder regarding
> >> the status of the certificate such as positive statement about
> >> issuance,
> >validity,
> >> etc"
> >>
> >> /Stefan
> >>
> >>
> >>
> >> On 11/1/12 5:37 PM, "Piyush Jain" <[e-mail]> wrote:
> >>
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Stefan Santesson [mailto:[e-mail]]
> >> >> Sent: Thursday, November 01, 2012 8:40 AM
> >> >> To: Piyush Jain; [e-mail]
> >> >> Subject: Re: [pkix] Proposed resolution to non-issued certificates
> >> >> -
> >> >2560bis
> >> >>
> >> >> As a short reply.
> >> >>
> >> >> No, the good response is still true from a very practical
> >>perspective.
> >> >> It is exactly as written.
> >> >[Piyush] I'm sure you have your reasons. But the obvious question
> >> >that comes to my mind is that if a responder returns revoked for
> >> >non-issued, than why can't good be considered a proof of issuance.
> >> >The current text fails to capture this.
> >> >>
> >> >> Secondly,
> >> >> Even if the major reason for allowing revoked for non-ussued certs
> >> >> is to detect/react to compromised CA situations,
> >> >[Piyush] That is the reason that has been cited. The way I see it is
> >> >to allow CAs to continue operations even after the compromise. I
> >> >have not seen a single discussion on how CA would react if starts
> >> >getting such requests.
> >> >It does give the CAs the tool to advertise the security of their
> >> >systems to unsuspecting customers who do not understand the OCSP
> >> >trust model.
> >> >
> >> >>this does NOT mean that any
> >> >> request for a non-issued cert is caused by a compromised CA.
> >> >
> >> >[Piyush]Nor does it mean that certificate was issued and put on
> >> >hold, which is what certifcateOnHold implies.
> >> >
> >> >>
> >> >> It can simply be caused by a bug in the requesting client or a
> >> >>deliberate
> >> >false
> >> >> request.
> >> >[Piyush] In either of these cases, what the responder returns has no
> >> >value.
> >> >The best response in such cases is to return transport level error
> >> >(HTTP 422).
> >> >I hope that the expectation here is not that this response will help
> >> >RPs to recover from software bugs or that it will teach malicious
> >> >clients to play nice.
> >> >
> >> >> It's therefore wrong to reply that the CA is compromised, unless
> >> >>you know  that the CA is compromised.
> >> >[Piyush] Only scenario that matters is the one in which CA is
> >compromised.
> >> >In every other scenario the content of the response is irrelevant.
> >> >>
> >> >> /Stefan
> >> >>
> >> >>
> >> >> On 11/1/12 4:23 PM, "Piyush Jain" <[e-mail]> wrote:
> >> >>
> >> >> >
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Stefan Santesson [mailto:[e-mail]]
> >> >> >> Sent: Thursday, November 01, 2012 6:11 AM
> >> >> >> To: Piyush Jain; [e-mail]
> >> >> >> Subject: Re: [pkix] Proposed resolution to non-issued
> >> >> >> certificates
> >> >> >> -
> >> >> >2560bis
> >> >> >>
> >> >> >> In-line;
> >> >> >>
> >> >> >> On 11/1/12 12:12 AM, "Piyush Jain" <[e-mail]> wrote:
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: [e-mail] [mailto:[e-mail]]
> >> >> >> >> On Behalf Of Stefan Santesson
> >> >> >> >> Sent: Wednesday, October 31, 2012 11:47 AM
> >> >> >> >> To: [e-mail]
> >> >> >> >> Subject: [pkix] Proposed resolution to non-issued
> >> >> >> >> certificates
> >> >> >> >> - 2560bis
> >> >> >> >>
> >> >> >> >> I didn't put up an end date for the straw-poll, but the
> >> >> >> >>trend seems clear.
> >> >> >> >>
> >> >> >> >> The results so far (if I counted right)
> >> >> >> >>
> >> >> >> >> Supporting #1: 22
> >> >> >> >> Supporting #2: 0
> >> >> >> >> Supporting #3 using "unknown": 6 Supporting #3 using
> >> >> >> >> "unauthorised: 2
> >> >> >> >>
> >> >> >> >> 6 persons supporting #1 has expressed various levels of
> >> >> >> >>support/demand for  an explicit declaration that the OCSP
> >> >> >> >>responder supports the enhanced  definition of "revoked" to
> >> >> >> >>include "no
> >> >issued".
> >> >> >> >>
> >> >> >> >> 1 person responded off-line supporting #1.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> If the trend reflects the opinion of the WG. This is my
> >> >> >> >> proposed
> >> >> >> >> resolution:
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> 1) Extend the "revoked" response to also be allowed for
> >> >> >> >> non-issued certificates. Clearly stating that this is
> >> >> >> >> optional if and only if the
> >> >> >> >OCSP
> >> >> >> >> responder knows that the requested serial number has never
> >> >> >> >> been
> >> >> >> issued.
> >> >> >> >[Piyush] This requires changing the current text for 'good'.
> >> >> >> >Pasted for your reference
> >> >> >> >
> >> >> >> >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. Response
> >> >>extensions
> >> >> >> >   may be used to convey additional information on assertions
> >> >> >> > made
> >> >>by
> >> >> >> >   the responder regarding the status of the certificate such as
> >> >> >> >   positive statement about issuance, validity, etc.
> >> >> >>
> >> >> >> This is still true.
> >> >> >[Piyush]It is tree in theoretical sense, but incomplete and
> >>confusing.
> >> >> >The meaning of 'good' changes, if the responder returns revoked
> >> >> >for 'fraudulently-issued' certificates.
> >> >> > In such cases, a positive proof implies that the certificate was
> >> >>issued.
> >> >> >Also, the last sentence in the above paragraph does not apply for
> >> >> >such responders.
> >> >> >>
> >> >> >> >
> >> >> >> >> 2) Specify that a "revoked" status for a non-issued
> >> >> >> >> certificate serial
> >> >> >> >number
> >> >> >> >> MUST have revocationTime set to Jan 1, 1970 and MUST set the
> >> >> >> >> revocationReason to certificateHold (6).
> >> >> >> >[Piyush] There were some objections on using certificateHold
> >> >> >> >as revocationReason for this purpose. CA compromise would be
> >> >> >> >more appropriate because the only scenario where this is
> >> >> >> >beneficial is when the CA is compromised.
> >> >> >>
> >> >> >> Absolutely not. The CA is not compromised just because I ask
> >> >> >>for a serial  number that was never issued.
> >> >> >
> >> >> >[Piyush] All this time, the reason to propose this change has
> >> >> >been that it helps the situation where certificates are
> >> >> >fraudulently issued. If the RP is not doing signature checking
> >> >> >than this discussion is moot. If RP has verified that signature
> >> >> >is correct and CA thinks it is not issued, it is caCompromise.
> >> >> >CA may be compromised or not. But this response is telling the RP
> >> >> >that if he thinks that certificate is signed by the CA, then it
> >> >> >implies that CA is compromised.
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> >> 2) Define a new optional non-critical extension declaring
> >> >> >> >> that OCSP responder returns "revoked" for non-issued
> >> >> >> >> certificates according to the updated standard. This
> >> >> >> >> extension MUST be present in all responses where the
> >> >> >> >> "revoked" response is returned as a result of a status
> >> >> >> >> request for a
> >> >> >> >non-
> >> >> >> >> issued certificate.
> >> >> >> >[Piyush] Are you proposing that the specification of this
> >> >> >> >extension would be part of OCSP or it would be published as a
> >> >> >> >separate specification?
> >> >> >> >I think that it should not be part of main OCSP specification,
> >> >> >> >given that it is useful only in the exceptional scenario where
> >> >> >> >CA gets compromised.
> >> >> >>
> >> >> >> Proposing to include it in the base standard. It can also be
> >> >> >> used to
> >> >> >measure
> >> >> >> whether an OCSP responder adopts this response behaviour even
> >> >> >>if the CA is  not compromised.
> >> >> >>
> >> >> >[Piyush] This is something new. So what are the benefits of this
> >> >> >if the CA is not compromised? What value does it add over
> >> >> >signature
> >> checking?
> >> >> >And I thought that in one of you previous emails you said that
> >> >> >there was a WG decision to limit changes to RFC 2560 to what is
> >> >> >necessary to resolve previous ambiguity. Don't know if that is
still the
> case.
> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Rationale:
> >> >> >> >> The certificateHold reason feels important for one
> >> >> >> >> particular
> >> >reason.
> >> >> >> >>If a
> >> >> >> >CA is
> >> >> >> >> issuing certificates with sequential serial numbers, then it
> >> >> >> >> could be
> >> >> >> >possible
> >> >> >> >> to obtain a revoked response for a certificate serial number
> >> >> >> >> that is not
> >> >> >> >yet
> >> >> >> >> issued, but soon will be issued. That the certificate serial
> >> >> >> >> number is
> >> >> >> >currently
> >> >> >> >> not issued, does not mean that it never will, thus the
> >> >> >> >> certificateHold
> >> >> >> >reason
> >> >> >> >> seems more appropriate.
> >> >> >> >>
> >> >> >> >[Piyush] Given that a fraudulent certificate has been issued
> >> >> >> >with a serial number, the CA would eventually revoke the
> >> >> >> >certificate with this serial number and would not issue any
> >> >> >> >newer certificate with the same
> >> >> >> serial.
> >> >> >> >I think the confusion arises from the fact that we've been
> >> >> >> >using 'not-issued' and 'fraudulently-issued' interchangeably.
> >> >> >> >All this time I'd been thinking that we are discussing the
> >> >> >> >latter. If that is indeed the case, caCompromise seems more
> appropriate.
> >> >> >>
> >> >> >> No, for reason above.
> >> >> >>
> >> >> >> >
> >> >> >> >> The date 1 Jan, 1970 is appropriate since it is common in
> >> >> >> >> programming languages to express time as milliseconds since
> >> >> >> >> jan 1,
> >> >> 1970.
> >> >> >> >> Selecting
> >> >> >> >this
> >> >> >> >> time avoids time expression as a negative integer.
> >> >> >> >>
> >> >> >> >> This date translates to (java):
> >> >> >> >> Date revocationTime = new Date(0);  //Jan 1st, 1970
> >> >> >> >>
> >> >> >> >> The extension would be a simple OID with no data structure
> >> >> >> >> and MUST not be set to critical.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Question:
> >> >> >> >> Would it make sense to require an OCSP responder that adopts
> >> >> >> >>the expanded use of "revoked" to always include the new
> >> extension?
> >> >> >> >> It would add the benefit that someone receiving "good" can
> >> >> >> >>know that the  OCSP responder has checked that the
> >> >> >> >>certificate in fact has been issued by  the CA.
> >> >> >> >> In such case it may be reasonable to add an optional data
> >> >> >> >>structure which  MAY contain a hash of the cert.
> >> >> >> >> Such hash would make the positive confirmation even
> >> >> >> >>stronger, adding proof  of existence of the certificate.
> >> >> >> >[Piyush] I hope that you realize that big enterprise PKI
> >> >> >> >deployments use OCSP and CRLs interchangeably. And with this
> >> >> >> >proposal OCSP becomes more authoritative than CRL.
> >> >> >> >So I guess the next step would be to change the basic path
> >> >> >> >validation algorithm to drop the use of CRLs in favor of OCSP
> >> >> >> >and also drop the signature verification (off course if the RP
> >> >> >> >knows that his OCSP responder issues stronger positive
> confirmations).
> >> >> >>
> >> >> >> It is not part of this work to update CRL processing or path
> >> >validation.
> >> >> >[Piyush] Are you saying that there is no need to evaluate how
> >> >> >this work affects other standards created by pkix.
> >> >> >>
> >> >> >> >>
> >> >> >> >> But perhaps this will bee too much to agree on :)
> >> >> >> >>
> >> >> >> >[Piyush] How about a thinner profile of SCVP that could
> >> >> >> >address everything you are trying to achieve in OCSP.
> >> >> >>
> >> >> >> It is neither part of this work to update SCVP. Just to update
> >>OCSP.
> >> >> >[Piyush] SCVP does not need to be updated. It already has
> >> >> >provisions for what you are trying to duplicate in OCSP.
> >> >> >>
> >> >> >> /Stefan
> >> >> >>
> >> >> >
> >> >> >
> >> >> >_______________________________________________
> >> >> >pkix mailing list
> >> >> >[e-mail]
> >> >> >https://www.ietf.org/mailman/listinfo/pkix
> >> >>
> >> >
> >> >
> >>
> >
> >
>