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

Stefan Santesson <stefan@aaa-sec.com> Fri, 02 November 2012 16:26 UTC

Return-Path: <stefan@aaa-sec.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 ACDA51F0C44 for <pkix@ietfa.amsl.com>; Fri, 2 Nov 2012 09:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.695
X-Spam-Level:
X-Spam-Status: No, score=-101.695 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
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 4gpjvvIcOhaJ for <pkix@ietfa.amsl.com>; Fri, 2 Nov 2012 09:25:59 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0C70121F8CF5 for <pkix@ietf.org>; Fri, 2 Nov 2012 09:25:58 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id A4163364C0 for <pkix@ietf.org>; Fri, 2 Nov 2012 17:24:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gQMeKE7AIK1x for <pkix@ietf.org>; Fri, 2 Nov 2012 17:24:47 +0100 (CET)
Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 93051364B3 for <pkix@ietf.org>; Fri, 2 Nov 2012 17:24:47 +0100 (CET)
Received: (qmail 18647 invoked from network); 2 Nov 2012 16:24:47 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.113]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender <stefan@aaa-sec.com>) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <piyush@ditenity.com>; 2 Nov 2012 16:24:47 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Fri, 02 Nov 2012 17:24:52 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Piyush Jain <piyush@ditenity.com>, pkix@ietf.org
Message-ID: <CCB9B1A1.52A72%stefan@aaa-sec.com>
Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis
In-Reply-To: <040701cdb910$5d7841f0$1868c5d0$@ditenity.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Fri, 02 Nov 2012 16:26:00 -0000

Piyush and Dave

I'm so sorry. To much stress today. I completely misread your post.

Yes, you made a great point. Thanks for bringing it up. I agree, it makes
perfect sense to not allow the CRL references extension when responding to
non-issued certificates.

/Stefan 



On 11/2/12 4:40 PM, "Piyush Jain" <piyush@ditenity.com> wrote:

>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:stefan@aaa-sec.com]
>> Sent: Friday, November 02, 2012 8:14 AM
>> To: Piyush Jain; pkix@ietf.org
>> Subject: Re: [pkix] Proposed resolution to non-issued certificates -
>2560bis
>> 
>> 
>> 
>> On 11/1/12 11:12 PM, "Piyush Jain" <piyush@ditenity.com> 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:stefan@aaa-sec.com]
>> >> Sent: Thursday, November 01, 2012 12:38 PM
>> >> To: Piyush Jain; pkix@ietf.org
>> >> 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" <piyush@ditenity.com> wrote:
>> >>
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>> >> >> Sent: Thursday, November 01, 2012 8:40 AM
>> >> >> To: Piyush Jain; pkix@ietf.org
>> >> >> 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" <piyush@ditenity.com> wrote:
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>> >> >> >> Sent: Thursday, November 01, 2012 6:11 AM
>> >> >> >> To: Piyush Jain; pkix@ietf.org
>> >> >> >> Subject: Re: [pkix] Proposed resolution to non-issued
>> >> >> >> certificates
>> >> >> >> -
>> >> >> >2560bis
>> >> >> >>
>> >> >> >> In-line;
>> >> >> >>
>> >> >> >> On 11/1/12 12:12 AM, "Piyush Jain" <piyush@ditenity.com> wrote:
>> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >> -----Original Message-----
>> >> >> >> >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org]
>> >> >> >> >> On Behalf Of Stefan Santesson
>> >> >> >> >> Sent: Wednesday, October 31, 2012 11:47 AM
>> >> >> >> >> To: pkix@ietf.org
>> >> >> >> >> 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
>> >> >> >pkix@ietf.org
>> >> >> >https://www.ietf.org/mailman/listinfo/pkix
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>> 
>
>