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

Stefan Santesson <stefan@aaa-sec.com> Thu, 01 November 2012 15:39 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 39DA021F8E27 for <pkix@ietfa.amsl.com>; Thu, 1 Nov 2012 08:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.349, 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 o7kbtco8lQ6Z for <pkix@ietfa.amsl.com>; Thu, 1 Nov 2012 08:39:53 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9221F8E24 for <pkix@ietf.org>; Thu, 1 Nov 2012 08:39:52 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9344A326C0 for <pkix@ietf.org>; Thu, 1 Nov 2012 16:39:51 +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 igAWQQXYUd-A for <pkix@ietf.org>; Thu, 1 Nov 2012 16:39:50 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 85498326CD for <pkix@ietf.org>; Thu, 1 Nov 2012 16:39:50 +0100 (CET)
Received: (qmail 7502 invoked from network); 1 Nov 2012 15:39:50 -0000
Received: from host-95-192-12-180.mobileonline.telia.com (HELO [192.168.43.205]) (stefan@fiddler.nu@[95.192.12.180]) (envelope-sender <stefan@aaa-sec.com>) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <piyush@ditenity.com>; 1 Nov 2012 15:39:50 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Thu, 01 Nov 2012 16:39:55 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Piyush Jain <piyush@ditenity.com>, pkix@ietf.org
Message-ID: <CCB85537.52953%stefan@aaa-sec.com>
Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis
In-Reply-To: <028f01cdb844$ca049fc0$5e0ddf40$@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: Thu, 01 Nov 2012 15:39:54 -0000

As a short reply.

No, the good response is still true from a very practical perspective.
It is exactly as written.

Secondly,
Even if the major reason for allowing revoked for non-ussued certs is to
detect/react to compromised CA situations, this does NOT mean that any
request for a non-issued cert is caused by a compromised CA.

It can simply be caused by a bug in the requesting client or a deliberate
false request.
It's therefore wrong to reply that the CA is compromised, unless you know
that the CA is compromised.

/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