From stefan@aaa-sec.com Thu Nov 1 06:11:56 2012 Return-Path: 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 5407321F8A0B for ; Thu, 1 Nov 2012 06:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 laHuopW-Ne-m for ; Thu, 1 Nov 2012 06:11:55 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72D21F8DE7 for ; Thu, 1 Nov 2012 06:10:51 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D51D02DA60 for ; Thu, 1 Nov 2012 14:10:49 +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 ymD973ddmDXr for ; Thu, 1 Nov 2012 14:10:49 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3AED22E47F for ; Thu, 1 Nov 2012 14:10:49 +0100 (CET) Received: (qmail 26513 invoked from network); 1 Nov 2012 13:10:48 -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 ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Nov 2012 13:10:48 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 14:10:49 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis In-Reply-To: <01fc01cdb7bd$43c183b0$cb448b10$@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:11:56 -0000 In-line; On 11/1/12 12:12 AM, "Piyush Jain" 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. > >> 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. > >> 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. >> >> >> 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. >> >> 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. /Stefan From hallam@gmail.com Thu Nov 1 06:42:37 2012 Return-Path: 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 5671721F8E29 for ; Thu, 1 Nov 2012 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wAyMAfzS2ldm for ; Thu, 1 Nov 2012 06:42:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D534221F8E1C for ; Thu, 1 Nov 2012 06:42:35 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2753794obq.31 for ; Thu, 01 Nov 2012 06:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tHIfls8Z29VY0LA3T0l74pm3aI/M7UQpCKKMlZu0dg0=; b=lsXb7dwkg++nCcsB+ACOri02wbiNCp7ZGXwrVtazHCGXrEsoi92Xx1f3cHj64WYgtA rnIfe3ySW+R1Wt3vSni2ax34Wp+bX15JCySM18lcw3sEucGiU91gu7DELKCnNHAsod+g ugqvQqOX+K45XVg9WOVluT0aP353imE3L6b8ep7hy/k8MKJ4l1fqIOvQ4Q3CgKrVUcc8 IKo0XhPiRPTdRhGJ93y7jenQVDy86dOI1LkRsXYfk3BAVUaWSxD+wMtfJ4OAfNFjEZpU Q6h2A5KFLUIT1ys6lTUM6CCSWynV/1/Ih1z/TQt98BwCaZlZsWPH7sY00WQDJFqhBHZi LrhQ== MIME-Version: 1.0 Received: by 10.60.7.41 with SMTP id g9mr33611527oea.18.1351777355226; Thu, 01 Nov 2012 06:42:35 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 1 Nov 2012 06:42:34 -0700 (PDT) In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> Date: Thu, 1 Nov 2012 09:42:34 -0400 Message-ID: From: Phillip Hallam-Baker To: Stefan Santesson Content-Type: multipart/alternative; boundary=e89a8fb2059212dcac04cd6f313a Cc: "pkix@ietf.org" Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:42:37 -0000 --e89a8fb2059212dcac04cd6f313a Content-Type: text/plain; charset=ISO-8859-1 1 and 3b Reading through the thread it appears that the poll has actually turned into 3a Do nothing 3b Add in unknown. But going back to the original straw poll, I think that it is pretty clear that any viable implementation of 'unknown' would have to be implemented as a CRL or OCSP entry that is marked 'Revoked' with a NON CRITICAL extension giving the revocation reason as 'It never existed' Marking the reason as non-critical looks like it is only going to result in the undesired behavior as clients will reject the CRL entry completely and accept the cert as good. Which is stupid behavior but so was not having the status 'never existed'. I would prefer the form of the OCSP 'does not exist' entry to specify a range of cert serial numbers that do not exist. This permits pre-signing of the responses and avoids a potential DoS issue. On Tue, Oct 30, 2012 at 5:52 AM, Stefan Santesson wrote: > Before we loose everyone engaged in this, I would like to make a > straw-poll: > > > Background: > A client may do a request for a certificate that has never been issued by > the CA. > This request may be done deliberately, by mistake or as a consequence of a > compromised CA. > > The OCSP protocol does not require OCSP responders to have any knowledge > about issued certificates. It must only know about revoked certificates > that are within it's current validity period. However, some OCSP > responders closely coupled with the CA may also know if a certificate with > a particular serialNumber value has been issued or not. > > The following is agreed: > - An OCSP responder is allowed to respond "good" to a status request > for a non-revoked certificate, disregarding if it has ever been issued. > > - A client, having no additional out-of-band knowledge about the OCSP > responder, will just know that the certificate is "not revoked" when > receiving a "good" response, unless the response includes one or more > response extensions that provides additional information. > > > The following is debated: > - Is an OCSP responder allowed to respond "revoked" even if a requested > certificate serial number is not on the list of revoked certificates, IF > the OCSP responder has positive knowledge that the requested serial number > does NOT represent a valid certificate issued by the identified CA? > > > Rationale for: > There are a number of reasons to allow this that has been mentioned, such > as: > - It breaks nothing. A legitimate request for an issued certificate will > get a legitimate deterministic response. > - It's safer. Responding "revoked" may not prevent a compromised CA from > being exploited. But if a request for a serialNumber that is known to be > bad is done nevertheless, a "revoked" response will at least be safer than > responding "good". > - Allowing extension definitions with further semantics. A response > extension may be defined in the future that adds more information about > the requested certificate. This may include a positive confirmation that > the certificate has been issued as well as information that this > particular OCSP responder will only respond "good" if it knows that the > requested certificate has been issued, otherwise it will respond > "revoked". An extension with such semantics can only be defined if the > base standard allows a status other than "good" in such situation. > - Supporting Web-PKI. The CAB-Forum has indicated that they will profile > the OCSP protocol for use with web server authentication. In such profile > they have indicated that they will NOT allow the "good" response unless > the requested certificate is known to have been issued. This means that > they will require OCSP responder in their infrastructure to have this > knowledge. Such profile would have to break the base OCSP standard if this > states that "good" MUST be returned unless the certificate has been > revoked. > > Rationale against: > The basic rationale against raised on this list has been the argument that > it is wrong and confusing to allow anything but "good" as a response to a > non-revoked certificate (if the cert is issued by a CA that is served by > this OCSP responder). > Another strong opinion is that it basically does not solve anything. A > broken CA is broken and can't be fixed by responding "revoked". It would > be easy to adapt an attack to circumvent such response, for example by > issuing a fake certificate that duplicates a legitimate serialNumber. > > > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). > > > > > Note: both alternatives are placed in a context where the certificate is > claimed to be issued by a CA that is served by this OCSP responder. The > exact meaning of "bad" is for later discussion. > > Please keep any motivation short and do not use this thread for long > debates. > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --e89a8fb2059212dcac04cd6f313a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1 and 3b

Reading through the thread it appears tha= t the poll has actually turned into=A0

3a Do nothing
3b Add in unknown.

But going back to the or= iginal straw poll, I think that it is pretty clear that any viable implemen= tation of 'unknown' would have to be implemented as a CRL or OCSP e= ntry that is marked 'Revoked' with a NON CRITICAL extension giving = the revocation reason as 'It never existed'

Marking the reason as non-critical looks like it is onl= y going to result in the undesired behavior as clients will reject the CRL = entry completely and accept the cert as good. Which is stupid behavior but = so was not having the status 'never existed'.

I would prefer the form of the OCSP 'does not exist= ' entry to specify a range of cert serial numbers that do not exist. Th= is permits pre-signing of the responses and avoids a potential DoS issue. = =A0



On Tue, Oct 30, 2012 at 5:52 AM, Stefan Santesson <<= a href=3D"mailto:stefan@aaa-sec.com" target=3D"_blank">stefan@aaa-sec.com> wrote:
Before we loose everyone engaged in this, I = would like to make a
straw-poll:


Background:
A client may do a request for a certificate that has never been issued by the CA.
This request may be done deliberately, by mistake or as a consequence of a<= br> compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates
that are within it's current validity period. However, some OCSP
responders closely coupled with the CA may also know if a certificate with<= br> a particular serialNumber value has been issued or not.

The following is agreed:
=A0 =A0- An OCSP responder is allowed to respond "good" to a stat= us request
for a non-revoked certificate, disregarding if it has ever been issued.

=A0 =A0- A client, having no additional out-of-band knowledge about the OCS= P
responder, will just know that the certificate is "not revoked" w= hen
receiving a "good" response, unless the response includes one or = more
response extensions that provides additional information.


The following is debated:
=A0 =A0- Is an OCSP responder allowed to respond "revoked" even i= f a requested
certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number<= br> does NOT represent a valid certificate issued by the identified CA?


Rationale for:
There are a number of reasons to allow this that has been mentioned, such as:
=A0- It breaks nothing. A legitimate request for an issued certificate will=
get a legitimate deterministic response.
=A0- It's safer. Responding "revoked" may not prevent a compr= omised CA from
being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be s= afer than
responding "good".
=A0- Allowing extension definitions with further semantics. A response
extension may be defined in the future that adds more information about
the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this
particular OCSP responder will only respond "good" if it knows th= at the
requested certificate has been issued, otherwise it will respond
"revoked". An extension with such semantics can only be defined i= f the
base standard allows a status other than "good" in such situation= .
=A0- Supporting Web-PKI. The CAB-Forum has indicated that they will profile=
the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response = unless
the requested certificate is known to have been issued. This means that
they will require OCSP responder in their infrastructure to have this
knowledge. Such profile would have to break the base OCSP standard if this<= br> states that "good" MUST be returned unless the certificate has be= en
revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that<= br> it is wrong and confusing to allow anything but "good" as a respo= nse to a
non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder).
Another strong opinion is that it basically does not solve anything. A
broken CA is broken and can't be fixed by responding "revoked"= ;. It would
be easy to adapt an attack to circumvent such response, for example by
issuing a fake certificate that duplicates a legitimate serialNumber.


Please reply with either:

1. Allow "revoked" response for a certificate that has not been &= quot;revoked"
but where that OCSP responder for any other reason knows the certificate to be "bad".

2. Require that the OCSP responder MUST respond "good" in this si= tuation.

3. Neither 1 or 2 (motivate).




Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The
exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long
debates.






_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



--
Website: http://hallambaker.com/

--e89a8fb2059212dcac04cd6f313a-- From david.cooper@nist.gov Thu Nov 1 07:04:21 2012 Return-Path: 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 CE65321F8CA9 for ; Thu, 1 Nov 2012 07:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] 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 r2P1YAbkIv+3 for ; Thu, 1 Nov 2012 07:04:21 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DA05E21F8CAA for ; Thu, 1 Nov 2012 07:04:20 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.421.2; Thu, 1 Nov 2012 10:04:01 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.421.2; Thu, 1 Nov 2012 10:03:42 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id qA1E4H2Q016935; Thu, 1 Nov 2012 10:04:18 -0400 Message-ID: <50928161.3060704@nist.gov> Date: Thu, 1 Nov 2012 10:04:17 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120829 Thunderbird/15.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: IETF PKIX 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:04:21 -0000
Stefan,

In your message yesterday you raised the issue of OCSP responders that have access to a database of issued certificates that are currently valid, but not of the certificates that were issued but that have now expired.  I then noticed that in the straw poll you did not limit the "revoked" response to certificates that have been revoked and certificates that the CA knows haven't never been issued, but indicated that the response could be used whenever the responder 'knows the certificate to be "bad".'  So, it was my understanding that you thought responders could still make use of the proposed expanded definition of "revoked" even if they did not maintain information about expired certificates.

So, which is it?  If a responder has access to a database of issued certificates, but that database does not include certificates that have expired, may the responder reply "revoked" if asked about a serial number that doesn't appear in the database or is it required to respond "good," since the serial number may be referring to a certificate that was issued but that has now expired?

Dave

On 10/31/2012 06:35 PM, Stefan Santesson wrote:

Does your message below mean that you now intend to extend the meaning of "revoked" even further to include certificates that were issued by CA and that were never revoked, but that are now expired? 

No

You got me wrong.

Not issued = never issued.

/Stefan


On 10/31/2012 05:25 PM, Stefan Santesson wrote:
There might be OCSP responders that do have access to a database of issued certs that are currently valid, but not the history of issued certs (expired).
They could not use this extension to include a cert hash as they can't know if a particular serial number of an expired cert is asked for.

Thus it may be wise to separate these issues and keep it simple and just use an OID to indicate this particular behaviour with regard to "revoked" response.
It may be wise therefore to allow a separate process come up with a separate extension for positive confirmations.
Not that I don't like such functionality.

On 10/30/2012 05:52 AM, Stefan Santesson wrote:
Please reply with either:

1. Allow "revoked" response for a certificate that has not been "revoked"
but where that OCSP responder for any other reason knows the certificate
to be "bad".

2. Require that the OCSP responder MUST respond "good" in this situation.

3. Neither 1 or 2 (motivate).
From stefan@aaa-sec.com Thu Nov 1 07:34:21 2012 Return-Path: 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 2CBC921F8DA1 for ; Thu, 1 Nov 2012 07:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.55 X-Spam-Level: X-Spam-Status: No, score=-101.55 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 OgWLhEAugFgb for ; Thu, 1 Nov 2012 07:34:20 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3621F86CE for ; Thu, 1 Nov 2012 07:34:19 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id C87B831585 for ; Thu, 1 Nov 2012 15:34:18 +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 vKl93OOEJE43 for ; Thu, 1 Nov 2012 15:34:18 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 118AF32103 for ; Thu, 1 Nov 2012 15:34:18 +0100 (CET) Received: (qmail 62889 invoked from network); 1 Nov 2012 14:34:17 -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 ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Nov 2012 14:34:17 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 15:34:21 +0100 From: Stefan Santesson To: "David A. Cooper" Message-ID: Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis In-Reply-To: <50928161.3060704@nist.gov> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434628864_34215025" Cc: IETF PKIX 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:34:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3434628864_34215025 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I have proposed nothing of the kind you suggest. The use of "bad" was an attempt to make the poll generic. It was said that the meaning of "bad" is for later discussion. No one have proposed anything but "non-issued" as a case for "bad" in this context and no-one have suggested "non-issued" to mean anything other than never issued. /Stefan From: "David A. Cooper" Date: Thursday, November 1, 2012 3:04 PM To: Stefan Santesson Cc: IETF PKIX Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis > > > Stefan, > > In your message yesterday you raised the issue of OCSP responders that have > access to a database of issued certificates that are currently valid, but not > of the certificates that were issued but that have now expired. I then > noticed that in the straw poll you did not limit the "revoked" response to > certificates that have been revoked and certificates that the CA knows haven't > never been issued, but indicated that the response could be used whenever the > responder 'knows the certificate to be "bad".' So, it was my understanding > that you thought responders could still make use of the proposed expanded > definition of "revoked" even if they did not maintain information about > expired certificates. > > So, which is it? If a responder has access to a database of issued > certificates, but that database does not include certificates that have > expired, may the responder reply "revoked" if asked about a serial number that > doesn't appear in the database or is it required to respond "good," since the > serial number may be referring to a certificate that was issued but that has > now expired? > > Dave > > On 10/31/2012 06:35 PM, Stefan Santesson wrote: > > >> >> >> >> >>> Does your message below mean that you now intend to extend the meaning of >>> "revoked" even further to include certificates that were issued by CA and >>> that were never revoked, but that are now expired? >> >> >> >> >> No >> >> >> >> >> You got me wrong. >> >> >> >> >> Not issued = never issued. >> >> >> >> >> /Stefan >> > > > > > On 10/31/2012 05:25 PM, Stefan Santesson wrote: > > >> >> There might be OCSP responders that do have access to a database of issued >> certs that are currently valid, but not the history of issued certs >> (expired). >> >> They could not use this extension to include a cert hash as they can't know >> if a particular serial number of an expired cert is asked for. >> >> >> >> >> Thus it may be wise to separate these issues and keep it simple and just use >> an OID to indicate this particular behaviour with regard to "revoked" >> response. >> >> It may be wise therefore to allow a separate process come up with a separate >> extension for positive confirmations. >> >> Not that I don't like such functionality. >> > > On 10/30/2012 05:52 AM, Stefan Santesson wrote: > > >> >> Please reply with either: >> >> 1. Allow "revoked" response for a certificate that has not been "revoked" >> but where that OCSP responder for any other reason knows the certificate >> to be "bad". >> >> 2. Require that the OCSP responder MUST respond "good" in this situation. >> >> 3. Neither 1 or 2 (motivate). >> > > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3434628864_34215025 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I have proposed nothing of t= he kind you suggest.

The use of "bad" was an attemp= t to make the poll generic. It was said that the meaning of "bad" is for lat= er discussion.

No one have proposed anything but "n= on-issued" as a case for "bad" in this context and no-one have suggested "no= n-issued" to mean anything other than never issued.

/Stefan

From: "Davi= d A. Cooper" <david.cooper@nist.go= v>
Date: Thursday, November= 1, 2012 3:04 PM
To: Stefan Santes= son <stefan@aaa-sec.com>
Cc: IETF PKIX <pkix@ietf.org>
Subject: <= /span> Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

Stefan,

In your message yesterday you raised the issue of OCSP responders that have access to a database of issued certificates that are currently valid, but not of the certificates that were issued but that have now expired.  I then noticed that in the straw poll yo= u did not limit the "revoked" response to certificates that have been revoked and certificates that the CA knows haven't never been issued, but indicated that the response could be used whenever the responder 'knows the certificate to be "bad".'  So, it was my understanding that you thought responders could still make use of the proposed expanded definition of "revoked" even if they did not maintain information about expired certificates.

So, which is it?  If a responder has access to a database of issued certificates, but that database does not include certificates that have expired, may the responder reply "revoked" if asked about a serial number that doesn't appear in the database or is it required to respond "good," since the serial number may be referring to a certificate that was issued but that has now expired?

Dave

On 10/31/2012 06:35 PM, Stefan Santesson wrote:
=

Does your message below mean that you now intend to extend the meaning of "revoked" even further to include certificates that were issued by CA and that were never revoked, but that are now expired? =

No

You got me wrong.

Not issued =3D never issued.

/Stefan


On 10/31/2012 05:25 PM, Stefan Santesson wrote:
There might be OCSP responders that do have access to a database of issued certs that are currently valid, but not the history of issued certs (expired).
They could not use this extension to include a cert hash as they can't know if a particular serial number of an expired cert is asked for.

Thus it may be wise to separate these issues and keep it simple and just use an OID to indicate this particular behaviour with regard to "revoked" response.
It may be wise therefore to allow a separate process come up with a separate extension for positive confirmations.
Not that I don't like such functionality.

On 10/30/2012 05:52 AM, Stefan Santesson wrote:
= 
Please reply with either:

1. Allow "revoked" response for a certificate that has not been "revoked"
but where that OCSP responder for any other reason knows the certificate
to be "bad".

2. Require that the OCSP responder MUST respond "good" in this situation.

3. Neither 1 or 2 (motivate).
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3434628864_34215025-- From piyush@ditenity.com Thu Nov 1 08:23:09 2012 Return-Path: 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 ACC3621F8AA2 for ; Thu, 1 Nov 2012 08:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 5xFVcra6chbO for ; Thu, 1 Nov 2012 08:23:08 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD74A21F8A91 for ; Thu, 1 Nov 2012 08:23:08 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4252897iec.31 for ; Thu, 01 Nov 2012 08:23:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=1pFAqVGLxrF/6SxAVNMA37m441/Pn0n98bqH7eGPEc8=; b=HwoAECAU8T7SvpiT0TUYPz4hNdUl0+y1W1L0y7PmxFk5AFYjFcS74z0AFxpXlknaLE 0Umay1rD7L4p5hTZKd5IwaEagWundSQ1nst2hcBX6nmpGsBRtcycgRtDLHXG//cDMeTs ToxWvgdtDW1B5y1rIkolm8Pd8psHoiuJvf0S9xVWP+KcR7zKN468R8jSRrnfs4iNoNmA i4E/wdeh8uBILngR9MtbNo+shKLBworm3zuja/XgrWH4sMmtxRAL5sZKGpg2TZFGWF0f vc3A63QjBcFraTqzYtEKk1cjUO5D+ifz+hjjSxxzm/KixXAtBn7oWt5RBknOsdvSw5ex KFlg== Received: by 10.50.104.230 with SMTP id gh6mr1674343igb.13.1351783387975; Thu, 01 Nov 2012 08:23:07 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id c3sm13196397igj.1.2012.11.01.08.23.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 08:23:06 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <01fc01cdb7bd$43c183b0$cb448b10$@ditenity.com> In-Reply-To: Date: Thu, 1 Nov 2012 08:23:02 -0700 Message-ID: <028f01cdb844$ca049fc0$5e0ddf40$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQLU4WFp3f163IB454sKDouJC1jNhZXGvLOw Content-Language: en-us X-Gm-Message-State: ALoCoQnV3SDiK/G0qAIjBDtszzENqYLDgDNYO4AvV8VyKvhAqKDjXoDXiHQOoF0AbdZpoeK5bgKK 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:23:09 -0000 > -----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" 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 > From stefan@aaa-sec.com Thu Nov 1 08:39:54 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 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 To: Piyush Jain , Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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" 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 From piyush@ditenity.com Thu Nov 1 09:37:26 2012 Return-Path: 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 5C57E21F8FE4 for ; Thu, 1 Nov 2012 09:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fJo1HGWiTSfS for ; Thu, 1 Nov 2012 09:37:25 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 439F121F8FCA for ; Thu, 1 Nov 2012 09:37:25 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4362343iec.31 for ; Thu, 01 Nov 2012 09:37:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=rPGuEptrB79slPdgkJ2zWXWlLbKNH6zRk4LUt2d2svw=; b=ZozaDX/yRXG+HFw/slJmNqMj0BXBlSDaJtJH/ehoQNaL65hI7fsuU3LOlXIuJGLG+f H8vNj85ytsxtAe7Ic++geTvvlZ9Yp8jP9LfhjwRxaxvb8x+0Qa9wHrukIskUDb2Z1rtI Fq0aCHj09dCJnLtaLuxKRuJVaBENo0HLkEjSmUB4Sxbjyrgii3GyyQhtp2uwbA83Xgdq 9rpPkqKNu+k3bBPoqVUGvgSF3UjCjJ9iOG+t1dAAE5OfHv63Vl7drfOKoKuBxXQYM2OM 6VEJ/eaN2qoKfXCfXuW+BXModDFs06a2wukZyZ1S4aFZe83pNm5VeAnTn/oIG+2tIve6 7+XA== Received: by 10.50.237.70 with SMTP id va6mr1861692igc.8.1351787844645; Thu, 01 Nov 2012 09:37:24 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ez8sm6137854igb.17.2012.11.01.09.37.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 09:37:23 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <028f01cdb844$ca049fc0$5e0ddf40$@ditenity.com> In-Reply-To: Date: Thu, 1 Nov 2012 09:37:19 -0700 Message-ID: <02a301cdb84f$2a685460$7f38fd20$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQITRFpf3TX/lIOcXMxLIF3O5LbkCpdKDVqw Content-Language: en-us X-Gm-Message-State: ALoCoQkPF6VskyoI7n1YnzqUKPJN8mIA819z3A9CJhw1R7nPio7DMie5zCLql6GZlDg01v+biZya 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:37:26 -0000 > -----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" 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" 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 > From stefan@aaa-sec.com Thu Nov 1 12:39:37 2012 Return-Path: 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 A292021F9395 for ; Thu, 1 Nov 2012 12:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 UEbZIs21mTKV for ; Thu, 1 Nov 2012 12:39:35 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 790B421F9385 for ; Thu, 1 Nov 2012 12:39:33 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 0CDEB18034 for ; Thu, 1 Nov 2012 20:37:53 +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 MrJqQt_wx-qE for ; Thu, 1 Nov 2012 20:37:52 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 27D8518076 for ; Thu, 1 Nov 2012 20:37:52 +0100 (CET) Received: (qmail 8287 invoked from network); 1 Nov 2012 19:37:51 -0000 Received: from host-95-193-224-34.mobileonline.telia.com (HELO [192.168.43.205]) (stefan@fiddler.nu@[95.193.224.34]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Nov 2012 19:37:51 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 20:37:47 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis In-Reply-To: <02a301cdb84f$2a685460$7f38fd20$@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:39:37 -0000 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" 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" 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" 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 >> > > From Internet-Drafts@ietf.org Thu Nov 1 12:49:16 2012 Return-Path: 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 C15C421F94ED; Thu, 1 Nov 2012 12:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 55vDgQRwGeOH; Thu, 1 Nov 2012 12:49:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5933421F9478; Thu, 1 Nov 2012 12:49:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121101194916.14023.28364.idtracker@ietfa.amsl.com> Date: Thu, 01 Nov 2012 12:49:16 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D ACTION:draft-ietf-pkix-rfc5280-clarifications-11.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:49:16 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author(s) : P. Yee Filename : draft-ietf-pkix-rfc5280-clarifications Pages : 8 Date : Nov. 1, 2012 This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc5280-clarifications-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-rfc5280-clarifications"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-11-01124916.I-D@ietf.org> --NextPart-- From piyush@ditenity.com Thu Nov 1 15:13:30 2012 Return-Path: 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 1990C21F928D for ; Thu, 1 Nov 2012 15:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tWgz85+NIGEc for ; Thu, 1 Nov 2012 15:13:29 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85821F89CE for ; Thu, 1 Nov 2012 15:13:06 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4803374iec.31 for ; Thu, 01 Nov 2012 15:13:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=hDTAtPyzNKFuuLZo3xlASmYxUYXEEM9Qdo/QZVhU4c0=; b=dRpe+4WinCLD27tvIBeYq53LncrzJbXdblITA1fFuhxr7B8GjghPO3Tmxxfx3gG7uY TjtfegpBXYL3RPlSuQ+vW4w6tZ2m1DsbHoMSKR/i2ygvkhH279ziY/Pxs8bAx3hG8xmP bM7C/mESpsPSdZACPokXEY9NNJOh3eVY9n4oR4m1rtYf53YrQup3HSo1IfL+gg+Wf8M9 6b193tegdJrkRN+CKXts8Ks4G6UCMVNwKuWxonznSFPwSg+9/Vu3RobH0f5YK6FUjwh/ Th8cCen+u9ljVbtFtyPBD82asGrNyOGF6eVH9FLaIQ+x2okKCi7kToz8l6wxrgcuhEO0 2GBQ== Received: by 10.42.68.68 with SMTP id w4mr27604301ici.30.1351807985761; Thu, 01 Nov 2012 15:13:05 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id u4sm491673igw.6.2012.11.01.15.13.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 15:13:04 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <02a301cdb84f$2a685460$7f38fd20$@ditenity.com> In-Reply-To: Date: Thu, 1 Nov 2012 15:12:59 -0700 Message-ID: <034701cdb87e$0f083a80$2d18af80$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQHKlOnAg8ihb48DeDERbO7FPU2sCJfbyyhw Content-Language: en-us X-Gm-Message-State: ALoCoQkWkqRi31nLipto+kyIcuJsuMteQCrCI7soC8+TG1l4k32e+UwdhVQFmiOWSVa1qH9a8hbI 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:13:30 -0000 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. 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. -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" 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" 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" 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 > >> > > > > > From iesg-secretary@ietf.org Thu Nov 1 15:15:48 2012 Return-Path: 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 A0EE921F84D8; Thu, 1 Nov 2012 15:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, 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 B7AS+S4w7NeA; Thu, 1 Nov 2012 15:15:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22C21F8A62; Thu, 1 Nov 2012 15:15:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121101221547.23437.9250.idtracker@ietfa.amsl.com> Date: Thu, 01 Nov 2012 15:15:47 -0700 Cc: pkix mailing list , pkix chair , RFC Editor Subject: [pkix] Protocol Action: 'Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' to Proposed Standard (draft-ietf-pkix-rfc5280-clarifications-11.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:15:48 -0000 The IESG has approved the following document: - 'Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' (draft-ietf-pkix-rfc5280-clarifications-11.txt) as Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications/ Technical Summary Since the publication of RFC 5280 in May of 2008, several areas have been identified where the document was not clear, thus motivating a “clarifications†update. Experience with CA use of the Certificate Policies extension motivated a change to allow (MAY) use of BMPString. The DANE WG requested that PKIX clarify make an explicit (positive) statement about self-signed certificates that are not marked as CA certificates. PKIX published an informational RFC (5937) and a standards track RFC (5914) related to trust anchor formats and constraints processing by a relying party. This document updates 5280 to point to these documents. Experience with IDNs motivated a minor update to align the details of how such names are processed. The Secruity Considerations section was updated to reflect experience with attacks against CAs. This document addresses all of these issues. Working Group Summary Most of the clarifications in this document were not contentious, except for the self-signed certificate text. Numerous revisions were required to develop text that was acceptable to the WG. The original document editor was replaced as part of this process. He elected to no longer be listed as an author, but he is thanked in the Acknowledgements section. Document Quality This is a very small document and is well written. Most of the clarifications are motivated by experience with existing implementations of CA or RP software. There is no need for a MIB doctor review, there are no Media Types, etc. Personnel Steve Kent is the Document Shepherd, and Sean Turner the Responsible Area Director. From mstjohns@comcast.net Thu Nov 1 21:07:23 2012 Return-Path: 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 0EC2E21F9947 for ; Thu, 1 Nov 2012 21:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.002 X-Spam-Level: X-Spam-Status: No, score=-99.002 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 TGXroDQi07-g for ; Thu, 1 Nov 2012 21:07:22 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 63CBD21F987F for ; Thu, 1 Nov 2012 21:07:21 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta14.westchester.pa.mail.comcast.net with comcast id JTuz1k0020bG4ec5EU7PPs; Fri, 02 Nov 2012 04:07:23 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta03.westchester.pa.mail.comcast.net with comcast id JU751k00F2kB7pQ3PU75Ls; Fri, 02 Nov 2012 04:07:05 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Nov 2012 00:07:26 -0400 To: pkix@ietf.org From: Michael StJohns Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20121102040722.63CBD21F987F@ietfa.amsl.com> Subject: [pkix] CertBag attribute to indicate root of trust? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 04:07:23 -0000 Can any one point me to a defined OID and Attribute class definition that could be used in a PKCS12 CertBag attribute set to indicate that the certificate in the CertBag is a trust anchor? I think I'm looking for something similar to the CommonCertificateAttributes in PKCS15, but there's no defined OID for that object class. Mike From prvs=06536ac167=rybar@nbusr.sk Fri Nov 2 03:16:43 2012 Return-Path: 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 20BD821F99E4 for ; Fri, 2 Nov 2012 03:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.607 X-Spam-Level: X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001] 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 p9GE1w7pRF2m for ; Fri, 2 Nov 2012 03:16:40 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 840B221F99DE for ; Fri, 2 Nov 2012 03:16:37 -0700 (PDT) Message-Id: <201211021016.qA2AGYZA000373@mail.nbusr.sk> From: "Peter Rybar" To: "'Stefan Santesson'" , pkix@ietf.org Date: Fri, 2 Nov 2012 11:16:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01CDB8EB.84275D10" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <034701cdb87e$0f083a80$2d18af80$@ditenity.com> Thread-index: AQHKlOnAg8ihb48DeDERbO7FPU2sCJfbyyhwgADDuHA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.6 X-NAI-Spam-Version: 2.2.0.9309 : core <4389> : streams <850208> : uri <1258271> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:16:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0044_01CDB8EB.84275D10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Stefan, =20 I agree with David A. Cooper and Piyush. =20 And also retroactive revocation is not allowed in X.509. The certificate status "revoked" in OCSP must be consistent with the = status in CRL. In this case it is not consistent because status "revoked" is proposed = to be in OCSP but in the same time it is not included in CRL. Validation will be different by CRL/OCSP! =20 Don't forget that also thisUpdate MUST be correctly used and included in = OCSP response. =20 - thisUpdate: The time at which the status being indicated is known = to be correct. =20 It mans any new "correct" revocation MUST be with revocation value which = is greater than value thisUpdate of any issued CRL/OCSP. Including revocation date/time before value thisUpdate (of any already = issued CRL/OCSP) is destruction of X.509 fundamental rules for = validations. Date and time of revocation MUST be only after value thisUpdate which is = included in last issued CRL or OCSP. =20 [David A. Cooper] In your message yesterday you raised the issue of OCSP responders that = have access to a database of issued certificates that are currently = valid, but not of the certificates that were issued but that have now = expired. As I explained before = (http://www.ietf.org/mail-archive/web/pkix/current/msg31863.html), I = believe that would be a non-backward compatible change. =20 [Piyush] Only scenario that matters is the one in which CA is = compromised. In every other scenario the content of the response is irrelevant. Once the CA is compromised, no certificates issued by that CA could be = trusted. =20 Peter Rybar =20 -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Piyush Jain Sent: Thursday, November 01, 2012 11:13 PM To: 'Stefan Santesson'; pkix@ietf.org Subject: Re: [pkix] Proposed resolution to non-issued certificates - = 2560bis =20 So far we've outlined 3 scenarios in which this response makes sense 1) Buggy Client 2) Malicious client 3) CA compromise =20 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. =20 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. =20 -Piyush =20 > -----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 >=20 > To clear a few things up. >=20 > The current draft does not reflect the straw-poll. It will be updated = to > capture that which is/will be agreed. >=20 > CA compromise is a worse choice since it could be interpreted that no certs > from that CA can be trusted. =20 =20 > certificateHold only affects that serialNumber and only temporary, = thus it is > more suitable from a practical standpoint. =20 =20 >=20 > 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" >=20 > /Stefan >=20 >=20 >=20 > On 11/1/12 5:37 PM, "Piyush Jain" wrote: >=20 > > > > > >> -----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" 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" 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 =3D 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 > >> > > > > >=20 =20 =20 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0044_01CDB8EB.84275D10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Stefan,

 

I agree with David A. Cooper and = Piyush.

 

And also retroactive revocation is not = allowed in X.509.

The certificate status "revoked" in = OCSP must be consistent with the status in CRL.

In this case it is not consistent because = status "revoked" is proposed to be in OCSP but in the same time it is not included in = CRL.

Validation will be different by = CRL/OCSP!

 

Don't forget that also thisUpdate MUST be = correctly used and included in OCSP response.

 

=C2=A0=C2=A0 - thisUpdate: The time at which = the status being indicated is known to be correct.

 

It mans any new "correct" = revocation MUST be with revocation value which is greater than value thisUpdate of any = issued CRL/OCSP.

Including revocation date/time before value = thisUpdate (of any already issued CRL/OCSP) is destruction of X.509 fundamental = rules for validations.

Date and time of revocation MUST be only = after value thisUpdate which is included in last issued CRL or = OCSP.

 

[David A. = Cooper]

=C2=A0In your message yesterday you raised = the issue of OCSP responders that have access to a database of issued certificates = that are currently valid, but not of the certificates that were issued but that = have now expired.

=C2=A0As I explained before (http://www.ietf.org/mail-archive/web/pkix/current/msg31863.html= ), I believe that would be a non-backward compatible change.

 

[Piyush] Only scenario that matters is the = one in which CA is compromised.

=C2=A0In every other scenario the content of = the response is irrelevant.

=C2=A0Once the CA is compromised, no = certificates issued by that CA could be trusted.

 

Peter Rybar

 

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Piyush Jain
Sent: Thursday, November 01, 2012 11:13 PM
To: 'Stefan Santesson'; pkix@ietf.org
Subject: Re: [pkix] Proposed resolution to non-issued certificates - = 2560bis

 

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.

 

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.

 

-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=C2=A0 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=C2=A0 an explicit declaration that the OCSP

> >> >> >>responder = supports the enhanced=C2=A0 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.

> >> >> >=C2=A0=C2=A0 At a = minimum, this positive response indicates that the

> = >>certificate

> >> >> >=C2=A0=C2=A0 is = not revoked, but does not necessarily mean that the

> = >>certificate

> >> >> >=C2=A0=C2=A0 was = ever issued or that the time at which the response was

> = >>produced

> >> >> >=C2=A0=C2=A0 is = within the certificate's validity interval. Response

> = >>extensions

> >> >> >=C2=A0=C2=A0 may = be used to convey additional information on assertions

> >> >> > = made

> >>by

> >> >> >=C2=A0=C2=A0 the = responder regarding the status of the certificate such as

> >> >> >=C2=A0=C2=A0 = 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=C2=A0 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=C2=A0 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 =3D new Date(0);=C2=A0 //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=C2=A0 = OCSP responder has checked that the certificate = in

> >> >> >>fact has been = issued by=C2=A0 the CA.

> >> >> >> In such case = it may be reasonable to add an optional data

> >> >> >>structure = which=C2=A0 MAY contain a hash of the cert.

> >> >> >> Such hash = would make the positive confirmation even stronger,

> >> >> >>adding = proof=C2=A0 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

> >>

> >

> >

>

 

 

______________________________________________= _

pkix mailing = list

pkix@ietf.org

https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_000_0044_01CDB8EB.84275D10-- From simon@tardell.se Fri Nov 2 05:08:19 2012 Return-Path: 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 2AE0021F8818 for ; Fri, 2 Nov 2012 05:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 DlfjX+t1H-eC for ; Fri, 2 Nov 2012 05:08:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43D6121F880E for ; Fri, 2 Nov 2012 05:08:16 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2799743lbo.31 for ; Fri, 02 Nov 2012 05:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/uyWwJRsXq+EpgtrhiXK5PZSPMSK1RwtcHJ15NgQl0E=; b=RyR7XVlTx5bmtGROyXaRxhrlNuGONHbA6qU4DJXeS7azkVk1A88XgkxoL5dI06GAqa gmH0mG+GFKPN4KxuN2sseOUUhhGTjVTbUUHF6rwa2T4DEgMFHAkUg4ugXgzkw4aGKT+d pcYm5AkEDWyq6EPC5EJ+CErrs36yv578MFGr0q+inlygPcYes/7U6AMXQS1lUeEp/fsW 5EOOSay0lt/IALHRHChKfmO4SCQjxpX6pqaYhA13X7UM1SF6FzkwkS3P9vQRNGour4ZH Y0SnwJuDo0rr7q3NBtgoE5E6YzsfrfTa7Dw5U6khaBdKGesRgwX2TaNUqrJrbQLtMIqt 13tA== MIME-Version: 1.0 Received: by 10.112.54.99 with SMTP id i3mr655815lbp.37.1351858095770; Fri, 02 Nov 2012 05:08:15 -0700 (PDT) Received: by 10.112.134.102 with HTTP; Fri, 2 Nov 2012 05:08:15 -0700 (PDT) In-Reply-To: <201211021016.qA2AGYZA000373@mail.nbusr.sk> References: <034701cdb87e$0f083a80$2d18af80$@ditenity.com> <201211021016.qA2AGYZA000373@mail.nbusr.sk> Date: Fri, 2 Nov 2012 13:08:15 +0100 Message-ID: From: Simon Tardell To: Peter Rybar Content-Type: multipart/alternative; boundary=bcaec555544695cc7104cd81fdd1 X-Gm-Message-State: ALoCoQmxURTMznVrQ9V5BkUqDIr2Tj6PA0JgT765VE5fboe1fzZrJIg5YgmnUSLroC/v2DtKG0jK Cc: Stefan Santesson , "pkix@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:08:19 -0000 --bcaec555544695cc7104cd81fdd1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 2, 2012 at 11:16 AM, Peter Rybar wrote: > ** ** > > Stefan,**** > > ** ** > > I agree with David A. Cooper and Piyush.**** > > ** ** > > And also retroactive revocation is not allowed in X.509.**** > > The certificate status "revoked" in OCSP must be consistent with the > status in CRL.**** > > In this case it is not consistent because status "revoked" is proposed to > be in OCSP but in the same time it is not included in CRL.**** > > Validation will be different by CRL/OCSP! > So a CA that does answer revoked for never issued MUST NOT use CRLs. > ** > > Don't forget that also thisUpdate MUST be correctly used and included in > OCSP response.**** > > ** ** > > - thisUpdate: The time at which the status being indicated is known to > be correct.**** > > ** ** > > It mans any new "correct" revocation MUST be with revocation value which > is greater than value thisUpdate of any issued CRL/OCSP. > Including revocation date/time before value thisUpdate (of any already > issued CRL/OCSP) is destruction of X.509 fundamental rules for validations. > **** > > Date and time of revocation MUST be only after value thisUpdate which is > included in last issued CRL or OCSP.**** > > ** > I don't quite understand. The revocationTime of a RevokedInfo must logically be earlier than the thisUpdate of the response, unless we assume that we are dealing with a precog OCSP responder. The OCSP responder should try to keep the thisUpdate as close to "now" as it can, to limit the window where compromised keys can be used. /Simon --bcaec555544695cc7104cd81fdd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, N= ov 2, 2012 at 11:16 AM, Peter Rybar <rybar@nbusr.sk> wrote:
=

Stefan,

=A0

I agree with David A. Cooper and Piyush.

=A0

And also retroactive revocation is not allowed in X.509.

The certificate status "revoked" in OCSP must be consistent with the status in CRL.

In this case it is not consistent because status "revoked" is proposed to be in OCSP but in the same time it is not included in CRL.

Validation will be different by CRL/OCSP!=A0

So a CA that does answer revoked for never issued MUST NOT use CRLs.= =A0

=

Don't forget that also thisUpdate MUST be correctly used and included in OCSP response.

=A0

=A0=A0 - thisUpdate: The time at which the status being indicated is known to be correct.

=A0

It mans any new "correct" revocation MUST be with revocation value which is greater than value thisUpdate of any issued CRL/OCSP.

Including revocation date/time before value thisUpdate (of any already issued CRL/OCSP) is destruction of X.509 fundamental rules = for validations.

Date and time of revocation MUST be only after value thisUpdate which is included in last issued CRL or OCSP.


I do= n't quite understand. The revocationTime of a RevokedInfo must logicall= y be earlier than the thisUpdate of the response, unless we assume that we = are dealing with a precog OCSP responder. The OCSP responder should try to = keep the thisUpdate as close to "now" as it can, to limit the win= dow where compromised keys can be used.=A0
=A0
/Simon
--bcaec555544695cc7104cd81fdd1-- From stefan@aaa-sec.com Fri Nov 2 08:17:57 2012 Return-Path: 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 0B6C71F0C42 for ; Fri, 2 Nov 2012 08:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[AWL=0.582, 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 hq+K+UAYtoVm for ; Fri, 2 Nov 2012 08:17:55 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6967D21F8B77 for ; Fri, 2 Nov 2012 08:17:55 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id C661F36339 for ; Fri, 2 Nov 2012 16:14:13 +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 AJhEVwlx_F8M for ; Fri, 2 Nov 2012 16:14:12 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5E94136337 for ; Fri, 2 Nov 2012 16:14:12 +0100 (CET) Received: (qmail 38659 invoked from network); 2 Nov 2012 15:14:12 -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 ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Nov 2012 15:14:12 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 02 Nov 2012 16:14:15 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis In-Reply-To: <034701cdb87e$0f083a80$2d18af80$@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:17:57 -0000 On 11/1/12 11:12 PM, "Piyush Jain" 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" 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" 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" 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 >> >> >> > >> > >> > > From stefan@aaa-sec.com Fri Nov 2 08:24:26 2012 Return-Path: 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 B5D0C21F87C3 for ; Fri, 2 Nov 2012 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.785 X-Spam-Level: X-Spam-Status: No, score=-100.785 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, 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 Q8Ep7FziEMQz for ; Fri, 2 Nov 2012 08:24:26 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1921F8946 for ; Fri, 2 Nov 2012 08:24:25 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id DD0ED3629B for ; Fri, 2 Nov 2012 16:19:41 +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 mSUFuwdKPUhu for ; Fri, 2 Nov 2012 16:19:39 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C2386362BA for ; Fri, 2 Nov 2012 16:19:28 +0100 (CET) Received: (qmail 96092 invoked from network); 2 Nov 2012 15:19:28 -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 ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Nov 2012 15:19:28 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 02 Nov 2012 16:19:31 +0100 From: Stefan Santesson To: Simon Tardell , Peter Rybar Message-ID: Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434717976_34724110" Cc: "pkix@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:24:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3434717976_34724110 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Agree with Simon, Except on the CRL issue. It is not up to the OCSP standard to limit the use of other services for revocation status checking. Just because security of OCSP has been enhanced slightly, does not necessarily mean that clients must stop using CRL:s. /Stefan From: Simon Tardell Date: Friday, November 2, 2012 1:08 PM To: Peter Rybar Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis > > > > On Fri, Nov 2, 2012 at 11:16 AM, Peter Rybar wrote: >> Stefan, >> >> >> >> I agree with David A. Cooper and Piyush. >> >> >> >> And also retroactive revocation is not allowed in X.509. >> >> The certificate status "revoked" in OCSP must be consistent with the status >> in CRL. >> >> In this case it is not consistent because status "revoked" is proposed to be >> in OCSP but in the same time it is not included in CRL. >> >> Validation will be different by CRL/OCSP! > > So a CA that does answer revoked for never issued MUST NOT use CRLs. >> Don't forget that also thisUpdate MUST be correctly used and included in OCSP >> response. >> >> >> >> - thisUpdate: The time at which the status being indicated is known to be >> correct. >> >> >> >> It mans any new "correct" revocation MUST be with revocation value which is >> greater than value thisUpdate of any issued CRL/OCSP. >> >> Including revocation date/time before value thisUpdate (of any already issued >> CRL/OCSP) is destruction of X.509 fundamental rules for validations. >> >> Date and time of revocation MUST be only after value thisUpdate which is >> included in last issued CRL or OCSP. >> > > I don't quite understand. The revocationTime of a RevokedInfo must logically > be earlier than the thisUpdate of the response, unless we assume that we are > dealing with a precog OCSP responder. The OCSP responder should try to keep > the thisUpdate as close to "now" as it can, to limit the window where > compromised keys can be used. > > /Simon --B_3434717976_34724110 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Agree with Simon,
=
Except on the CRL issue. It is not up to the OCSP standard to= limit the use of other services for revocation status checking.
J= ust because security of OCSP has been enhanced slightly, does not necessaril= y mean that clients must stop using CRL:s.

/Stefan<= /div>

From: Simon Tardell = <simon@tardell.se>
Date: Friday, November 2, 2012 1:08 PM
To: Peter Rybar <rybar@nbusr.sk>
Cc: Stefan Santesson <stefan@aaa-sec.c= om>, "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] Proposed resolution to non-issued certificates= - 2560bis




On Fri, = Nov 2, 2012 at 11:16 AM, Peter Rybar <rybar@nbusr.sk> wrote:

Stefan,=

 

I agree with David A. Cooper= and Piyush.

 

=

And al= so retroactive revocation is not allowed in X.509.

The certificate status "revoked" in OCSP mu= st be consistent with the status in CRL.

In this case= it is not consistent because status "revoked" is proposed to be in OCSP but in the same time it is not included in CRL.

Validation will be different by CRL/OCSP! =

So a CA that does answer revoked for never= issued MUST NOT use CRLs. 

Don't forget that also thisUpdate MUST be c= orrectly used and included in OCSP response.

 <= u>

   - thisUpdate: The time at which the status be= ing indicated is known to be correct.

 =

It mans any new "correct" revocation MUST be with revocation value which is greater than value thisUpdate of any issued CRL/OCSP.

Including revocation date/time before value thi= sUpdate (of any already issued CRL/OCSP) is destruction of X.509 fundamental rules = for validations.

= Date and time of revocation MUST b= e only after value thisUpdate which is included in last issued CRL or OCSP.

<= /u>


I don't qu= ite understand. The revocationTime of a RevokedInfo must logically be earlie= r than the thisUpdate of the response, unless we assume that we are dealing = with a precog OCSP responder. The OCSP responder should try to keep the this= Update as close to "now" as it can, to limit the window where compromised ke= ys can be used. 
 
/Simon
--B_3434717976_34724110-- From david.cooper@nist.gov Fri Nov 2 08:39:38 2012 Return-Path: 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 9D81521F8BC4 for ; Fri, 2 Nov 2012 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MNunRdUU3SIa for ; Fri, 2 Nov 2012 08:39:38 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2FE21F8BC3 for ; Fri, 2 Nov 2012 08:39:37 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.421.2; Fri, 2 Nov 2012 11:39:17 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.421.2; Fri, 2 Nov 2012 11:38:56 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id qA2FdZVJ001843; Fri, 2 Nov 2012 11:39:36 -0400 Message-ID: <5093E937.9030908@nist.gov> Date: Fri, 2 Nov 2012 11:39:35 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120829 Thunderbird/15.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:39:38 -0000 The CRL references extension is defined in Section 4.4.2 of RFC 2560 as an extension that may be included in the singleExtensions field of an OCSP response. So, what is it about Piyush's request that is outside of the scope of the OCSP standard? On 11/02/2012 11:14 AM, Stefan Santesson wrote: > On 11/1/12 11:12 PM, "Piyush Jain" wrote: >> 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 From piyush@ditenity.com Fri Nov 2 08:40:25 2012 Return-Path: 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 2339C1F0C3A for ; Fri, 2 Nov 2012 08:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JySgKIeFIiSj for ; Fri, 2 Nov 2012 08:40:23 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0B21F8B74 for ; Fri, 2 Nov 2012 08:40:23 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so5917464iec.31 for ; Fri, 02 Nov 2012 08:40:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=f6Yevg3xn3RKmg86V77ZNY4h+bcUpG2P/xRhyzpBMz4=; b=Wjw2ViQpWTyEIgej5ZmC/HQ1j+az5vN4xpLhzATfd4TLLZHB5FDaGkq+tG3h/FKirP Qtj1oV3hCzkL8bru0Ed0Ttzbw+pd3GENu/cEJZ9wa460lmesh22LrpMz1fxd3LiOipF4 LCbj/D8BmnFGv+46cyCBfdDnquCaZ5JmFHxwFGJ8gzvuMUDhuSpEpzr3Lj1SuZTZSWDm Z+vviqXJDnf2R+H0XiGhVo2DOZrRJ293Nl4xY6Juavun5I9e31RdAHztnqeOZH8jqDLE tiX2+TY5jfgeNY7O2AMjtnAPDFSP44PwfXeTEYxbIpUO5lxVOWKZdqSaRkoe4VPj7IU1 sRzg== Received: by 10.50.152.197 with SMTP id va5mr2089661igb.12.1351870823121; Fri, 02 Nov 2012 08:40:23 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id v12sm1731755igv.3.2012.11.02.08.40.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:40:22 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <034701cdb87e$0f083a80$2d18af80$@ditenity.com> In-Reply-To: Date: Fri, 2 Nov 2012 08:40:17 -0700 Message-ID: <040701cdb910$5d7841f0$1868c5d0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQK+qD6Bys3dxVhAj7n9K3Hif9yvgZX0zTwA Content-Language: en-us X-Gm-Message-State: ALoCoQnLMPzMvNXG27AczpTIQMFsg2SQda7xXQGqIZOM96J8zHqM5Vz1illBPVQkSFr+gwNswslo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:40:25 -0000 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" 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" 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" 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" 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 > >> >> > >> > > >> > > >> > > > > > From peterryb@gmail.com Fri Nov 2 08:52:43 2012 Return-Path: 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 9331011E80A2 for ; Fri, 2 Nov 2012 08:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qJ7FsFAPbn3P for ; Fri, 2 Nov 2012 08:52:42 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 126F411E80DC for ; Fri, 2 Nov 2012 08:52:39 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2556844pbb.31 for ; Fri, 02 Nov 2012 08:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t+7A5a1WU7byEvdw4TpZxs8RC1gelMIW1+PBP9Au2kE=; b=pVEv+LnBtHO++FCDO1ScUyuZV6IieupLiWrA7Tnbj5hPaaPlpZnPDzGsnvykQKpLq8 dIA1rj3x8lHFNHJzOD85ddMn9yQBiSBOA4g9MVe91f8BK9gEVXVA1VlQ5Y2hfpIhzedi 7WNB9mMIhxsZThAPRUI4T4//T7W9ROWCK0RM4oLapZHgrEJ98sNCPXK4O5gmil72ye1l VJqZVB1t9fvtFXQtBQbsKiY1ilpbpmST79QitaHWqyr+jqSOC0POgZ+IIR/DcnZ12z0S tAIMe/rV0dLv+I4ietm3Sf9x0f2UXbbsgmesIARdk6xpPHLkpMt1tyuhh4eyWGrwMuT2 /+Iw== MIME-Version: 1.0 Received: by 10.66.81.199 with SMTP id c7mr6477845pay.19.1351871071567; Fri, 02 Nov 2012 08:44:31 -0700 (PDT) Received: by 10.66.235.102 with HTTP; Fri, 2 Nov 2012 08:44:31 -0700 (PDT) In-Reply-To: References: <034701cdb87e$0f083a80$2d18af80$@ditenity.com> <201211021016.qA2AGYZA000373@mail.nbusr.sk> Date: Fri, 2 Nov 2012 16:44:31 +0100 Message-ID: From: Peter Rybar To: Simon Tardell Content-Type: text/plain; charset=UTF-8 Cc: Stefan Santesson , "pkix@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:52:43 -0000 It means the time value in thisUpdate field is a time when CA database was locked in the process of creating CRL/OCSP response. CRL contains only revocations with time which were before time value of thisUpdate field. Any revocatins registered while database was locked must not be included and are included after next lock of CA database when a new CRL will be generated. Peter Rybar 2012/11/2, Simon Tardell : > On Fri, Nov 2, 2012 at 11:16 AM, Peter Rybar wrote: > >> ** ** >> >> Stefan,**** >> >> ** ** >> >> I agree with David A. Cooper and Piyush.**** >> >> ** ** >> >> And also retroactive revocation is not allowed in X.509.**** >> >> The certificate status "revoked" in OCSP must be consistent with the >> status in CRL.**** >> >> In this case it is not consistent because status "revoked" is proposed to >> be in OCSP but in the same time it is not included in CRL.**** >> >> Validation will be different by CRL/OCSP! >> > So a CA that does answer revoked for never issued MUST NOT use CRLs. > >> ** >> >> Don't forget that also thisUpdate MUST be correctly used and included in >> OCSP response.**** >> >> ** ** >> >> - thisUpdate: The time at which the status being indicated is known to >> be correct.**** >> >> ** ** >> >> It mans any new "correct" revocation MUST be with revocation value which >> is greater than value thisUpdate of any issued CRL/OCSP. >> > Including revocation date/time before value thisUpdate (of any already >> issued CRL/OCSP) is destruction of X.509 fundamental rules for >> validations. >> **** >> >> Date and time of revocation MUST be only after value thisUpdate which is >> included in last issued CRL or OCSP.**** >> >> ** >> > > I don't quite understand. The revocationTime of a RevokedInfo must > logically be earlier than the thisUpdate of the response, unless we assume > that we are dealing with a precog OCSP responder. The OCSP responder should > try to keep the thisUpdate as close to "now" as it can, to limit the window > where compromised keys can be used. > > /Simon > From simon@tardell.se Fri Nov 2 09:25:00 2012 Return-Path: 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 EA51611E80D2 for ; Fri, 2 Nov 2012 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Gw-AqE-LNyTj for ; Fri, 2 Nov 2012 09:25:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7111E80C5 for ; Fri, 2 Nov 2012 09:24:59 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2981908lbo.31 for ; Fri, 02 Nov 2012 09:24:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=9OwsUyx39VcQr1x0OT7izYPMpyaDSlGLMojLh/bgs0E=; b=ow6QDhyZbGrHotlyG9PTIyUdZVSMiv1u6NFQobY3Pvy/KQxG/HDe4LcDe9f2WUQGdf Apk2+xrQYV0zYwBC0SEGAPeK7iw8MnY2z+pjHnarVQnGTDFeTT12tsBRVtM/QlTd6grI MZPhMNNQbGGlHvKVqND3xJmXIyRoos40stYJRWgrHrb3ewia+jYh7NMmHW6TAf4R/jat I+Kay1VUZSpv3fLgPrg4vM8GqyrZoTJJWdXVHxTGj8SDHCzpGX98znXFtgQPMPtXTtXo doeo8VBq2PRoVUGlrdsGMNsH//6D3u/mwvBz5UbCxMqO3v2Vu61LmUdoPuvpX6JKJUwx EzDg== MIME-Version: 1.0 Received: by 10.152.105.236 with SMTP id gp12mr2135671lab.35.1351873498860; Fri, 02 Nov 2012 09:24:58 -0700 (PDT) Received: by 10.112.134.102 with HTTP; Fri, 2 Nov 2012 09:24:58 -0700 (PDT) In-Reply-To: References: <034701cdb87e$0f083a80$2d18af80$@ditenity.com> <201211021016.qA2AGYZA000373@mail.nbusr.sk> Date: Fri, 2 Nov 2012 17:24:58 +0100 Message-ID: From: Simon Tardell To: Peter Rybar Content-Type: multipart/alternative; boundary=f46d0407144bae4d6304cd8593d6 X-Gm-Message-State: ALoCoQnusRLi52tI5Ib7Zs9dRfPYztSGQDeJia/ncOhqSVd21EMtk617sh1zqW6X1HjxotF3sEB0 Cc: Stefan Santesson , "pkix@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:25:01 -0000 --f46d0407144bae4d6304cd8593d6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 2, 2012 at 4:44 PM, Peter Rybar wrote: > It means the time value in thisUpdate field is a time when CA database > was locked in the process of creating CRL/OCSP response. CRL contains > only revocations with time which were before time value of thisUpdate > field. Any revocatins registered while database was locked must not be > included and are included after next lock of CA database when a new > CRL will be generated. > I am not sure I follow you. Why does the OCSP responder have to care about when the CRLs are produced (if there are any at all) if it has access to the database? /Simon --f46d0407144bae4d6304cd8593d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 2, 2012 a= t 4:44 PM, Peter Rybar <peterryb@gmail.com> wrote:
It means the time value in thisUpdate field is a time when CA database
was locked in the process of creating CRL/OCSP response. CRL contains
only revocations with time which were before time value of thisUpdate
field. Any revocatins registered while database was locked must not be
included and are included after next lock of CA database when a new
CRL will be generated.

I am not sure I = follow you. Why does the OCSP responder have to care about when the CRLs ar= e produced (if there are any at all) if it has access to the database?

/Simon


=A0
--f46d0407144bae4d6304cd8593d6-- From stefan@aaa-sec.com Fri Nov 2 09:26:00 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 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 To: Piyush Jain , Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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" 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" 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" 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" 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 >> >> >> >> >> > >> >> > >> >> >> > >> > >> > > From piyush@ditenity.com Fri Nov 2 10:02:50 2012 Return-Path: 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 F19C211E80AD for ; Fri, 2 Nov 2012 10:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 M15orMseu5na for ; Fri, 2 Nov 2012 10:02:49 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A206511E80A3 for ; Fri, 2 Nov 2012 10:02:49 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6045782iec.31 for ; Fri, 02 Nov 2012 10:02:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=aZEAemuTr9gE7tD2t4Jjoy6NS3+aN/vDKsw7JQx+E1A=; b=kHYT222v7a40tI4QLCY5B2fxDo/cprcBdmwumrN73uxe3XtLFJ/PkEHbSoo8gv7eyC zlSUzEA+CVB8tmpKg+AcOPS6cAaAFq/PH3xY1Vd6JcN73t1LR6QdSYJQLVGm+SJPJFSX +axH69lyOdYxpI/UGQydpTKhBFCLfvbx3R3G/OvpzYvO1+3RHZ8pL/wIp/xyBMId9qqK ETP4zmw2ncOH9HufjDriYVJyzBfHGmtUh9k/FCPCtqb9P8CVOn4gISflbnjtgbZBggX4 CHiix3qNdO15oh0akR66ytJpo9gDQXggBmBdHNkxb8TSD2TJ4Fx9VdtzfYmSGU4OpdZj ZvkA== Received: by 10.50.189.193 with SMTP id gk1mr2427989igc.22.1351875769200; Fri, 02 Nov 2012 10:02:49 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id eo7sm1886053igc.12.2012.11.02.10.02.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 10:02:48 -0700 (PDT) From: "Piyush Jain" To: "'Simon Tardell'" , "'Peter Rybar'" References: <034701cdb87e$0f083a80$2d18af80$@ditenity.com> <201211021016.qA2AGYZA000373@mail.nbusr.sk> In-Reply-To: Date: Fri, 2 Nov 2012 10:02:43 -0700 Message-ID: <044901cdb91b$e1b407a0$a51c16e0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_044A_01CDB8E1.35568F30" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQIIe7Oy5THsO0YxVy92Rnk80DqhjwGlPQVqApslMygCV19GXQHQ9WrIlx33MMA= Content-Language: en-us X-Gm-Message-State: ALoCoQlDynw2SDz67cWFB/Vv1GPUUJILHDmZB5oP2qI/IRPiI933eQFeubmoGuizSg9lHtIV/LlU Cc: 'Stefan Santesson' , pkix@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:02:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_044A_01CDB8E1.35568F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think Peter's point is that most folks consider revocationTime in OCSP equivalent to revocationDate in CRL. This interpretation is not ill-formed given that OCSP has no text describing what revocationTime means in OCSP context. And if you go by this interpretation, according to 5280, revocationDate cannot precede thisUpdate of an earlier CRL if the revocation for the certificate is being reported the first time. Not saying that OCSP has to follow these rules, but given that it is deviating from CRLs on the meaning of revocationTime and revocationReason, a separated section describing these fields should be added. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Simon Tardell Sent: Friday, November 02, 2012 9:25 AM To: Peter Rybar Cc: Stefan Santesson; pkix@ietf.org Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis On Fri, Nov 2, 2012 at 4:44 PM, Peter Rybar wrote: It means the time value in thisUpdate field is a time when CA database was locked in the process of creating CRL/OCSP response. CRL contains only revocations with time which were before time value of thisUpdate field. Any revocatins registered while database was locked must not be included and are included after next lock of CA database when a new CRL will be generated. I am not sure I follow you. Why does the OCSP responder have to care about when the CRLs are produced (if there are any at all) if it has access to the database? /Simon ------=_NextPart_000_044A_01CDB8E1.35568F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think Peter’s point is that most folks consider = revocationTime in OCSP equivalent to revocationDate in = CRL.

This interpretation is not ill-formed given that OCSP has no text = describing what revocationTime means in OCSP = context.

 

And if you go by this interpretation, according to 5280, = revocationDate cannot precede thisUpdate of an earlier CRL if the = revocation for the certificate is being reported the first = time.

 

Not saying that OCSP has to follow these rules, but given that it is = deviating from CRLs on the meaning of revocationTime and = revocationReason, a separated section describing these fields should be = added.

 

-Piyush

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Simon Tardell
Sent: Friday, November 02, 2012 9:25 = AM
To: Peter Rybar
Cc: Stefan Santesson; = pkix@ietf.org
Subject: Re: [pkix] Proposed resolution to = non-issued certificates - 2560bis

 

On = Fri, Nov 2, 2012 at 4:44 PM, Peter Rybar <peterryb@gmail.com> wrote:

It means the time value in thisUpdate field is a time = when CA database
was locked in the process of creating CRL/OCSP = response. CRL contains
only revocations with time which were before = time value of thisUpdate
field. Any revocatins registered while = database was locked must not be
included and are included after next = lock of CA database when a new
CRL will be = generated.

 

I = am not sure I follow you. Why does the OCSP responder have to care about = when the CRLs are produced (if there are any at all) if it has access to = the database?

 

/Simon

 

 

 

------=_NextPart_000_044A_01CDB8E1.35568F30-- From mrex@sap.com Fri Nov 2 11:04:39 2012 Return-Path: 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 CDAFE1F0C5C for ; Fri, 2 Nov 2012 11:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.816 X-Spam-Level: X-Spam-Status: No, score=-9.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 EZSMI+2la75R for ; Fri, 2 Nov 2012 11:04:39 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB16021F93EB for ; Fri, 2 Nov 2012 11:04:38 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qA2I4TV1005952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 19:04:29 +0100 (MET) In-Reply-To: <040701cdb910$5d7841f0$1868c5d0$@ditenity.com> To: Piyush Jain Date: Fri, 2 Nov 2012 19:04:27 +0100 (CET) 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: <20121102180428.017951A323@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:04:39 -0000 Piyush Jain wrote: > Couple of points Stefan > > 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. If this is about the optional CrlID OCSP SingleResponseExtension, I previously mentioned this and Stefan acknowledged it here: http://www.ietf.org/mail-archive/web/pkix/current/msg31881.html -Martin From mrex@sap.com Fri Nov 2 11:46:56 2012 Return-Path: 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 AE1EC1F0C70 for ; Fri, 2 Nov 2012 11:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 U-Gr-OQlj9kK for ; Fri, 2 Nov 2012 11:46:55 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7A01F0C6A for ; Fri, 2 Nov 2012 11:46:55 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qA2Ikkb6012245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 19:46:51 +0100 (MET) In-Reply-To: <044901cdb91b$e1b407a0$a51c16e0$@ditenity.com> To: Piyush Jain Date: Fri, 2 Nov 2012 19:46:44 +0100 (CET) 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: <20121102184644.444221A323@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:46:56 -0000 Piyush Jain wrote: > > I think Peter's point is that most folks consider revocationTime in OCSP > equivalent to revocationDate in CRL. > > This interpretation is not ill-formed given that OCSP has no text describing > what revocationTime means in OCSP context. But somewhat ignorant of how X.509 defines the meaning of revocationDate. ITU-T Rec. X.509 (08/2005), page 34: 8.5.1 Requirements The following requirements relate to CRLs: d) A CRL contains, for each revoked certificate, the date when the authority posted the revocation. Further information may be known as to when an actual or suspected key compromise occurred, and this information may be valuable to a certificate user. The revocation date is insufficient to solve some disputes because, assuming the worst, all signatures issued during the validity period of the certificate have to be considered invalid. However, it may be important for a user that a signed document be recognized as valid even though the key used to sign the message was compromised after the signature was produced. To assist in solving this problem, a CRL entry can include a second date which indicates when it was known or suspected that the private key was compromised. X.509 is pretty clear that the "revocationDate" entry does *NOT* mean when a certificate was revoked, but instead, that it means when a revocation was first published for the cert serial. And this refers to "publication on CRL", because publishing a CRL is the X.509 method to "publish a revocation". revocationDate of a CRL does not give you either of the two interesting times: (a) when a certificate was revoked and (b) since when a certificate is supposed to be invalid. For conveying the latter (b), an optional crlEntry extension was defined, and it is explicitly defined to predate "revocationDate": ITU-T Rec. X.509 (08/2005), page 36: 8.5.2.4 Invalidity date extension This CRL entry extension field indicates the date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid. This date may be earlier than the revocation date in the CRL entry, which is the date at which the authority processed the revocation. But we're actually discussing a certificate status reported through OCSP that is *NOT* based on a revocation on a CRL. So CRL semantics clearly do not apply. Now since the OCSP responder will typically (a) not have access to the cert for which the status is requested, (b) not know for which point in time the client will perform the validity check when obtaining the OCSP response (c) not know whether the RP supports the InvalidityDate extension. A sensible and safe approach to issue a OCSP status response, for a cert for which no record of issue exists, that will cause the RP to reject that cert with very high probability, is to fill revocationDate with a value suffiently far in the past, like Jan 1st, 1970. > > And if you go by this interpretation, according to 5280, revocationDate > cannot precede thisUpdate of an earlier CRL if the revocation for the > certificate is being reported the first time. OCSP was designed to report on status _other_ than revocation, but didn't define any codepoints to convey "reject this cert" other than those defined for CRLs. And from that list, in order to interoperate with the installed base "certificateHold, reject" appears to be the most sensible choice. Look at the history of draft-ietf-pkix-ocsp: Section 3/2 Protocol Overview 01-05: The Online Certificate Status Protocol (OCSP) enables applications to determine the revocation state of an identified certificate. 06-07: The Online Certificate Status Protocol (OCSP) enables applications to determine the state of an identified certificate. rfc2560: The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. OCSP is *NOT* limited to CRLs as information source. But it is currently limited to CRL ReasonCodes to expressing "reject this cert". > > Not saying that OCSP has to follow these rules, but given that it is > deviating from CRLs on the meaning of revocationTime and revocationReason, a > separated section describing these fields should be added. There is no such thing as a strict sequence of OCSP responses, so the conventions that apply to the relation of revocationDate to thisUpdate for a serial listed on a CRL do not apply to OCSP. FWIW, they also apply only to the very first CRL that this serial appears on, so in general, this is a pretty irrelevant characteristic for code that processes CRLs and OCSP responses. -Martin From piyush@ditenity.com Fri Nov 2 12:53:40 2012 Return-Path: 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 4135D11E80D3 for ; Fri, 2 Nov 2012 12:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rQA3+GkWKLos for ; Fri, 2 Nov 2012 12:53:39 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB70111E80BF for ; Fri, 2 Nov 2012 12:53:39 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6272643iec.31 for ; Fri, 02 Nov 2012 12:53:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=jsD0osUO2ozBlfCzzkPsXXpU7S1dW6VteBO+qMN95ms=; b=OXhA1xQNeqNC7iJR7vOudgmMjHTun53F546vjHCwpF1MMyRNB5sFtL29gE7PWwjItW sq4i2sVuE5KGPYUM+OoBA4tHS33of6IiTIZUoraKzC2gMk5p0sivWZrr3UzlDa1gUn52 N7M0UYyPYLvvNvHYu90qfWZxo8cJCTyMKu4rQvXic6Z4ujgoZe95faAFUS8vssK5N2AK ahIHcwTK5Esc4oV9kRfuEJla+EFNhdAD6XFjkyoOlDqc3ALjQuvxcZUgp9K+08Po9ZK3 Lw0oacH3seBkVJ/dDCnek01ooDCegHvayh9FD6ftrbLG+Sug6z0SPzjXl2OxjuJvcWCe P2MA== Received: by 10.50.95.167 with SMTP id dl7mr2812974igb.8.1351886019126; Fri, 02 Nov 2012 12:53:39 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id y10sm2087779igc.13.2012.11.02.12.53.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 12:53:38 -0700 (PDT) From: "Piyush Jain" To: References: <044901cdb91b$e1b407a0$a51c16e0$@ditenity.com> <20121102184644.444221A323@ld9781.wdf.sap.corp> In-Reply-To: <20121102184644.444221A323@ld9781.wdf.sap.corp> Date: Fri, 2 Nov 2012 12:53:33 -0700 Message-ID: <048601cdb933$bf3848e0$3da8daa0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQJEiJilXmVWcNKd2AuhG4Lt91OVIJbpST2g Content-Language: en-us X-Gm-Message-State: ALoCoQko57DFLMWXV5ccQ7KFHWiWXu7ZToJciXQCq0ikfKCsP0uX8fqxRVJdMEt9YXqDTaBjLN4u Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:53:40 -0000 > But somewhat ignorant of how X.509 defines the meaning of revocationDate. Don't know how you concluded this from either mine or Peter's comments. > revocationDate of a CRL does not give you either of the two interesting times: (a) when a certificate was revoked and (b) since when a certificate is supposed to be invalid. My interpretation was that revocationDate tells you a) but not b). For b) you need invalidity date extension. Your assertion is that revocationDate does not tell you the revocation time. I think it is incorrect. Here is the excerpt from 5280 section 5.1.2.6 "Certificates revoked by the CA are uniquely identified by the certificate serial number. The date on which the revocation occurred is specified. The time for revocationDate MUST be expressed as described in section 5.1.2.4." > OCSP was designed to report on status _other_ than revocation, but didn't define any codepoints to convey "reject this cert" other than those defined for CRLs. OCSP explicitly states that good status implies that certificate was never revoked and does not necessarily imply that cert was issued or valid. And that response extension may be used to convey additional information regarding the status such as positive statements about issuance and validity. The code points were not defined but the provision for including those additional statuses is clearly stated - by defining response extension, not by overloading the meaning of revoked. >And from that list, in order to interoperate with the installed base "certificateHold, reject" appears to be the most sensible choice. I fail to understand how this helps interoperability. And what "install base" are you talking about - public CA deployments, enterprise OCSP deployments or something else. > There is no such thing as a strict sequence of OCSP responses, so the > conventions that apply to the relation of revocationDate to thisUpdate for a > serial listed on a CRL do not apply to OCSP. FWIW, they also apply only to the > very first CRL that this serial appears on, so in general, this is a pretty > irrelevant characteristic for code that processes CRLs and OCSP responses. All the more reason to add sections in OCSP to clarify the meaning of revcationTime and revocationReason in OCSP. Currently there is no text for these fields in OCSP and people fallback to 5280 to figure out what it means and how it should be set. From mrex@sap.com Fri Nov 2 15:05:59 2012 Return-Path: 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 B5BF71F0C90 for ; Fri, 2 Nov 2012 15:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.032 X-Spam-Level: X-Spam-Status: No, score=-10.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 RQDqGhOdyytX for ; Fri, 2 Nov 2012 15:05:59 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47C1F0C8C for ; Fri, 2 Nov 2012 15:05:58 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qA2M5nh3022996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 23:05:54 +0100 (MET) In-Reply-To: <048601cdb933$bf3848e0$3da8daa0$@ditenity.com> To: Piyush Jain Date: Fri, 2 Nov 2012 23:05:47 +0100 (CET) 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: <20121102220547.982971A323@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 22:05:59 -0000 Piyush Jain wrote: > > > > revocationDate of a CRL does not give you either of the two interesting > > times: (a) when a certificate was revoked and (b) since when a certificate > > is supposed to be invalid. > > My interpretation was that revocationDate tells you a) but not b). For b) > you need invalidity date extension. Your assertion is that revocationDate > does not tell you the revocation time. I think it is incorrect. Here is the > excerpt from 5280 section 5.1.2.6 > "Certificates revoked by the CA are uniquely identified by the certificate > serial number. The date on which the revocation occurred is specified. The > time for revocationDate MUST be expressed as described in section 5.1.2.4." rfc5280 is inaccurate in that it assumes that "revocationDate" means revocationDate, andignores the X.509 definition. But the date when either the cert holder reported/requested or the CA decided or acknowledged that the cert is to be revoked is somewhat irrelevant for the code that is processing these data structures. The only point in times interesting to them is (a) when was it first posted/published or (b) at which time invalidity should be assumed to have started. > >> >> OCSP was designed to report on status _other_ than revocation, but didn't >> define any codepoints to convey "reject this cert" other than those defined >> for CRLs. > > OCSP explicitly states that good status implies that certificate was never > revoked and does not necessarily imply that cert was issued or valid. > And that response extension may be used to convey additional information > regarding the status such as positive statements about issuance and > validity. Correct. OCSP says that a simple-minded OCSP responder, like one feeding on CRLs, may respond "good" for certs / serials that may have never been issued. What it neither says, and certainly not suggest is that an OCSP responder who is well aware that a certificate was never issued, should also respond "good". It actually fairly basic common sense that the description of positive confirmations of cert issuance is complemented about negative confirmations (=revoked status, due to a lack of alternative negative confirmations) about not-issued certs. > > The code points were not defined but the provision for including > those additional statuses is clearly stated - by defining response > extension, not by overloading the meaning of revoked. The text under good only describes positive confirmations. Negative confirmations would not make any sense under status "good". > >>And from that list, in order to interoperate with the installed base >> "certificateHold, reject" appears to be the most sensible choice. > > I fail to understand how this helps interoperability. And what "install > base" are you talking about - public CA deployments, enterprise OCSP > deployments or something else. The installed base of RPs, to which a responsible OCSP responder wants to deliver the message "you ought to reject this cert", plus counting in that this status can not be conveyed through CRLs (to which some RPs will fallback if OCSP returns an error) or that some implementations will soft-fail when OCSP returns an error. > >> There is no such thing as a strict sequence of OCSP responses, so the >> conventions that apply to the relation of revocationDate to thisUpdate for >> a serial listed on a CRL do not apply to OCSP. FWIW, they also apply only >> to the very first CRL that this serial appears on, so in general, this >> is a pretty irrelevant characteristic for code that processes >> CRLs and OCSP responses. > > All the more reason to add sections in OCSP to clarify the meaning of > revcationTime and revocationReason in OCSP. Currently there is no text for > these fields in OCSP and people fallback to 5280 to figure out what it means > and how it should be set. What the revocationDate means to an RP is extremely context dependent, so if anything could be clarified, then that it can not be clarified due to how its defined in X.509. Recall ITU-T Rec. X.509 (08/2005), page 35 d) A CRL contains, for each revoked certificate, the date when the authority posted the revocation. Further information may be known as to when an actual or suspected key compromise occurred, and this information may be valuable to a certificate user. The revocation date is insufficient to solve some disputes because, assuming the worst, all signatures issued during the validity period of the certificate have to be considered invalid. However, it may be important for a user that a signed document be recognized as valid even though the key used to sign the message was compromised after the signature was produced. To assist in solving this problem, a CRL entry can include a second date which indicates when it was known or suspected that the private key was compromised. "The revocation date is insufficient to solve some disputes ..." "To assist in solving ..." bottom line is that X.509 says, revocationDate can mean anything to anybody, and you might need a layer and a court to analyze what it means with respect to a particular's CA certificate practice statement. It is up to the RP to decide what it means in terms of risk management and whether to ignore any given revocationDate and invalidityDate timestamps. -Martin From piyush@ditenity.com Sat Nov 3 08:40:00 2012 Return-Path: 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 3C85921F9C5E for ; Sat, 3 Nov 2012 08:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 xA030KrpY+J5 for ; Sat, 3 Nov 2012 08:39:59 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9374721F9C55 for ; Sat, 3 Nov 2012 08:39:59 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7092710iec.31 for ; Sat, 03 Nov 2012 08:39:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=gCSWGCPMIIF96c40auYYeorytH1iLYeiMkhx47CDPnQ=; b=bRjjhubPrdad91bAplk7LVX/963Emtgc96964wiux6ZlY07P2fPGfX5WTzMQLTBehk FT7OSQdTWXo61UUzsrLVgVApxT0acurOdcgLwvIi+pESCHby6PPf1t3dTV3as92Wv6ww G49Nxg+V75jIuGP5xPf99vLxcq3JHaZsjMZLnEg5inOnrcgH7SIGrlKSzrGJN5M6k+Jy viECBca/sodirGD9vNJAN3Mlou2O7CVgXhMrBgzophCqVdCHdLRF3np75M8dUhq/qCqS YMYY8uySyIBrH/QxoQZSeDJIkfqobeIbMy8viAoHFv+1YGqLiPbWo6PL83tQ2ze50WrO uO9g== Received: by 10.50.104.232 with SMTP id gh8mr5156540igb.45.1351957198666; Sat, 03 Nov 2012 08:39:58 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id az4sm1747969igb.2.2012.11.03.08.39.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 08:39:57 -0700 (PDT) From: "Piyush Jain" To: References: <048601cdb933$bf3848e0$3da8daa0$@ditenity.com> <20121102220547.982971A323@ld9781.wdf.sap.corp> In-Reply-To: <20121102220547.982971A323@ld9781.wdf.sap.corp> Date: Sat, 3 Nov 2012 08:39:51 -0700 Message-ID: <04dc01cdb9d9$78973670$69c5a350$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGnFFErjxmtMNrrdR7ida+MLlMsFpgkbrwg Content-Language: en-us X-Gm-Message-State: ALoCoQkqmL54GRDz/vnUNt2ff5D5XPIhzUItdU5YUpTxFmyyz7yt2tWIVmO3rCtDA0TGoG0NNIYM Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:40:00 -0000 > But the date when either the cert holder reported/requested or the CA > decided or acknowledged that the cert is to be revoked is somewhat > irrelevant for the code that is processing these data structures. > The only point in times interesting to them is (a) when was it first > posted/published or (b) at which time invalidity should be assumed to have > started. I think these statements about relevance are based on a narrow viewpoint. One example is an application which needs to trigger an audit for all transactions that happened between invalidity time and revocation time. Both dates are required in this case. Just because you have not found a use case does not make this information irrelevant. > What it neither says, and certainly not suggest is that an OCSP responder > who is well aware that a certificate was never issued, should also respond > "good". But it clearly says that responder should return revoked for certificates that have been revoked. > It actually fairly basic common sense that the description of positive confirmations of cert issuance is complemented about negative > confirmations (=revoked status, due to a lack of alternative negative confirmations) about not-issued certs. Again, the common sense you talk about is based on set of limited use cases - public CAs with browser clients. You can find lot of corner cases that people like to address using OCSP. And that is why there are response extensions. Here is another example - Checking the bank balance of the certificate holder before allowing a financial transaction to go through. The negative proof in this case does not warrant a revoked response. Instead the information should be communicated using response extension. And if you are wondering, this is not a fictitious use case. I know of at least one OCSP responder that is designed for such use cases, what the vendor calls 'state-full validations'. What defies common sense is encouraging users to question the signature on EE certificates and trusting the signature on responder certificates, even though both are signed by the same authority. And just to get the terminology right, these are not non-issued certificates, these are certificates issued without the CA's knowledge, i.e. fraudulently issued certificates. So even if the responder decides to return revoked for such certificates, CA compromise is the right reason code. From piyush@ditenity.com Sat Nov 3 09:09:07 2012 Return-Path: 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 3437C21F9C81 for ; Sat, 3 Nov 2012 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0UmF8J-nkKzH for ; Sat, 3 Nov 2012 09:09:06 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE8BB21F9C6B for ; Sat, 3 Nov 2012 09:09:06 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7115761iec.31 for ; Sat, 03 Nov 2012 09:09:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language :x-gm-message-state; bh=QtVI0pIz2736nYRK2sv0MiavwNPLdDXaRCr6xzcLBXk=; b=VRLJjVu2kLcMTAWudnyhJ1/OmiVqMaGqFyqnb0hES/rlvsZ2EKbadVLc57nwOcqlxg HB25g5MpMtH4hY/YEXWRFPLoM0+wWIGc78FN/QiTSvEpgt3/oVEAVpH4A/+GiHB6Jumk 47c5BqlJIcgI2R5un70K7oUSApQ9O7CYXoRPqO20NlP+MKNb4cviTBZODle8b+Fbuch8 nayCoNo04aVRXPvncInz64mh3yrMdlTW3y4pjDwJGEl/Nnkj5+rOVSf7/4JjkgG4aoCL fZJNTiKVQdVDQUuNkax+ni7ad64OgLUhna6yCtSWxjNNuM56fiA1F3e4YpBs03LvrRAE pEiA== Received: by 10.42.44.196 with SMTP id c4mr4428057icf.17.1351958945861; Sat, 03 Nov 2012 09:09:05 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id i10sm1640411igb.12.2012.11.03.09.09.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 09:09:05 -0700 (PDT) From: "Piyush Jain" To: Date: Sat, 3 Nov 2012 09:09:00 -0700 Message-ID: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: Ac252fI84zrgkuQsTJ6998V/rC5zfw== Content-Language: en-us X-Gm-Message-State: ALoCoQlCAeA37X2Qjk6nQq1+jF+MKh8Oe/KndewGtcyANXnyIyWWgNTn8QQg3UWe5/FSc3wHQ6Dw Subject: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:09:07 -0000 Here are a few points about the current proposal - Most folks agree that it adds very little or no incremental security, given current OCSP trust models. The benefits that are mentioned only apply if CA is compromised, but any smart attacker who has compromised the CA can easily circumvent the 'supposed' additional security provided by returning revoked for fraudulent certs. - It adds confusion because users are asked to put different level of trust in two signatures, both generated by the same authority (end entity cert and responder cert) - It introduces functional differences between OCSP and CRLs which are traditionally considered interchangeable from functional point of view by most deployments, thus making revocation checking non-deterministic based on source of revocation information. - Its impact on other features of OCSP (revocation reason, revocation time, crl references, may be others) extends the scope of change to sections beyond the one which re-defines the meaning of revoked. - It can be perceived as an alternative to signature checking if OCSP responder claims to check issuance. The biggest point is that it does not change the protocol specification (bits on wire) at all. Implementations can still decide to return revoked for fraudulently issued certificates without breaking the protocol. So what's the need to introduce this concept in OCSP which can lead many to believe that OCSP can successfully deal with the case of CA compromise? -Piyush From yngve@opera.com Sat Nov 3 12:47:27 2012 Return-Path: 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 AC84521F9CA1 for ; Sat, 3 Nov 2012 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 QHuOGnODdSnR for ; Sat, 3 Nov 2012 12:47:26 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id E862D21F9CB9 for ; Sat, 3 Nov 2012 12:47:15 -0700 (PDT) Received: from acorna.invalid.invalid (119.70.202.84.customer.cdi.no [84.202.70.119]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA3Jl73C016340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 3 Nov 2012 19:47:08 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: pkix@ietf.org References: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> Date: Sat, 03 Nov 2012 20:47:06 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:47:27 -0000 Hi, For reference, my point of view on this topic is that of a browser vendor that have to provide security and trust information to the users of our browser; that is, WebPKI. Our users expect their browser to indicate whether they are on a safe site or not; while that may be a bit above what can be reasonably done, we do use fraud and malware information, as well as certificate revocation checking (for site certificates this is primarily OCSP, not CRLs) to provide the best possible advice to our users. In relation to revocation information we rely on the information provided, in particular by OCSP, to give an accurate and truthful indication of the status of the certificate at the time the response was generated. Personally, I do not consider a "Good" response for a non-issued certificate to be accurate, because the responder cannot truthfully say that the certificate is "Good", as the issuer does not know the certificate was issued, or who uses the certificate. Based on what was revealed about last year's breach of DigiNotar, I proposed to the CABForum, and the CABForum earlier this year accepted, that OCSP responders MUST NOT reply "Good" for a certificate that it does not know has been issued (Effective August 2013). My original proposal was that the response should be "Revoked", but this was rejected as to the language of RFC 2560 seemed to forbid it. Using "Revoked" would have meant that clients would not have had to be updated to handle different responses (as is the case with the final resolution), and would also immediately protect older clients that have not been updated. Please note that my proposal only concerned certificates that have never been issued, it does not define anything about certificates that have been issued, but have expired. The relevant background for my proposal was, as should be known by members of this WG, that the DigiNotar attacker was able to issue certificates that was not tracked by the CA systems, and was thus unknown to the issuer. The certificates were then used to perform MITM attacks on at least Google Mail users living in Iran. Because DigiNotar's OCSP system returned "Good" for serial numbers it did not know, no client seeing these certificates would be able to warn their users about the fake certificate. If the OCSP responder had been required to return something else for these certificates, and which the clients would have treated as Fatal errors, then the attacker would not have been able to use the methods he was using. (For reference, in Opera 12.02 functionality was introduced that treat "Unknown" and "unauthorized" as indications of non-issued certificates, and display a Fatal Error about the certificate being unknown to the issuer, and in the worst case scenario is a fraudulent certificate.) He could have mitigated the effect by blocking access to the OCSP responder, since most clients does not, currently, indicate such failures to the user. However, the browser I develop, Opera, do remove any indication that the site is secure when revocation checks fails to complete successfully, and we have had frequent experience with users reporting the incidents when a site have lost its padlock, most recently involving a bug in our revocation caching system, and host-files overrides that prevent access to the revocation servers (possibly self-inflicted to bypass application licensing requirements). See also . Making it impossible for the attacker to give his certificates a "good" OCSP response means that he will either have to leave the certificate in the database, or have to achieve far deeper and wider penetration of the CA than he would otherwise have needed, in order to compromise other parts of the CA system necessary to successfully obtain fraudulent certificates that can be used. Based on my information, I would guess that the reason the DigiNotar attacker started destroying the logs was that DigiNotar was repeatedly revoking his fraudulent certificates as they were discovered. If so, that means that the revocation system worked, at least in part, and the attacker was forced to find a way around it. As the attacker would need more control, or leave more obvious tracks, that means that there is far better chance of an attack being discovered and stopped. The no-"good"/"revoked" OCSP response suggestions are not a panacea for detecting fraudulent certificates or CA compromise, but it provides an extra layer of security for users, and makes sure the attacker have to jump through a lot more hoops, which make detection more likely (remember, DigiNotar did detect the attacker's activity). Combined with other counter-measures, such as the browser removing secure indications if the revocation check fails (if not going for hard fail), and perhaps other protocols being developed/suggested (pinning, certificate transparency, etc.) it may be possible to make a CA compromise much less profitable or likely to succeed. Personally, I would have preferred that the "does not necessarily mean the certificate was ever issued" text in the definition of "Good" was removed. In my opinion it is dangerous, and should never have been in the text originally, since it requires that CA issuance systems cannot be compromised. Even if it ever made sense to have "Good" as a response for non-issued certificates, in my opinion any reasonable rationale for allowing it went out the window in September 2011, as it was proven that CA issuance systems could be compromised. Given that, as I understand it, one reason for allowing this kind of response in such a case, was that OCSP responders could be based entirely on CRL data, perhaps it is now an idea to retire that entire concept, since it has, at least, proven to be based on one unwarranted assumption: that CAs cannot be compromised. OCSP can, and should, provide more and better information about a certificate's status than CRLs, which after all only provide information about revoked certificates. As for CRLs, maybe they need to be replaced by a Certificate Status List, listing all issued and currently unexpired certificate, and whether they are revoked or not, but that is a different discussion. For further reference, the final report in the DigiNotar incident can be found here: On Sat, 03 Nov 2012 17:09:00 +0100, Piyush Jain wrote: > Here are a few points about the current proposal > - Most folks agree that it adds very little or no incremental security, > given current OCSP trust models. The benefits that are mentioned only > apply > if CA is compromised, but any smart attacker who has compromised the CA > can > easily circumvent the 'supposed' additional security provided by > returning > revoked for fraudulent certs. > - It adds confusion because users are asked to put different level of > trust > in two signatures, both generated by the same authority (end entity cert > and > responder cert) > - It introduces functional differences between OCSP and CRLs which are > traditionally considered interchangeable from functional point of view by > most deployments, thus making revocation checking non-deterministic > based on > source of revocation information. > - Its impact on other features of OCSP (revocation reason, revocation > time, > crl references, may be others) extends the scope of change to sections > beyond the one which re-defines the meaning of revoked. > - It can be perceived as an alternative to signature checking if OCSP > responder claims to check issuance. > > The biggest point is that it does not change the protocol specification > (bits on wire) at all. Implementations can still decide to return revoked > for fraudulently issued certificates without breaking the protocol. > So what's the need to introduce this concept in OCSP which can lead many > to > believe that OCSP can successfully deal with the case of CA compromise? > > -Piyush > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** From SChokhani@cygnacom.com Sat Nov 3 13:17:19 2012 Return-Path: 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 01FAA21F9C7C for ; Sat, 3 Nov 2012 13:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ek4Gl68iMAte for ; Sat, 3 Nov 2012 13:17:17 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42E21F9C69 for ; Sat, 3 Nov 2012 13:17:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,705,1344225600"; d="scan'208";a="2324907" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 03 Nov 2012 16:17:04 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 3 Nov 2012 16:17:04 -0400 From: Santosh Chokhani To: "Yngve N. Pettersen (Developer Opera Software ASA)" , "pkix@ietf.org" Date: Sat, 3 Nov 2012 16:17:02 -0400 Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Thread-Index: Ac25/Bllf5/ttFx4TBWkddhCzpnlNAAAsdhA Message-ID: References: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:17:19 -0000 I am ok with OCSP returning "revoked" for certificate that it knows has not= been issued. It can also inform the CA of the certificate if it has a cop= y so that the CA can determine if there was a fraudulent certificate or sim= ply a mischief. I am also ok with disparity in CRL and OCSP results. What I am not ok with is the CAB Forum and the post below's false sense of = security "but it provides an extra layer of security". The attacker can mi= nt a delegated OCSP Responder certificate and browsers will not know of it.= The post below and CAB Forum do not seem to recognize this and seem to gi= ve a false sense of security. This is only effective if the CA had some ge= nuine controls that would prevent from generating OCSP certificates while i= t has been compromised. This all depends on the CA design and the nature o= f compromise. Some designs and compromises I have seen, what you write bel= ow will be useless since the browser will be going to the rogue OCSP Respon= der created by the attacker. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Yng= ve N. Pettersen (Developer Opera Software ASA) Sent: Saturday, November 03, 2012 3:47 PM To: pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certif= icates in OCSP Hi, For reference, my point of view on this topic is that of a browser vendor t= hat have to provide security and trust information to the users of our brow= ser; that is, WebPKI. Our users expect their browser to indicate whether they are on a safe site = or not; while that may be a bit above what can be reasonably done, we do us= e fraud and malware information, as well as certificate revocation checking= (for site certificates this is primarily OCSP, not CRLs) to provide the be= st possible advice to our users. In relation to revocation information we = rely on the information provided, in particular by OCSP, to give an accurat= e and truthful indication of the status of the certificate at the time the = response was generated. Personally, I do not consider a "Good" response for= a non-issued certificate to be accurate, because the responder cannot trut= hfully say that the certificate is "Good", as the issuer does not know the = certificate was issued, or who uses the certificate. Based on what was revealed about last year's breach of DigiNotar, I propose= d to the CABForum, and the CABForum earlier this year accepted, that OCSP r= esponders MUST NOT reply "Good" for a certificate that it does not know has= been issued (Effective August 2013). My original proposal was that the res= ponse should be "Revoked", but this was rejected as to the language of RFC = 2560 seemed to forbid it. Using "Revoked" would have meant that clients wou= ld not have had to be updated to handle different responses (as is the case= with the final resolution), and would also immediately protect older clien= ts that have not been updated. Please note that my proposal only concerned = certificates that have never been issued, it does not define anything about= certificates that have been issued, but have expired. The relevant background for my proposal was, as should be known by members = of this WG, that the DigiNotar attacker was able to issue certificates that= was not tracked by the CA systems, and was thus unknown to the issuer. The= certificates were then used to perform MITM attacks on at least Google Mai= l users living in Iran. Because DigiNotar's OCSP system returned "Good" for= serial numbers it did not know, no client seeing these certificates would = be able to warn their users about the fake certificate. If the OCSP responder had been required to return something else for these = certificates, and which the clients would have treated as Fatal errors, the= n the attacker would not have been able to use the methods he was using. (F= or reference, in Opera 12.02 functionality was introduced that treat "Unkno= wn" and "unauthorized" as indications of non-issued certificates, and displ= ay a Fatal Error about the certificate being unknown to the issuer, and in = the worst case scenario is a fraudulent certificate.) He could have mitigated the effect by blocking access to the OCSP responder= , since most clients does not, currently, indicate such failures to the use= r. However, the browser I develop, Opera, do remove any indication that the= site is secure when revocation checks fails to complete successfully, and = we have had frequent experience with users reporting the incidents when a s= ite have lost its padlock, most recently involving a bug in our revocation = caching system, and host-files overrides that prevent access to the revocat= ion servers (possibly self-inflicted to bypass application licensing requir= ements). See also . Making it impossible for the attacker to give his certificates a "good" =20 OCSP response means that he will either have to leave the certificate in th= e database, or have to achieve far deeper and wider penetration of the CA t= han he would otherwise have needed, in order to compromise other parts of t= he CA system necessary to successfully obtain fraudulent certificates that = can be used. Based on my information, I would guess that the reason the Dig= iNotar attacker started destroying the logs was that DigiNotar was repeated= ly revoking his fraudulent certificates as they were discovered. =20 If so, that means that the revocation system worked, at least in part, and = the attacker was forced to find a way around it. As the attacker would need more control, or leave more obvious tracks, that= means that there is far better chance of an attack being discovered and st= opped. The no-"good"/"revoked" OCSP response suggestions are not a panacea for det= ecting fraudulent certificates or CA compromise, but it provides an extra l= ayer of security for users, and makes sure the attacker have to jump throug= h a lot more hoops, which make detection more likely (remember, DigiNotar d= id detect the attacker's activity). Combined with other counter-measures, s= uch as the browser removing secure indications if the revocation check fail= s (if not going for hard fail), and perhaps other protocols being developed= /suggested (pinning, certificate transparency, etc.) it may be possible to make a CA compromise much less profitable or li= kely to succeed. Personally, I would have preferred that the "does not necessarily mean the = certificate was ever issued" text in the definition of "Good" was removed. = =20 In my opinion it is dangerous, and should never have been in the text origi= nally, since it requires that CA issuance systems cannot be compromised. Ev= en if it ever made sense to have "Good" as a response for non-issued certif= icates, in my opinion any reasonable rationale for allowing it went out the= window in September 2011, as it was proven that CA issuance systems could = be compromised. Given that, as I understand it, one reason for allowing thi= s kind of response in such a case, was that OCSP responders could be based = entirely on CRL data, perhaps it is now an idea to retire that entire conce= pt, since it has, at least, proven to be based on one unwarranted assumptio= n: that CAs cannot be compromised. OCSP can, and should, provide more and better information about a certifica= te's status than CRLs, which after all only provide information about revok= ed certificates. As for CRLs, maybe they need to be replaced by a Certificate Status List, l= isting all issued and currently unexpired certificate, and whether they are= revoked or not, but that is a different discussion. For further reference, the final report in the DigiNotar incident can be fo= und here: =20 On Sat, 03 Nov 2012 17:09:00 +0100, Piyush Jain wrote: > Here are a few points about the current proposal > - Most folks agree that it adds very little or no incremental=20 > security, given current OCSP trust models. The benefits that are=20 > mentioned only apply if CA is compromised, but any smart attacker who=20 > has compromised the CA can easily circumvent the 'supposed' additional=20 > security provided by returning revoked for fraudulent certs. > - It adds confusion because users are asked to put different level of=20 > trust in two signatures, both generated by the same authority (end=20 > entity cert and responder cert) > - It introduces functional differences between OCSP and CRLs which are=20 > traditionally considered interchangeable from functional point of view=20 > by most deployments, thus making revocation checking non-deterministic=20 > based on source of revocation information. > - Its impact on other features of OCSP (revocation reason, revocation=20 > time, crl references, may be others) extends the scope of change to=20 > sections beyond the one which re-defines the meaning of revoked. > - It can be perceived as an alternative to signature checking if OCSP=20 > responder claims to check issuance. > > The biggest point is that it does not change the protocol=20 > specification (bits on wire) at all. Implementations can still decide=20 > to return revoked for fraudulently issued certificates without breaking t= he protocol. > So what's the need to introduce this concept in OCSP which can lead=20 > many to believe that OCSP can successfully deal with the case of CA=20 > compromise? > > -Piyush > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From yngve@opera.com Sat Nov 3 14:08:45 2012 Return-Path: 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 0BD1621F9BAF for ; Sat, 3 Nov 2012 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3t5RaWS1Ma7t for ; Sat, 3 Nov 2012 14:08:44 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0986421F9B59 for ; Sat, 3 Nov 2012 14:08:43 -0700 (PDT) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA3L8fsI002372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 3 Nov 2012 21:08:42 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "pkix@ietf.org" References: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> Date: Sat, 03 Nov 2012 22:08:41 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 21:08:45 -0000 On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani wrote: > The attacker can mint a delegated OCSP Responder certificate and > browsers will not know of it. AFAIK delegated OCSP certificates require special attributes, meaning that the attacker would need to be able to access a system that could issue such a certificate. If the CA system allows any extension to be set, or the CA system issuing OCSP responder certs can be compromised then, yes, an OCSP minting cert could be created and arbitrary responses created, as would be possible if the attacker managed to take control over the OCSP system itself. If an OCSP minting cert is created, then the only way to repair the problem is to revoke the issuing subCA. The same would be the case if the certificate issuance system allowed arbitrary byte sequences, e.g. an OCSP response, to be signed. That is, however, part of what I mention about the attacker requiring deeper penetration than just what is needed to issue certs, increasing the risk of detection. It is up to the CA to design their system so that such special certificates cannot be created without the CA intending to do so. In my opinion, an issuing system should not be able to set arbitrary extensions, they should be part of what the CA have hardcoded for that particular product. In part, these changes are made to eliminate a direct security problem (and I do say they are not a panacea) and, like many security measures, in part to increase the hassle and risks for the attacker by making an "easy" attack less feasible. In other ongoing work, other aspects of the attack is being countered, also seeking to block an attack, or increase the risks for the attacker. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** From liaquat.khan@ascertia.com Sat Nov 3 15:48:43 2012 Return-Path: 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 941F321F9C9A for ; Sat, 3 Nov 2012 15:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Lf1-1M0hQdMG for ; Sat, 3 Nov 2012 15:48:42 -0700 (PDT) Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7670721F9C3D for ; Sat, 3 Nov 2012 15:48:42 -0700 (PDT) Received: from [192.168.1.64] ([86.174.165.204]) by ascertia.com with MailEnable ESMTP; Sat, 3 Nov 2012 22:50:39 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Sat, 03 Nov 2012 22:47:48 +0000 From: Liaquat Khan To: "Yngve N. Pettersen (Developer Opera Software ASA)" , "pkix@ietf.org" Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:48:43 -0000 IMO an attacker that has the capability to bypass the normal CA security controls and access the CA's private signing key to issue fake certificates will be capable of also generating fake OCSP responder certificates. The fact that OCSP responder certificates contain special extension (I assume you were referring to EKU extension) is hardly going to raise the bar in terms of complexity for the attacker. Security should not hinge on the fact that the attacker cannot add an extension in the to-be-signed certificate, since this is just manipulating the input to the certificate signing process, but rather that they cannot use the CA's private signing key. So IMO if they can issue one fake certificate without detection, it's safer to assume they can issue multiple certificates and also of different types. In some cases you may be right, but to make a general statement that it's much harder to issue an OCSP certificate compared to an end-entity certificate is indeed a "false sense of security". On 03/11/2012 21:08, "Yngve N. Pettersen (Developer Opera Software ASA)" wrote: >On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani > wrote: > >> The attacker can mint a delegated OCSP Responder certificate and >> browsers will not know of it. > >AFAIK delegated OCSP certificates require special attributes, meaning >that >the attacker would need to be able to access a system that could issue >such a certificate. > >If the CA system allows any extension to be set, or the CA system issuing > >OCSP responder certs can be compromised then, yes, an OCSP minting cert >could be created and arbitrary responses created, as would be possible if > >the attacker managed to take control over the OCSP system itself. If an >OCSP minting cert is created, then the only way to repair the problem is >to revoke the issuing subCA. The same would be the case if the >certificate >issuance system allowed arbitrary byte sequences, e.g. an OCSP response, > >to be signed. > >That is, however, part of what I mention about the attacker requiring >deeper penetration than just what is needed to issue certs, increasing >the >risk of detection. It is up to the CA to design their system so that such > >special certificates cannot be created without the CA intending to do so. > >In my opinion, an issuing system should not be able to set arbitrary >extensions, they should be part of what the CA have hardcoded for that >particular product. > >In part, these changes are made to eliminate a direct security problem >(and I do say they are not a panacea) and, like many security measures, >in >part to increase the hassle and risks for the attacker by making an >"easy" >attack less feasible. In other ongoing work, other aspects of the attack >is being countered, also seeking to block an attack, or increase the >risks >for the attacker. > > > >-- >Sincerely, >Yngve N. Pettersen >******************************************************************** >Senior Developer Email: yngve@opera.com >Opera Software ASA http://www.opera.com/ >Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 >******************************************************************** >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > From SChokhani@cygnacom.com Sat Nov 3 16:25:51 2012 Return-Path: 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 CCE4D21F9C5F for ; Sat, 3 Nov 2012 16:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 BJgd0SS8U8pU for ; Sat, 3 Nov 2012 16:25:51 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id DF6D921F9C43 for ; Sat, 3 Nov 2012 16:25:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,707,1344225600"; d="scan'208";a="2325379" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 03 Nov 2012 19:25:50 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 3 Nov 2012 19:25:49 -0400 From: Santosh Chokhani To: Liaquat Khan , "Yngve N. Pettersen (Developer Opera Software ASA)" , "pkix@ietf.org" Date: Sat, 3 Nov 2012 19:25:48 -0400 Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Thread-Index: Ac26GomohOmUTl3HTGiA2okadp8+Eg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 23:25:51 -0000 I agree with Liaquat. I would emphasize that CA products have magical controls to protect once co= mpromised is not supported by the analysis of some of the commonly used CA = products. To think that OCSP certificate is somewhat special and hard to mint is an e= rror. Even a CA certificate can be easily minted from a CA once a CA is compromis= ed. The only saving grace here may be the parent CA had path length =3D 0 = in the compromised CA certificate protecting relying parties from accepting= a minted CA certificate. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Lia= quat Khan Sent: Saturday, November 03, 2012 6:48 PM To: Yngve N. Pettersen (Developer Opera Software ASA); pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certif= icates in OCSP IMO an attacker that has the capability to bypass the normal CA security co= ntrols and access the CA's private signing key to issue fake certificates w= ill be capable of also generating fake OCSP responder certificates. =20 The fact that OCSP responder certificates contain special extension (I assu= me you were referring to EKU extension) is hardly going to raise the bar in= terms of complexity for the attacker. Security should not hinge on the fa= ct that the attacker cannot add an extension in the to-be-signed certificat= e, since this is just manipulating the input to the certificate signing pro= cess, but rather that they cannot use the CA's private signing key. So IMO = if they can issue one fake certificate without detection, it's safer to ass= ume they can issue multiple certificates and also of different types.=20 In some cases you may be right, but to make a general statement that it's m= uch harder to issue an OCSP certificate compared to an end-entity certifica= te is indeed a "false sense of security". On 03/11/2012 21:08, "Yngve N. Pettersen (Developer Opera Software ASA)" wrote: >On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani=20 > wrote: > >> The attacker can mint a delegated OCSP Responder certificate and=20 >> browsers will not know of it. > >AFAIK delegated OCSP certificates require special attributes, meaning=20 >that the attacker would need to be able to access a system that could=20 >issue such a certificate. > >If the CA system allows any extension to be set, or the CA system=20 >issuing >=20 >OCSP responder certs can be compromised then, yes, an OCSP minting cert=20 >could be created and arbitrary responses created, as would be possible=20 >if >=20 >the attacker managed to take control over the OCSP system itself. If an=20 >OCSP minting cert is created, then the only way to repair the problem=20 >is to revoke the issuing subCA. The same would be the case if the=20 >certificate issuance system allowed arbitrary byte sequences, e.g. an=20 >OCSP response, >=20 >to be signed. > >That is, however, part of what I mention about the attacker requiring=20 >deeper penetration than just what is needed to issue certs, increasing=20 >the risk of detection. It is up to the CA to design their system so=20 >that such >=20 >special certificates cannot be created without the CA intending to do so. > >In my opinion, an issuing system should not be able to set arbitrary=20 >extensions, they should be part of what the CA have hardcoded for that=20 >particular product. > >In part, these changes are made to eliminate a direct security problem=20 >(and I do say they are not a panacea) and, like many security measures,=20 >in part to increase the hassle and risks for the attacker by making an=20 >"easy" >attack less feasible. In other ongoing work, other aspects of the=20 >attack is being countered, also seeking to block an attack, or increase=20 >the risks for the attacker. > > > >-- >Sincerely, >Yngve N. Pettersen >******************************************************************** >Senior Developer Email: yngve@opera.com >Opera Software ASA http://www.opera.com/ >Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 >******************************************************************** >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ryan-pkix@sleevi.com Sat Nov 3 17:32:53 2012 Return-Path: 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 2046921F9BEC for ; Sat, 3 Nov 2012 17:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, 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 5Mhw1izQqcKI for ; Sat, 3 Nov 2012 17:32:52 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 21C6C21F9BE1 for ; Sat, 3 Nov 2012 17:32:52 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id A52821E064; Sat, 3 Nov 2012 17:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=H0GeFiV75o1Pj+pmYZDs1AhU4yc=; b=rDbpJ+Nl4BbHfa1sX 0f5M4Q2a1SxD6DlnUl+aTmjSQ5oULFKhejnDh9rzgcgaR4A3cWWW0rLAKv2/uj0y WmkdGFRj87Hh88xJquM5Ez/ztDuS/y01f2vvCkP1miL0p/7TCdbq9MXz9SzXUzHj lYW/uT50LFsKv1+m1lq/+0c/uE= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 4A5191E05D; Sat, 3 Nov 2012 17:32:51 -0700 (PDT) Received: from 212.180.75.100 (proxying for 212.180.75.100) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sat, 3 Nov 2012 17:33:08 -0700 Message-ID: <0c1b7f83d913b35e47ce0a6b71d6b74c.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Sat, 3 Nov 2012 17:33:08 -0700 From: "Ryan Sleevi" To: "Santosh Chokhani" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-pkix@sleevi.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 00:32:53 -0000 To assume that an RA compromise + logging denial of service, for sake of example, is the same as allowing arbitrary signing access, is equally an error. I agree with Yngve - this is not trying, nor claiming to try, to resolve all the security issues involved with CA compromise. But it does raise th= e bar for security, by making it *possible* for CAs to make it more difficult for attackers to evade detection *in some situations*. And in practice, once something is possible for CAs to do something that improve= s overall security, it's near guaranteed that the browser and root store operators will *require* the CAs to do so posthaste. The point here is that CA systems frequently involve multiple layers of communication between different systems, with different access controls and audit schemes. It's hardly an informed comment to suggest that the ability to compromise a single issuance workflow is equivalent to arbitrary access to the key material or that it is equal to a signing oracle, no matter how compelling it is to think about it in the hypothetical. Does the proposal defend against signing oracles or arbitrary key materia= l access? No, as Yngve has repeated and which should hopefully be obvious. But I support Yngve's assertion that this does provide some degree of benefit for at least some situations, and even if that benefit is merely that an attacker must "work harder," that's a meaningful benefit to both the public CAs participating in the so-called "web PKI" and to the browsers and relying party software that are collectively used by hundred= s of millions of users on the Internet today. On Sat, November 3, 2012 4:25 pm, Santosh Chokhani wrote: > I agree with Liaquat. > > I would emphasize that CA products have magical controls to protect on= ce > compromised is not supported by the analysis of some of the commonly u= sed > CA products. > > To think that OCSP certificate is somewhat special and hard to mint is= an > error. > > Even a CA certificate can be easily minted from a CA once a CA is > compromised. The only saving grace here may be the parent CA had path > length =3D 0 in the compromised CA certificate protecting relying part= ies > from accepting a minted CA certificate. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f > Liaquat Khan > Sent: Saturday, November 03, 2012 6:48 PM > To: Yngve N. Pettersen (Developer Opera Software ASA); pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP > > IMO an attacker that has the capability to bypass the normal CA securi= ty > controls and access the CA's private signing key to issue fake > certificates will be capable of also generating fake OCSP responder > certificates. > > The fact that OCSP responder certificates contain special extension (I > assume you were referring to EKU extension) is hardly going to raise t= he > bar in terms of complexity for the attacker. Security should not hing= e on > the fact that the attacker cannot add an extension in the to-be-signed > certificate, since this is just manipulating the input to the certific= ate > signing process, but rather that they cannot use the CA's private sign= ing > key. So IMO if they can issue one fake certificate without detection, = it's > safer to assume they can issue multiple certificates and also of diffe= rent > types. > > In some cases you may be right, but to make a general statement that i= t's > much harder to issue an OCSP certificate compared to an end-entity > certificate is indeed a "false sense of security". > > > On 03/11/2012 21:08, "Yngve N. Pettersen (Developer Opera Software ASA= )" > wrote: > > >On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani > > wrote: > > > >> The attacker can mint a delegated OCSP Responder certificate and > >> browsers will not know of it. > > > >AFAIK delegated OCSP certificates require special attributes, meaning > >that the attacker would need to be able to access a system that could > >issue such a certificate. > > > >If the CA system allows any extension to be set, or the CA system > >issuing > > > >OCSP responder certs can be compromised then, yes, an OCSP minting cer= t > >could be created and arbitrary responses created, as would be possible > >if > > > >the attacker managed to take control over the OCSP system itself. If a= n > >OCSP minting cert is created, then the only way to repair the problem > >is to revoke the issuing subCA. The same would be the case if the > >certificate issuance system allowed arbitrary byte sequences, e.g. an > >OCSP response, > > > >to be signed. > > > >That is, however, part of what I mention about the attacker requiring > >deeper penetration than just what is needed to issue certs, increasing > >the risk of detection. It is up to the CA to design their system so > >that such > > > >special certificates cannot be created without the CA intending to do = so. > > > >In my opinion, an issuing system should not be able to set arbitrary > >extensions, they should be part of what the CA have hardcoded for that > >particular product. > > > >In part, these changes are made to eliminate a direct security problem > >(and I do say they are not a panacea) and, like many security measures= , > >in part to increase the hassle and risks for the attacker by making an > >"easy" > >attack less feasible. In other ongoing work, other aspects of the > >attack is being countered, also seeking to block an attack, or increas= e > >the risks for the attacker. > > > > > > > >-- > >Sincerely, > >Yngve N. Pettersen > >******************************************************************** > >Senior Developer Email: yngve@opera.com > >Opera Software ASA http://www.opera.com/ > >Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > >******************************************************************** > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From SChokhani@cygnacom.com Sat Nov 3 17:43:52 2012 Return-Path: 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 C592D21F9B09 for ; Sat, 3 Nov 2012 17:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, 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 77O8L1mKdcw7 for ; Sat, 3 Nov 2012 17:43:51 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id B121D21F8DAA for ; Sat, 3 Nov 2012 17:43:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,707,1344225600"; d="scan'208";a="6720287" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 03 Nov 2012 20:43:43 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 3 Nov 2012 20:43:42 -0400 From: Santosh Chokhani To: "ryan-pkix@sleevi.com" Date: Sat, 3 Nov 2012 20:43:40 -0400 Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Thread-Index: Ac26I/vsWd/MBPN6T0iPLvcd40WfRgAAJ4EQ Message-ID: References: <0c1b7f83d913b35e47ce0a6b71d6b74c.squirrel@webmail.dreamhost.com> In-Reply-To: <0c1b7f83d913b35e47ce0a6b71d6b74c.squirrel@webmail.dreamhost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 00:43:53 -0000 Ryan, There is a hell of difference between claims "does provide some degree of b= enefit" and "provides an extra layer of security". Decide which one you wa= nt to claim. Also, DigiNotar attack was a CA compromise and not an RA. You are doing disservice to the readers by confusing the issues. I have no idea if you yourself are confused or doing this intentionally and= if so for what purpose. -----Original Message----- From: Ryan Sleevi [mailto:ryan-pkix@sleevi.com]=20 Sent: Saturday, November 03, 2012 8:33 PM To: Santosh Chokhani Cc: Liaquat Khan; Yngve N. Pettersen (Developer Opera Software ASA); pkix@i= etf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certif= icates in OCSP To assume that an RA compromise + logging denial of service, for sake of ex= ample, is the same as allowing arbitrary signing access, is equally an erro= r. I agree with Yngve - this is not trying, nor claiming to try, to resolve al= l the security issues involved with CA compromise. But it does raise the ba= r for security, by making it *possible* for CAs to make it more difficult f= or attackers to evade detection *in some situations*. And in practice, once= something is possible for CAs to do something that improves overall securi= ty, it's near guaranteed that the browser and root store operators will *re= quire* the CAs to do so posthaste. The point here is that CA systems frequently involve multiple layers of com= munication between different systems, with different access controls and au= dit schemes. It's hardly an informed comment to suggest that the ability to= compromise a single issuance workflow is equivalent to arbitrary access to= the key material or that it is equal to a signing oracle, no matter how co= mpelling it is to think about it in the hypothetical. Does the proposal defend against signing oracles or arbitrary key material = access? No, as Yngve has repeated and which should hopefully be obvious. But I support Yngve's assertion that this does provide some degree of benef= it for at least some situations, and even if that benefit is merely that an= attacker must "work harder," that's a meaningful benefit to both the publi= c CAs participating in the so-called "web PKI" and to the browsers and rely= ing party software that are collectively used by hundreds of millions of us= ers on the Internet today. On Sat, November 3, 2012 4:25 pm, Santosh Chokhani wrote: > I agree with Liaquat. > > I would emphasize that CA products have magical controls to protect=20 > once compromised is not supported by the analysis of some of the=20 > commonly used CA products. > > To think that OCSP certificate is somewhat special and hard to mint=20 > is an error. > > Even a CA certificate can be easily minted from a CA once a CA is =20 > compromised. The only saving grace here may be the parent CA had path =20 > length =3D 0 in the compromised CA certificate protecting relying=20 > parties from accepting a minted CA certificate. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Liaquat Khan > Sent: Saturday, November 03, 2012 6:48 PM > To: Yngve N. Pettersen (Developer Opera Software ASA); pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued =20 > certificates in OCSP > > IMO an attacker that has the capability to bypass the normal CA=20 > security controls and access the CA's private signing key to issue=20 > fake certificates will be capable of also generating fake OCSP=20 > responder certificates. > > The fact that OCSP responder certificates contain special extension=20 > (I assume you were referring to EKU extension) is hardly going to=20 > raise the bar in terms of complexity for the attacker. Security=20 > should not hinge on the fact that the attacker cannot add an=20 > extension in the to-be-signed certificate, since this is just=20 > manipulating the input to the certificate signing process, but rather=20 > that they cannot use the CA's private signing key. So IMO if they can=20 > issue one fake certificate without detection, it's safer to assume=20 > they can issue multiple certificates and also of different types. > > In some cases you may be right, but to make a general statement that=20 > it's much harder to issue an OCSP certificate compared to an=20 > end-entity certificate is indeed a "false sense of security". > > > On 03/11/2012 21:08, "Yngve N. Pettersen (Developer Opera Software ASA)" > wrote: > > >On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani=20 > > wrote: > > > >> The attacker can mint a delegated OCSP Responder certificate and=20 > >> browsers will not know of it. > > > >AFAIK delegated OCSP certificates require special attributes, meaning=20 > >that the attacker would need to be able to access a system that could=20 > >issue such a certificate. > > > >If the CA system allows any extension to be set, or the CA system=20 > >issuing > > > >OCSP responder certs can be compromised then, yes, an OCSP minting=20 > >cert could be created and arbitrary responses created, as would be=20 > >possible if > > > >the attacker managed to take control over the OCSP system itself. If=20 > >an OCSP minting cert is created, then the only way to repair the=20 > >problem is to revoke the issuing subCA. The same would be the case if=20 > >the certificate issuance system allowed arbitrary byte sequences,=20 > >e.g. an OCSP response, > > > >to be signed. > > > >That is, however, part of what I mention about the attacker requiring=20 > >deeper penetration than just what is needed to issue certs,=20 > >increasing the risk of detection. It is up to the CA to design their=20 > >system so that such > > > >special certificates cannot be created without the CA intending to do so= . > > > >In my opinion, an issuing system should not be able to set arbitrary=20 > >extensions, they should be part of what the CA have hardcoded for=20 > >that particular product. > > > >In part, these changes are made to eliminate a direct security=20 > >problem (and I do say they are not a panacea) and, like many security=20 > >measures, in part to increase the hassle and risks for the attacker=20 > >by making an "easy" > >attack less feasible. In other ongoing work, other aspects of the=20 > >attack is being countered, also seeking to block an attack, or=20 > >increase the risks for the attacker. > > > > > > > >-- > >Sincerely, > >Yngve N. Pettersen > >******************************************************************** > >Senior Developer Email: yngve@opera.com > >Opera Software ASA http://www.opera.com/ > >Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > >******************************************************************** > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From piyush@ditenity.com Sat Nov 3 18:16:31 2012 Return-Path: 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 4559221F9C7D for ; Sat, 3 Nov 2012 18:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2WCbnJ-8b53Y for ; Sat, 3 Nov 2012 18:16:30 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0021F9C43 for ; Sat, 3 Nov 2012 18:16:30 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so3961574iak.31 for ; Sat, 03 Nov 2012 18:16:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=FVSABC0nZbbVILr3YrlwesrdCGWt8BFBPs7enqtiWRI=; b=OYeCdGoCrT2mUf7jrjo6013okAqyQA5gs/qWzOnGrqxvOLLcfQ90nSclHqqdp/VW98 6Zqxux1BkX7ToTSQCzDqU2y8jAhdpGGtBIGz5IEIXWZ1RIh1H2gc/dd/gJ6dQaxQ0VGF rPD8I+PaGz/Ku5VFg2Ni6e+x59aYkYufKupvu7YudLEH2KYRNmbJ6m5YcuUkSRWmt2JZ Zp541fn8J4oBn+rhD+YjllTbccc8D+YEsxKwIhu/7ZOZJdhIcha3zRkq/TZieJ+DqLye TRfBHDo1POmRLd3NOlLyaPi/syhiDI3N66FQ3G3mhi7F4agRh5XGIradok5DbLE2llWZ 8Seg== Received: by 10.50.178.67 with SMTP id cw3mr5841391igc.53.1351991789709; Sat, 03 Nov 2012 18:16:29 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id eo7sm2762598igc.12.2012.11.03.18.16.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 18:16:28 -0700 (PDT) From: "Piyush Jain" To: "'Santosh Chokhani'" , "'Liaquat Khan'" , "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , References: In-Reply-To: Date: Sat, 3 Nov 2012 18:16:24 -0700 Message-ID: <057001cdba2a$032a29a0$097e7ce0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQI1CbQb9BjuIYZDPIIwgqNLh73KuJcKNDOA Content-Language: en-us X-Gm-Message-State: ALoCoQkdWnPVnIIkDV+XxIGztQ7sXHZCDr176D2l0BDKVkGlBuZ2vegHaQUDgMzYjpdovhTpXH8a Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 01:16:31 -0000 Thanks Santosh and Liaquat. That has been my biggest objection to adding the new text to OCSP - it creates a false sense of security. Ygnve I appreciate you analysis of the DigiiNotor incidence. However, I still believe that the changes proposed here or in the CAB forum won't have helped and attacker would have been able to circumvent any additional measures that were put in place based on these proposals. Please note that based on current text in OCSP, the responder can return unknown or INTERNAL ERROR for such certificates. In my opinion, changing the standards to accommodate clients who are not updated is never good. CAs can always decide to return revoked for fraudulently issued certificates for some period of time, until all clients are updated to Opera like functionality to reject access if certificate status is unknown. Another alternative could be to create a profile of OCSP for webPKI that adds recommendations which make sense for webPKI. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Santosh Chokhani > Sent: Saturday, November 03, 2012 4:26 PM > To: Liaquat Khan; Yngve N. Pettersen (Developer Opera Software ASA); > pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP > > I agree with Liaquat. > > I would emphasize that CA products have magical controls to protect once > compromised is not supported by the analysis of some of the commonly > used CA products. > > To think that OCSP certificate is somewhat special and hard to mint is an > error. > > Even a CA certificate can be easily minted from a CA once a CA is > compromised. The only saving grace here may be the parent CA had path > length = 0 in the compromised CA certificate protecting relying parties from > accepting a minted CA certificate. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Liaquat Khan > Sent: Saturday, November 03, 2012 6:48 PM > To: Yngve N. Pettersen (Developer Opera Software ASA); pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP > > IMO an attacker that has the capability to bypass the normal CA security > controls and access the CA's private signing key to issue fake certificates will > be capable of also generating fake OCSP responder certificates. > > The fact that OCSP responder certificates contain special extension (I assume > you were referring to EKU extension) is hardly going to raise the bar in terms > of complexity for the attacker. Security should not hinge on the fact that the > attacker cannot add an extension in the to-be-signed certificate, since this is > just manipulating the input to the certificate signing process, but rather that > they cannot use the CA's private signing key. So IMO if they can issue one > fake certificate without detection, it's safer to assume they can issue multiple > certificates and also of different types. > > In some cases you may be right, but to make a general statement that it's > much harder to issue an OCSP certificate compared to an end-entity > certificate is indeed a "false sense of security". > > > On 03/11/2012 21:08, "Yngve N. Pettersen (Developer Opera Software ASA)" > wrote: > > >On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani > > wrote: > > > >> The attacker can mint a delegated OCSP Responder certificate and > >> browsers will not know of it. > > > >AFAIK delegated OCSP certificates require special attributes, meaning > >that the attacker would need to be able to access a system that could > >issue such a certificate. > > > >If the CA system allows any extension to be set, or the CA system > >issuing > > > >OCSP responder certs can be compromised then, yes, an OCSP minting cert > >could be created and arbitrary responses created, as would be possible > >if > > > >the attacker managed to take control over the OCSP system itself. If an > >OCSP minting cert is created, then the only way to repair the problem > >is to revoke the issuing subCA. The same would be the case if the > >certificate issuance system allowed arbitrary byte sequences, e.g. an > >OCSP response, > > > >to be signed. > > > >That is, however, part of what I mention about the attacker requiring > >deeper penetration than just what is needed to issue certs, increasing > >the risk of detection. It is up to the CA to design their system so > >that such > > > >special certificates cannot be created without the CA intending to do so. > > > >In my opinion, an issuing system should not be able to set arbitrary > >extensions, they should be part of what the CA have hardcoded for that > >particular product. > > > >In part, these changes are made to eliminate a direct security problem > >(and I do say they are not a panacea) and, like many security measures, > >in part to increase the hassle and risks for the attacker by making an > >"easy" > >attack less feasible. In other ongoing work, other aspects of the > >attack is being countered, also seeking to block an attack, or increase > >the risks for the attacker. > > > > > > > >-- > >Sincerely, > >Yngve N. Pettersen > >********************************************************* > *********** > >Senior Developer Email: yngve@opera.com > >Opera Software ASA http://www.opera.com/ > >Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > >********************************************************* > *********** > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Sun Nov 4 09:37:24 2012 Return-Path: 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 89F3621F877F for ; Sun, 4 Nov 2012 09:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7TFlLdWXv7PT for ; Sun, 4 Nov 2012 09:37:23 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D80C721F8774 for ; Sun, 4 Nov 2012 09:37:22 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so4272276iak.31 for ; Sun, 04 Nov 2012 09:37:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=F0SA3cMY9503/1CF+hxN2lenKjmD0x8tysxhgAy0Oug=; b=WUYlrYqrPpYErZEUzccgHiU/XphTNg9va6+zjN+X2iPAcsgokGpi9vxIXKvTs0XnTy c3Y4RaDfqH5ISxmRxSvZqxTXWCVXOuaolJx3HB39M36Z9XUURT55EEa1avndv44bpsVc wwSAmChdubuOMW+4pRX25Mc0knvTvG6qs2+23NkS0IUHgzXEZ7+pbV/C5VsE+LDICsr5 K8UkDJE38Ej2pp13xSQ4BGriYxiDraYNb7dStnxWTCsULkTCWOua1QVQz7EisBV1jx2W LFuXGy2mnVbokPpo77mQt5Rmr28+l2irVhkbZ96gYFmmgmgybcn8tFfJ3twkXOH/vd61 rNxA== Received: by 10.50.10.133 with SMTP id i5mr7380913igb.10.1352050642212; Sun, 04 Nov 2012 09:37:22 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id rd10sm3892611igb.1.2012.11.04.09.37.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Nov 2012 09:37:21 -0800 (PST) From: "Piyush Jain" To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , References: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> In-Reply-To: Date: Sun, 4 Nov 2012 09:37:16 -0800 Message-ID: <05c901cdbab3$09d37de0$1d7a79a0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGBbMMdyvGO6HsvGEs0EQCE0qcvGgI9WBS4mGCG9tA= Content-Language: en-us X-Gm-Message-State: ALoCoQkbTBi7JTzFSVZ18bDIIC0VECgliFGNR2JFBJNZEpCZjSzAbcPx9lC7eMPJnO4XXP0Y2pSD Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:37:24 -0000 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Yngve N. Pettersen (Developer Opera Software ASA) > Sent: Saturday, November 03, 2012 12:47 PM > To: pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP > > Hi, > > For reference, my point of view on this topic is that of a browser vendor that > have to provide security and trust information to the users of our browser; > that is, WebPKI. > > Our users expect their browser to indicate whether they are on a safe site or > not; while that may be a bit above what can be reasonably done, we do use > fraud and malware information, as well as certificate revocation checking (for > site certificates this is primarily OCSP, not CRLs) to provide the best possible > advice to our users. In relation to revocation information we rely on the > information provided, in particular by OCSP, to give an accurate and truthful > indication of the status of the certificate at the time the response was > generated. Personally, I do not consider a "Good" response for a non-issued > certificate to be accurate, because the responder cannot truthfully say that > the certificate is "Good", as the issuer does not know the certificate was > issued, or who uses the certificate. [Piyush] OCSP is clear about what 'good' means. It explicitly states that 'good' does not imply that certificate is issued or valid. Issuance is checked by signature on the certificate, validity for a purpose is checked by building path to trusted root and performing additional checks on the path. People should understand that OCSP status 'good' does not imply that certificate is valid for their purpose. On a side note, I have seen products that just perform an OCSP check on the certificate and accept the certificate if responder returns 'good'. > > Based on what was revealed about last year's breach of DigiNotar, I proposed > to the CABForum, and the CABForum earlier this year accepted, that OCSP > responders MUST NOT reply "Good" for a certificate that it does not know > has been issued (Effective August 2013). My original proposal was that the > response should be "Revoked", but this was rejected as to the language of > RFC 2560 seemed to forbid it. Using "Revoked" would have meant that > clients would not have had to be updated to handle different responses (as > is the case with the final resolution), and would also immediately protect > older clients that have not been updated. > Please note that my proposal only > concerned certificates that have never been issued, it does not define > anything about certificates that have been issued, but have expired. > > The relevant background for my proposal was, as should be known by > members of this WG, that the DigiNotar attacker was able to issue > certificates that was not tracked by the CA systems, and was thus unknown > to the issuer. The certificates were then used to perform MITM attacks on at > least Google Mail users living in Iran. Because DigiNotar's OCSP system > returned "Good" for serial numbers it did not know, no client seeing these > certificates would be able to warn their users about the fake certificate. > > If the OCSP responder had been required to return something else for these > certificates, and which the clients would have treated as Fatal errors, then > the attacker would not have been able to use the methods he was using. > (For reference, in Opera 12.02 functionality was introduced that treat > "Unknown" and "unauthorized" as indications of non-issued certificates, and > display a Fatal Error about the certificate being unknown to the issuer, and in > the worst case scenario is a fraudulent > certificate.) [Piyush] The right approach IMO. Handle 'unknown' correctly and the world is a happy place. > > He could have mitigated the effect by blocking access to the OCSP > responder, since most clients does not, currently, indicate such failures to > the user. However, the browser I develop, Opera, do remove any indication > that the site is secure when revocation checks fails to complete successfully, > and we have had frequent experience with users reporting the incidents > when a site have lost its padlock, most recently involving a bug in our > revocation caching system, and host-files overrides that prevent access to > the revocation servers (possibly self-inflicted to bypass application licensing > requirements). See also > debunked-by-opera-users>. > > Making it impossible for the attacker to give his certificates a "good" > OCSP response means that he will either have to leave the certificate in the > database, or have to achieve far deeper and wider penetration of the CA > than he would otherwise have needed, in order to compromise other parts > of the CA system necessary to successfully obtain fraudulent certificates that > can be used. Based on my information, I would guess that the reason the > DigiNotar attacker started destroying the logs was that DigiNotar was > repeatedly revoking his fraudulent certificates as they were discovered. > If so, that means that the revocation system worked, at least in part, and the > attacker was forced to find a way around it. > > As the attacker would need more control, or leave more obvious tracks, that > means that there is far better chance of an attack being discovered and > stopped. > > The no-"good"/"revoked" OCSP response suggestions are not a panacea for > detecting fraudulent certificates or CA compromise, but it provides an extra > layer of security for users, and makes sure the attacker have to jump through > a lot more hoops, which make detection more likely (remember, DigiNotar > did detect the attacker's activity). Combined with other counter-measures, > such as the browser removing secure indications if the revocation check fails > (if not going for hard fail), and perhaps other protocols being > developed/suggested (pinning, certificate transparency, > etc.) it may be possible to make a CA compromise much less profitable or > likely to succeed. > [Piyush] I can understand a no-"good" response for such scenario, but it does not have to be 'revoked'. Based on what you are describing a signed 'unknown' or an error response from the responder would be equally effective. I know of at least one CA (among the biggest ones) which returns TRY later for certificates that are not present in its database. > Personally, I would have preferred that the "does not necessarily mean the > certificate was ever issued" text in the definition of "Good" was removed. [Piyush] [Piyush] That could make sense only if you assume that OCSP responders are tied to the CA. Unfortunately, some of the biggest deployments of OCSP depend on CRL to provide revocation status. And in public key certificates issuance is determined by checking the signature on the certificate. > In my opinion it is dangerous, and should never have been in the text > originally, since it requires that CA issuance systems cannot be compromised. [Piyush] That's one way to look it. The other way is to assume that CA would detect the compromise and revoke the certificate that are fraudulently issued or mark itself as compromised if it cannot figure out what certificates are fraudulently issued. Assuming that relying parties will only use OCSP to check revocation status is dangerous. Given that at least one browser vendor has stated that it won't use OCSP for revocation checks proves that this assumption is invalid. > Even if it ever made sense to have "Good" as a response for non-issued > certificates, in my opinion any reasonable rationale for allowing it went out > the window in September 2011, as it was proven that CA issuance systems > could be compromised. Given that, as I understand it, one reason for > allowing this kind of response in such a case, was that OCSP responders could > be based entirely on CRL data, perhaps it is now an idea to retire that entire > concept, since it has, at least, proven to be based on one unwarranted > assumption: that CAs cannot be compromised. [Piyush] I don't think that CAs cannot be compromised was ever an assumption. However, assumption that CA's can continue operations normally after being compromised is dangerous. > > OCSP can, and should, provide more and better information about a > certificate's status than CRLs, which after all only provide information about > revoked certificates. > [Piyush] Based on current OCSP trust models the above statement is incorrect. If your goal is to provide validity of certificate for a purpose, instead of revocation status, deploy SCVP. > As for CRLs, maybe they need to be replaced by a Certificate Status List, > listing all issued and currently unexpired certificate, and whether they are > revoked or not, but that is a different discussion. > [Piyush] The system that you are proposing does not need public key certificates. What you are proposing is that CA stops makes an assertion about the user and his associated public key through PKC and instead use an online request/response mechanism or signed white list to make such an assertion. There is nothing wrong with the approach or proposal but Imo it's outside the charter of PKIX. > > For further reference, the final report in the DigiNotar incident can be found > here: > publicaties/rapporten/2012/08/13/black-tulip-update.html> > > > On Sat, 03 Nov 2012 17:09:00 +0100, Piyush Jain > wrote: > > > Here are a few points about the current proposal > > - Most folks agree that it adds very little or no incremental > > security, given current OCSP trust models. The benefits that are > > mentioned only apply if CA is compromised, but any smart attacker who > > has compromised the CA can easily circumvent the 'supposed' additional > > security provided by returning revoked for fraudulent certs. > > - It adds confusion because users are asked to put different level of > > trust in two signatures, both generated by the same authority (end > > entity cert and responder cert) > > - It introduces functional differences between OCSP and CRLs which are > > traditionally considered interchangeable from functional point of view > > by most deployments, thus making revocation checking non-deterministic > > based on source of revocation information. > > - Its impact on other features of OCSP (revocation reason, revocation > > time, crl references, may be others) extends the scope of change to > > sections beyond the one which re-defines the meaning of revoked. > > - It can be perceived as an alternative to signature checking if OCSP > > responder claims to check issuance. > > > > The biggest point is that it does not change the protocol > > specification (bits on wire) at all. Implementations can still decide > > to return revoked for fraudulently issued certificates without breaking the > protocol. > > So what's the need to introduce this concept in OCSP which can lead > > many to believe that OCSP can successfully deal with the case of CA > > compromise? > > > > -Piyush > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > > -- > Sincerely, > Yngve N. Pettersen > ********************************************************** > ********** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > ********************************************************** > ********** > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From yngve@opera.com Sun Nov 4 11:07:10 2012 Return-Path: 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 CAA0521F8626 for ; Sun, 4 Nov 2012 11:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 awGdfJdR0jpQ for ; Sun, 4 Nov 2012 11:07:09 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E18721F8615 for ; Sun, 4 Nov 2012 11:07:08 -0800 (PST) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA4J75sN022544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Nov 2012 19:07:06 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: pkix@ietf.org, "Piyush Jain" References: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> <05c901cdbab3$09d37de0$1d7a79a0$@ditenity.com> Date: Sun, 04 Nov 2012 20:07:05 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <05c901cdbab3$09d37de0$1d7a79a0$@ditenity.com> User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:07:10 -0000 On Sun, 04 Nov 2012 18:37:16 +0100, Piyush Jain wrote: > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Yngve N. Pettersen (Developer Opera Software ASA) >> Sent: Saturday, November 03, 2012 12:47 PM >> To: pkix@ietf.org >> Subject: Re: [pkix] What's the need to introduce fraudulently issued >> certificates in OCSP >> >> Hi, >> >> For reference, my point of view on this topic is that of a browser >> vendor > that >> have to provide security and trust information to the users of our > browser; >> that is, WebPKI. >> >> Our users expect their browser to indicate whether they are on a safe >> site > or >> not; while that may be a bit above what can be reasonably done, we do >> use >> fraud and malware information, as well as certificate revocation >> checking > (for >> site certificates this is primarily OCSP, not CRLs) to provide the best > possible >> advice to our users. In relation to revocation information we rely on >> the >> information provided, in particular by OCSP, to give an accurate and > truthful >> indication of the status of the certificate at the time the response was >> generated. Personally, I do not consider a "Good" response for a > non-issued >> certificate to be accurate, because the responder cannot truthfully say > that >> the certificate is "Good", as the issuer does not know the certificate >> was >> issued, or who uses the certificate. > [Piyush] OCSP is clear about what 'good' means. It explicitly states that > 'good' does not imply that certificate is issued or valid. Issuance is > checked by signature on the certificate, validity for a purpose is > checked > by building path to trusted root and performing additional checks on the > path. > People should understand that OCSP status 'good' does not imply that > certificate is valid for their purpose. On a side note, I have seen > products > that just perform an OCSP check on the certificate and accept the > certificate if responder returns 'good'. Those who are experts of PKIX systems may know, and believe that. That kind of interpretation of "Good" may even make sense if the RP/client can only check a limited number of pre-configured serial numbers for a specific CA. For an RP (browser) that can access random sites chosen from millions of sites that kind of interpretation does not make sense. Unfortunately, many, or most, normal users tend to have a "either it is good, or it isn't", black and white interpretation of any signal to them, they do not want to know about gray areas. Opera had, for many years, a graduated padlock system going from 0 to 3, zero being unencrypted, 1 for user has been warned about certificates a very weak encryption, 2 for downgraded due to sightly weak encryption including revocation failure, and 3 for passed all certificate, encryption, revocation checks, including "good" for OCSP. We no longer have that, we now have an indication for what was level 3 (Same meaning), Extended Validation certificates (level 5), and one for everything else, including unencrypted content. The reason for that change was that the graduated display was too confusing for the users. Opera is also the only browser ever to have such a graduated system. If an OCSP "Good" response is a PKIX version of Schroedinger's Cat, the certificate either exists and is valid (in revocation terms), or it does not exists and is not valid, and there is no way to tell the difference unless we open the box (phones the CA and demand access to their database), then OCSP cannot be used as part of a security system that reports to the user. We will have to discard the protocol, and use something else, or "fix" the protocol for the purposes where users are involved, which is what the CABForum decided to do in BR 1.1, by making sure the responder can only reply "Good" when the certificate is known to be issued and not revoked. >> Personally, I would have preferred that the "does not necessarily mean >> the >> certificate was ever issued" text in the definition of "Good" was >> removed. > > [Piyush] That could make sense only if you assume that OCSP responders > are > tied to the CA. Unfortunately, some of the biggest deployments of OCSP > depend on CRL to provide revocation status. And in public key > certificates > issuance is determined by checking the signature on the certificate. As I said further down, I think that kind of deployment can no longer be defended (if it ever could), since it makes what I think are unwarranted assumptions. >> In my opinion it is dangerous, and should never have been in the text >> originally, since it requires that CA issuance systems cannot be > compromised. > [Piyush] That's one way to look it. The other way is to assume that CA > would > detect the compromise and revoke the certificate that are fraudulently > issued or mark itself as compromised if it cannot figure out what > certificates are fraudulently issued. You are assuming that a CA could in all cases detect incorrectly issued certificates that have been hidden. DigiNotar proved that that is not always the case, and while the CABforum have been working on procedures to avoid a repetition, I would not want to assume that something similar (untracked certificates) could not happen again. That means that the "Good" response cannot be used when the certificate serial number is unknown. > Assuming that relying parties will > only use OCSP to check revocation status is dangerous. > Given that at least one browser vendor has stated that it won't use OCSP > for > revocation checks proves that this assumption is invalid. I assume that you are referring to Google and their CRLSets. As a matter of fact, I do not approve of Google's experiment (and that is what they are calling it themselves: an experiment). And one reason I do not approve is that they would not be protected against the kind of attack that the non-issued response is aimed at. Their reason for doing this is, as I understand it, in part due to what they consider unreliability of revocation checking (not revocation itself), particularly network stability, and speed considerations due to the delays loading OCSP and/or CRLs introduce (browsers are in a race to load and display the page as quickly as possible, opening multiple connections to load revocation information can delay that by hundreds of milliseconds, if not seconds). According to my information, Google Chrome will use OCSP when received via OCSP Stapling in the TLS protocol. >> Even if it ever made sense to have "Good" as a response for non-issued >> certificates, in my opinion any reasonable rationale for allowing it >> went > out >> the window in September 2011, as it was proven that CA issuance systems >> could be compromised. Given that, as I understand it, one reason for >> allowing this kind of response in such a case, was that OCSP responders > could >> be based entirely on CRL data, perhaps it is now an idea to retire that > entire >> concept, since it has, at least, proven to be based on one unwarranted >> assumption: that CAs cannot be compromised. > > [Piyush] I don't think that CAs cannot be compromised was ever an > assumption. However, assumption that CA's can continue operations > normally > after being compromised is dangerous. It may not have been a stated assumption, but whether or not it was, the effect is the same; it was a builtin assumption. One of the points that have cause a lot of my concern about DigiNotar's handling *is* that they continued operations as normal, particularly since another CA was reporting itself under attack at the same time the attack on them started. They did not inform any of the browsers or the CABforum about what was going on, only after the Google cert was discovered and reported did they confirm that they had been compromised. However, there will usually be a delay between attack and detection, and assuming the attacker manages to hide a certificate in that period, the only defense is that the OCSP responder does not reply "Good" for that serial number. >> OCSP can, and should, provide more and better information about a >> certificate's status than CRLs, which after all only provide information > about >> revoked certificates. >> > [Piyush] Based on current OCSP trust models the above statement is > incorrect. The name is "Status Protocol", not "Revocation Status Protocol". I think it can be argued either way, but names matter, and my opinion is that OCSP should only reply Good for certificates that the issuer knows have been issued and have not been revoked. If "not revoked" is the desired indication, then the name should say that, not "Good". > If your goal is to provide validity of certificate for a purpose, > instead of revocation status, deploy SCVP. SCVP is not AFAIK deployed by any CA or browser, at present, and there was no interest expressed from PKIX WG participants, or anyone else, to add it as a method for the TLS Multi Stapling extension document I am editing, and I therefore removed the text in the most recent draft. It is, also, AFAIK not implemented in OpenSSL, which indicates that the protocol is minimum 12-24 months from deployment, assuming interest is expressed for deploying it. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** From ben@digicert.com Sun Nov 4 13:09:21 2012 Return-Path: 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 2FD0221F8839 for ; Sun, 4 Nov 2012 13:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, 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 MqUcN3xAR4Bd for ; Sun, 4 Nov 2012 13:09:20 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id D6D2C21F8836 for ; Sun, 4 Nov 2012 13:09:19 -0800 (PST) Received: from BWILSONL1 (dhcp-43f0.meeting.ietf.org [130.129.67.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 0E2DD1AE010; Sun, 4 Nov 2012 14:09:18 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1352063359; bh=hH0E9GQjqgQSILN2rHilP1UwC0NAFSCTXgzZqq1TmKc=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=x8cW/oBd5yX4ha31So+YQlK7v4ExsBAq06ikHB6hq6oxk1QyGScNuyC1shk+OGhd5 COiTqWAlh+U+7hTyuKjxq95qq+kBa9/UDZGu5xfjvv+MwG0ovIltnaQqDfl88QXPZg gYgx1nXJUZCInPK4jAEbpFV0oHteBgGFgReKe2Hc= From: "Ben Wilson" To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , , "'Piyush Jain'" References: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> <05c901cdbab3$09d37de0$1d7a79a0$@ditenity.com> In-Reply-To: Date: Sun, 4 Nov 2012 14:09:14 -0700 Organization: DigiCert Message-ID: <009c01cdbad0$a520b340$ef6219c0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBbMMdyvGO6HsvGEs0EQCE0qcvGgI9WBS4AtU4hjoB2r5Q95g7WzlA Content-Language: en-us Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 21:09:21 -0000 Yngve, Putting aside the technical interpretation of "good" defense for the moment, there still may be legal liability for responding "good" to a non-issued certificate. This brings to mind the paper written by Tom Smedinghoff in 1998 on CA Liability. http://64.78.35.30/article/ca-liability-analysis.pdf. The provider of certificate status information might be held liable for saying that a certificate is "good" when it isn't - either under a theory of negligent misrepresentation, or making a representation about the status of a certificate with reckless disregard for the truth, or some other legal liability theory (you know lawyers, they can create new claims where none existed before). Ben -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Yngve N. Pettersen (Developer Opera Software ASA) Sent: Sunday, November 04, 2012 12:07 PM To: pkix@ietf.org; Piyush Jain Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP On Sun, 04 Nov 2012 18:37:16 +0100, Piyush Jain wrote: > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Yngve N. Pettersen (Developer Opera Software ASA) >> Sent: Saturday, November 03, 2012 12:47 PM >> To: pkix@ietf.org >> Subject: Re: [pkix] What's the need to introduce fraudulently issued >> certificates in OCSP >> >> Hi, >> >> For reference, my point of view on this topic is that of a browser >> vendor > that >> have to provide security and trust information to the users of our > browser; >> that is, WebPKI. >> >> Our users expect their browser to indicate whether they are on a safe >> site > or >> not; while that may be a bit above what can be reasonably done, we do >> use >> fraud and malware information, as well as certificate revocation >> checking > (for >> site certificates this is primarily OCSP, not CRLs) to provide the best > possible >> advice to our users. In relation to revocation information we rely on >> the >> information provided, in particular by OCSP, to give an accurate and > truthful >> indication of the status of the certificate at the time the response was >> generated. Personally, I do not consider a "Good" response for a > non-issued >> certificate to be accurate, because the responder cannot truthfully say > that >> the certificate is "Good", as the issuer does not know the certificate >> was >> issued, or who uses the certificate. > [Piyush] OCSP is clear about what 'good' means. It explicitly states that > 'good' does not imply that certificate is issued or valid. Issuance is > checked by signature on the certificate, validity for a purpose is > checked > by building path to trusted root and performing additional checks on the > path. > People should understand that OCSP status 'good' does not imply that > certificate is valid for their purpose. On a side note, I have seen > products > that just perform an OCSP check on the certificate and accept the > certificate if responder returns 'good'. Those who are experts of PKIX systems may know, and believe that. That kind of interpretation of "Good" may even make sense if the RP/client can only check a limited number of pre-configured serial numbers for a specific CA. For an RP (browser) that can access random sites chosen from millions of sites that kind of interpretation does not make sense. Unfortunately, many, or most, normal users tend to have a "either it is good, or it isn't", black and white interpretation of any signal to them, they do not want to know about gray areas. Opera had, for many years, a graduated padlock system going from 0 to 3, zero being unencrypted, 1 for user has been warned about certificates a very weak encryption, 2 for downgraded due to sightly weak encryption including revocation failure, and 3 for passed all certificate, encryption, revocation checks, including "good" for OCSP. We no longer have that, we now have an indication for what was level 3 (Same meaning), Extended Validation certificates (level 5), and one for everything else, including unencrypted content. The reason for that change was that the graduated display was too confusing for the users. Opera is also the only browser ever to have such a graduated system. If an OCSP "Good" response is a PKIX version of Schroedinger's Cat, the certificate either exists and is valid (in revocation terms), or it does not exists and is not valid, and there is no way to tell the difference unless we open the box (phones the CA and demand access to their database), then OCSP cannot be used as part of a security system that reports to the user. We will have to discard the protocol, and use something else, or "fix" the protocol for the purposes where users are involved, which is what the CABForum decided to do in BR 1.1, by making sure the responder can only reply "Good" when the certificate is known to be issued and not revoked. >> Personally, I would have preferred that the "does not necessarily mean >> the >> certificate was ever issued" text in the definition of "Good" was >> removed. > > [Piyush] That could make sense only if you assume that OCSP responders > are > tied to the CA. Unfortunately, some of the biggest deployments of OCSP > depend on CRL to provide revocation status. And in public key > certificates > issuance is determined by checking the signature on the certificate. As I said further down, I think that kind of deployment can no longer be defended (if it ever could), since it makes what I think are unwarranted assumptions. >> In my opinion it is dangerous, and should never have been in the text >> originally, since it requires that CA issuance systems cannot be > compromised. > [Piyush] That's one way to look it. The other way is to assume that CA > would > detect the compromise and revoke the certificate that are fraudulently > issued or mark itself as compromised if it cannot figure out what > certificates are fraudulently issued. You are assuming that a CA could in all cases detect incorrectly issued certificates that have been hidden. DigiNotar proved that that is not always the case, and while the CABforum have been working on procedures to avoid a repetition, I would not want to assume that something similar (untracked certificates) could not happen again. That means that the "Good" response cannot be used when the certificate serial number is unknown. > Assuming that relying parties will > only use OCSP to check revocation status is dangerous. > Given that at least one browser vendor has stated that it won't use OCSP > for > revocation checks proves that this assumption is invalid. I assume that you are referring to Google and their CRLSets. As a matter of fact, I do not approve of Google's experiment (and that is what they are calling it themselves: an experiment). And one reason I do not approve is that they would not be protected against the kind of attack that the non-issued response is aimed at. Their reason for doing this is, as I understand it, in part due to what they consider unreliability of revocation checking (not revocation itself), particularly network stability, and speed considerations due to the delays loading OCSP and/or CRLs introduce (browsers are in a race to load and display the page as quickly as possible, opening multiple connections to load revocation information can delay that by hundreds of milliseconds, if not seconds). According to my information, Google Chrome will use OCSP when received via OCSP Stapling in the TLS protocol. >> Even if it ever made sense to have "Good" as a response for non-issued >> certificates, in my opinion any reasonable rationale for allowing it >> went > out >> the window in September 2011, as it was proven that CA issuance systems >> could be compromised. Given that, as I understand it, one reason for >> allowing this kind of response in such a case, was that OCSP responders > could >> be based entirely on CRL data, perhaps it is now an idea to retire that > entire >> concept, since it has, at least, proven to be based on one unwarranted >> assumption: that CAs cannot be compromised. > > [Piyush] I don't think that CAs cannot be compromised was ever an > assumption. However, assumption that CA's can continue operations > normally > after being compromised is dangerous. It may not have been a stated assumption, but whether or not it was, the effect is the same; it was a builtin assumption. One of the points that have cause a lot of my concern about DigiNotar's handling *is* that they continued operations as normal, particularly since another CA was reporting itself under attack at the same time the attack on them started. They did not inform any of the browsers or the CABforum about what was going on, only after the Google cert was discovered and reported did they confirm that they had been compromised. However, there will usually be a delay between attack and detection, and assuming the attacker manages to hide a certificate in that period, the only defense is that the OCSP responder does not reply "Good" for that serial number. >> OCSP can, and should, provide more and better information about a >> certificate's status than CRLs, which after all only provide information > about >> revoked certificates. >> > [Piyush] Based on current OCSP trust models the above statement is > incorrect. The name is "Status Protocol", not "Revocation Status Protocol". I think it can be argued either way, but names matter, and my opinion is that OCSP should only reply Good for certificates that the issuer knows have been issued and have not been revoked. If "not revoked" is the desired indication, then the name should say that, not "Good". > If your goal is to provide validity of certificate for a purpose, > instead of revocation status, deploy SCVP. SCVP is not AFAIK deployed by any CA or browser, at present, and there was no interest expressed from PKIX WG participants, or anyone else, to add it as a method for the TLS Multi Stapling extension document I am editing, and I therefore removed the text in the most recent draft. It is, also, AFAIK not implemented in OpenSSL, which indicates that the protocol is minimum 12-24 months from deployment, assuming interest is expressed for deploying it. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Nov 5 06:16:06 2012 Return-Path: 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 AAB5B21F871D for ; Mon, 5 Nov 2012 06:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.063 X-Spam-Level: X-Spam-Status: No, score=-10.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 KQ+Pwa0g3lzo for ; Mon, 5 Nov 2012 06:16:05 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 87E9121F871F for ; Mon, 5 Nov 2012 06:16:05 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qA5EG0WB024932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Nov 2012 15:16:01 +0100 (MET) In-Reply-To: To: Santosh Chokhani Date: Mon, 5 Nov 2012 15:15:59 +0100 (CET) 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: <20121105141559.1CF971A331@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:16:06 -0000 Santosh Chokhani wrote: > > I would emphasize that CA products have magical controls to protect > once compromised is not supported by the analysis of some of the > commonly used CA products. > > To think that OCSP certificate is somewhat special and hard to mint > is an error. This is why an updated OCSP spec should not allow the EE signing key to issue OCSP signer certs. Existing OCSP and existing CRL are broken by _design_, not by implementation, so without updating the spec to provide additional protection and without updating the installed base to use it, there is not going to be any improvement. > > Even a CA certificate can be easily minted from a CA once a CA is > compromised. The only saving grace here may be the parent CA had > path length = 0 in the compromised CA certificate protecting relying > parties from accepting a minted CA certificate. I doubt that path length = 0 helps. Self-issued certs are specified to not count for the path len, so the CA cert that the attacker has to create is one where subject=issuer, i.e a self-issued CA cert. -Martin From SChokhani@cygnacom.com Mon Nov 5 08:00:24 2012 Return-Path: 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 F3D8521F8A8F for ; Mon, 5 Nov 2012 08:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 ZICJ--0Bc7QY for ; Mon, 5 Nov 2012 08:00:23 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 803BE21F8938 for ; Mon, 5 Nov 2012 08:00:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,715,1344225600"; d="scan'208";a="2336206" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 05 Nov 2012 11:00:08 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 5 Nov 2012 11:00:07 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Mon, 5 Nov 2012 11:00:05 -0500 Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Thread-Index: Ac27YByDCYEBdIVYREewijrGNUaOmgADlVPw Message-ID: References: <20121105141559.1CF971A331@ld9781.wdf.sap.corp> In-Reply-To: <20121105141559.1CF971A331@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:00:24 -0000 On the OCSP Certificate Signer, we are where we are, Unless you provide a = total solution, the security and software complexity comparison cannot be m= ade. Your point about self-issued is well taken. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, November 05, 2012 9:16 AM To: Santosh Chokhani Cc: Liaquat Khan; Yngve N. Pettersen (Developer Opera Software ASA); pkix@i= etf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certif= icates in OCSP Santosh Chokhani wrote: >=20 > I would emphasize that CA products have magical controls to protect=20 > once compromised is not supported by the analysis of some of the=20 > commonly used CA products. >=20 > To think that OCSP certificate is somewhat special and hard to mint is=20 > an error. This is why an updated OCSP spec should not allow the EE signing key to iss= ue OCSP signer certs. Existing OCSP and existing CRL are broken by _design_, not by implementatio= n, so without updating the spec to provide additional protection and withou= t updating the installed base to use it, there is not going to be any impro= vement. >=20 > Even a CA certificate can be easily minted from a CA once a CA is=20 > compromised. The only saving grace here may be the parent CA had path=20 > length =3D 0 in the compromised CA certificate protecting relying=20 > parties from accepting a minted CA certificate. I doubt that path length =3D 0 helps. Self-issued certs are specified to not count for the path len, so the CA ce= rt that the attacker has to create is one where subject=3Dissuer, i.e a sel= f-issued CA cert. -Martin From piyush@ditenity.com Mon Nov 5 08:17:32 2012 Return-Path: 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 8779321F87E7 for ; Mon, 5 Nov 2012 08:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8MPNFp3L3TQL for ; Mon, 5 Nov 2012 08:17:32 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7DB521F87E0 for ; Mon, 5 Nov 2012 08:17:31 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so9294877iec.31 for ; Mon, 05 Nov 2012 08:17:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=mY2/DhhV4UUJyiheAdQim2thgHK29Vr1OYyIpj9F/bw=; b=otPnqDAYlTfMfNM7KY+8CtSyoxMpbHuMnI4JCTe9uibuI9GErcAFIG2/NxtGJUtFj0 P+bPR4Pb2mbh2B/V27rVOUvDw32FZ/DB0XNV4U2/AwbO6bkf4ZcyJOI4KoLjrPZlplfj G6cFMugwheUHxAIr/RXi/4xMtF/nUnCc5ZJNw83G9wdiwoIfHf+hZGsCv98l+H0Fx54b a/t6BT/pb0GEK/SMvfhsj6zZ2wXVTwaIXHNiq2ddbjwBQkkRToAysnJlC5yxH7+teJwG FTwBxLHkNWpCQiluSBbOTB4DJoVnKd1TT9RdZXjoSsO/9gtjLw3sAsFyWZvg+tuboiab En7w== Received: by 10.42.50.6 with SMTP id y6mr1687459icf.35.1352132251405; Mon, 05 Nov 2012 08:17:31 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id us4sm5983462igc.9.2012.11.05.08.17.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 08:17:30 -0800 (PST) From: "Piyush Jain" To: , "'Santosh Chokhani'" References: <20121105141559.1CF971A331@ld9781.wdf.sap.corp> In-Reply-To: <20121105141559.1CF971A331@ld9781.wdf.sap.corp> Date: Mon, 5 Nov 2012 08:17:26 -0800 Message-ID: <062501cdbb71$0d93eff0$28bbcfd0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGy0Jl8fH2dAlMhvv5cbSwZ/TsoXpgRNOZw Content-Language: en-us X-Gm-Message-State: ALoCoQkogKzR9VFij/bFO4j+2J2/Lcia4dFpN2NEljSI2+sfNBtoXTxI5Bi7GO2ghkhUW1IPsAhf Cc: pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:17:32 -0000 > This is why an updated OCSP spec should not allow the EE signing key to issue > OCSP signer certs. > > Existing OCSP and existing CRL are broken by _design_, not by > implementation, so without updating the spec to provide additional > protection and without updating the installed base to use it, there is not > going to be any improvement. > [Piyush] To claim that OCSP and CRLs are broken is stretch. Both do exactly what they are supposed to do - tell you if a certificate is revoked by the issuing authority. If you really believe that OCSP and CRL are broken and should go through wholesale changes, isn't it better to address the issue by creating a new protocol that addresses these issue, instead of affecting all the deployments that still wish to use OCSP and CRLs in the traditional way? I understand that you would like these specifications to do more to avoid revoking the CA even when it is compromised and make OCSP and CRLs more authoritative that the CA. As I said before, nothing wrong with the idea - many systems utilize user databases to authenticate a user. PKC is used as alternative to such systems because it addresses lot of operational problems associated with such systems. White lists are difficult to transport, especially in cases where the user population is huge. A single system which checks for validity becomes performance bottleneck and to replicate the information across geographies to address scalability imposes security and logistical problems. Is the cost of additional protection that you allude to, justified? Most people would say yes to more security, but will question the benefit if you lay out the cost associated with providing that security. Unfortunately, the proponents of the changes to OCSP have cited reasons ranging from - "it makes it more difficult for attacker" to it adds "additional layer of security" without providing any concrete analysis of scenarios that substantiates these claims. > > > > > Even a CA certificate can be easily minted from a CA once a CA is > > compromised. The only saving grace here may be the parent CA had path > > length = 0 in the compromised CA certificate protecting relying > > parties from accepting a minted CA certificate. > > I doubt that path length = 0 helps. > > Self-issued certs are specified to not count for the path len, so the CA cert > that the attacker has to create is one where subject=issuer, i.e a self-issued > CA cert. [Piyush] I agree. And it is all the more reason to be skeptical about the benefits of addressing fraudulently issued certificates through OCSP. From piyush@ditenity.com Mon Nov 5 08:57:41 2012 Return-Path: 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 1FA9A21F866F for ; Mon, 5 Nov 2012 08:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 p6GbOZV8OwWc for ; Mon, 5 Nov 2012 08:57:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8906121F8545 for ; Mon, 5 Nov 2012 08:57:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so9378060iec.31 for ; Mon, 05 Nov 2012 08:57:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=zhnVA/Y+BmkK7QetcwyDXJO4myzNGZ63ardiqq074rY=; b=IgzrEbRMzErZFJcwAvmq8zHe2FNyGPd+ph1UIOE/J9c4TGcoa9o9VYOpVOBnSrzYkJ CC5aPKPuKYYVJqH6BI3wFNV9pNrTF7kPGRq6hQzRSSgiC0cf2kaNml9/9irXAXb/Sdq6 vUcSX2FIxOUEgznycyrXEA3w/0jjM5AZ1B0jpRPXJE97QThFxPzcQQbKKYSHxZzVVz5U teMXzeCyk3bc+hq25U/TofUfKGDT83ZFXjcu5j7ESlZkRPSaSnfW8jKkwLocVjcbmrOb rnB6Ij5ib8UrUrCAmY+CtE1XeRSv/78dbfjBO/GGi3QB0Kro50nB/goHwRo/MsqpOPMV icCw== Received: by 10.50.242.10 with SMTP id wm10mr8679691igc.38.1352134659118; Mon, 05 Nov 2012 08:57:39 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id v12sm6562721igv.3.2012.11.05.08.57.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 08:57:38 -0800 (PST) From: "Piyush Jain" To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , References: <053e01cdb9dd$8a7a1520$9f6e3f60$@ditenity.com> <05c901cdbab3$09d37de0$1d7a79a0$@ditenity.com> In-Reply-To: Date: Mon, 5 Nov 2012 08:57:34 -0800 Message-ID: <064801cdbb76$a89bf2e0$f9d3d8a0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGBbMMdyvGO6HsvGEs0EQCE0qcvGgI9WBS4AtU4hjoB2r5Q95g8nlOA Content-Language: en-us X-Gm-Message-State: ALoCoQm2Cn9upVjOFVU0TwQnyRrMRrhqyZ6y4IIyt6qqy/pTP01+kpy1p/RmXfzcDNR/BIfTlRr9 Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:57:41 -0000 Yngve, The question is if the responder can authoritatively provide the information you are seeking or not. I appreciate your point about returning good for fraudulently-issued certificates. My question is, can the responder figure out if the certificate is fraudulently issued if the CA is compromised. In most cases this untrue, unless you standup a responder independent of the CA. I'm sorry to say, but you proposal to CAB forum was just a feel good measure without providing any additional security. It is actually a disservice because now people believe that their deployments are more secure without that being the case. Here are a few scenarios, some of which have been discussed in this forum before: - Attacker issued a new OCSP certificate and issued site certificate with AIA that point to a bogus responder with a OCSP certificate issued by the CA. To counter this you need to have OCSP certificates that are not issued by the CA. -Attacker issued site certificate with same serial number as an existing valid certificate. To counter this you would require that the OCSP request should contain a unique representation of the certificate as opposed to just the serial number. Given that CAs issue millions of certificates other than site certificates, think of the impact it would've on the size of OCSP request and response and on the latency of an OCSP response. - CRLs are still used to validate all kind of certificates. There are big enterprises that have directly trusted OCSP responders feeding of CRLs. These responders provide revocation information for all kind of certificates, even public website certificates (somewhat similar to google model). The only benefit of your proposal, as I see it could be to detect a CA compromise scenario that too not in a fool proof way. To continue operating the CA by claiming that OCSP has effectively dealt with CA compromise would be incorrect and deceptive. Your point about 'good' status is a valid one. The name 'good' is a misnomer and almost everyone one this WG believes that it should be 'not revoked'. Simple reason is that, given the guidance on certificate validation and OCSP trust model , OCSP responder does not have and cannot have enough information to respond with an authoritative 'good'. Folks realized the benefit of a service that can return authoritative 'good' and that is why we have SCVP. BTW, All these proposed changes in OCSP (different trust model, including certificate identifier in request and returning authoritative goods) turn it into a protocol that could very well be a light weight profile of SCVP. -Piyush - > -----Original Message----- > From: Yngve N. Pettersen (Developer Opera Software ASA) > [mailto:yngve@opera.com] > Sent: Sunday, November 04, 2012 11:07 AM > To: pkix@ietf.org; Piyush Jain > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP > > On Sun, 04 Nov 2012 18:37:16 +0100, Piyush Jain > wrote: > > > > > > >> -----Original Message----- > >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf > Of > >> Yngve N. Pettersen (Developer Opera Software ASA) > >> Sent: Saturday, November 03, 2012 12:47 PM > >> To: pkix@ietf.org > >> Subject: Re: [pkix] What's the need to introduce fraudulently issued > >> certificates in OCSP > >> > >> Hi, > >> > >> For reference, my point of view on this topic is that of a browser > >> vendor > > that > >> have to provide security and trust information to the users of our > > browser; > >> that is, WebPKI. > >> > >> Our users expect their browser to indicate whether they are on a safe > >> site > > or > >> not; while that may be a bit above what can be reasonably done, we do > >> use > >> fraud and malware information, as well as certificate revocation > >> checking > > (for > >> site certificates this is primarily OCSP, not CRLs) to provide the best > > possible > >> advice to our users. In relation to revocation information we rely on > >> the > >> information provided, in particular by OCSP, to give an accurate and > > truthful > >> indication of the status of the certificate at the time the response was > >> generated. Personally, I do not consider a "Good" response for a > > non-issued > >> certificate to be accurate, because the responder cannot truthfully say > > that > >> the certificate is "Good", as the issuer does not know the certificate > >> was > >> issued, or who uses the certificate. > > [Piyush] OCSP is clear about what 'good' means. It explicitly states that > > 'good' does not imply that certificate is issued or valid. Issuance is > > checked by signature on the certificate, validity for a purpose is > > checked > > by building path to trusted root and performing additional checks on the > > path. > > People should understand that OCSP status 'good' does not imply that > > certificate is valid for their purpose. On a side note, I have seen > > products > > that just perform an OCSP check on the certificate and accept the > > certificate if responder returns 'good'. > > Those who are experts of PKIX systems may know, and believe that. > > That kind of interpretation of "Good" may even make sense if the RP/client > can only check a limited number of pre-configured serial numbers for a > specific CA. For an RP (browser) that can access random sites chosen from > millions of sites that kind of interpretation does not make sense. > > Unfortunately, many, or most, normal users tend to have a "either it is > good, or it isn't", black and white interpretation of any signal to them, > they do not want to know about gray areas. > > Opera had, for many years, a graduated padlock system going from 0 to 3, > zero being unencrypted, 1 for user has been warned about certificates a > very weak encryption, 2 for downgraded due to sightly weak encryption > including revocation failure, and 3 for passed all certificate, > encryption, revocation checks, including "good" for OCSP. > > We no longer have that, we now have an indication for what was level 3 > (Same meaning), Extended Validation certificates (level 5), and one for > everything else, including unencrypted content. > > The reason for that change was that the graduated display was too > confusing for the users. Opera is also the only browser ever to have such > a graduated system. > > If an OCSP "Good" response is a PKIX version of Schroedinger's Cat, the > certificate either exists and is valid (in revocation terms), or it does > not exists and is not valid, and there is no way to tell the difference > unless we open the box (phones the CA and demand access to their > database), then OCSP cannot be used as part of a security system that > reports to the user. We will have to discard the protocol, and use > something else, or "fix" the protocol for the purposes where users are > involved, which is what the CABForum decided to do in BR 1.1, by making > sure the responder can only reply "Good" when the certificate is known to > be issued and not revoked. > > >> Personally, I would have preferred that the "does not necessarily mean > >> the > >> certificate was ever issued" text in the definition of "Good" was > >> removed. > > > > [Piyush] That could make sense only if you assume that OCSP responders > > are > > tied to the CA. Unfortunately, some of the biggest deployments of OCSP > > depend on CRL to provide revocation status. And in public key > > certificates > > issuance is determined by checking the signature on the certificate. > > As I said further down, I think that kind of deployment can no longer be > defended (if it ever could), since it makes what I think are unwarranted > assumptions. > > >> In my opinion it is dangerous, and should never have been in the text > >> originally, since it requires that CA issuance systems cannot be > > compromised. > > [Piyush] That's one way to look it. The other way is to assume that CA > > would > > detect the compromise and revoke the certificate that are fraudulently > > issued or mark itself as compromised if it cannot figure out what > > certificates are fraudulently issued. > > You are assuming that a CA could in all cases detect incorrectly issued > certificates that have been hidden. DigiNotar proved that that is not > always the case, and while the CABforum have been working on procedures > to > avoid a repetition, I would not want to assume that something similar > (untracked certificates) could not happen again. That means that the > "Good" response cannot be used when the certificate serial number is > unknown. > > > Assuming that relying parties will > > only use OCSP to check revocation status is dangerous. > > Given that at least one browser vendor has stated that it won't use OCSP > > for > > revocation checks proves that this assumption is invalid. > > I assume that you are referring to Google and their CRLSets. > > As a matter of fact, I do not approve of Google's experiment (and that is > what they are calling it themselves: an experiment). And one reason I do > not approve is that they would not be protected against the kind of attack > that the non-issued response is aimed at. > > Their reason for doing this is, as I understand it, in part due to what > they consider unreliability of revocation checking (not revocation > itself), particularly network stability, and speed considerations due to > the delays loading OCSP and/or CRLs introduce (browsers are in a race to > load and display the page as quickly as possible, opening multiple > connections to load revocation information can delay that by hundreds of > milliseconds, if not seconds). > > According to my information, Google Chrome will use OCSP when received > via > OCSP Stapling in the TLS protocol. > > >> Even if it ever made sense to have "Good" as a response for non-issued > >> certificates, in my opinion any reasonable rationale for allowing it > >> went > > out > >> the window in September 2011, as it was proven that CA issuance systems > >> could be compromised. Given that, as I understand it, one reason for > >> allowing this kind of response in such a case, was that OCSP responders > > could > >> be based entirely on CRL data, perhaps it is now an idea to retire that > > entire > >> concept, since it has, at least, proven to be based on one unwarranted > >> assumption: that CAs cannot be compromised. > > > > [Piyush] I don't think that CAs cannot be compromised was ever an > > assumption. However, assumption that CA's can continue operations > > normally > > after being compromised is dangerous. > > It may not have been a stated assumption, but whether or not it was, the > effect is the same; it was a builtin assumption. > > One of the points that have cause a lot of my concern about DigiNotar's > handling *is* that they continued operations as normal, particularly since > another CA was reporting itself under attack at the same time the attack > on them started. They did not inform any of the browsers or the CABforum > about what was going on, only after the Google cert was discovered and > reported did they confirm that they had been compromised. > > However, there will usually be a delay between attack and detection, and > assuming the attacker manages to hide a certificate in that period, the > only defense is that the OCSP responder does not reply "Good" for that > serial number. > > > >> OCSP can, and should, provide more and better information about a > >> certificate's status than CRLs, which after all only provide information > > about > >> revoked certificates. > >> > > [Piyush] Based on current OCSP trust models the above statement is > > incorrect. > > The name is "Status Protocol", not "Revocation Status Protocol". I think > it can be argued either way, but names matter, and my opinion is that OCSP > should only reply Good for certificates that the issuer knows have been > issued and have not been revoked. If "not revoked" is the desired > indication, then the name should say that, not "Good". > > > If your goal is to provide validity of certificate for a purpose, > > instead of revocation status, deploy SCVP. > > SCVP is not AFAIK deployed by any CA or browser, at present, and there was > no interest expressed from PKIX WG participants, or anyone else, to add it > as a method for the TLS Multi Stapling extension document I am editing, > and I therefore removed the text in the most recent draft. It is, also, > AFAIK not implemented in OpenSSL, which indicates that the protocol is > minimum 12-24 months from deployment, assuming interest is expressed for > deploying it. > > > > -- > Sincerely, > Yngve N. Pettersen > ********************************************************** > ********** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > ********************************************************** > ********** From tgindin@us.ibm.com Mon Nov 5 18:08:57 2012 Return-Path: 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 3E1E511E80A5 for ; Mon, 5 Nov 2012 18:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 SLx07Q6wdzFz for ; Mon, 5 Nov 2012 18:08:56 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id DAFB711E80CC for ; Mon, 5 Nov 2012 18:08:55 -0800 (PST) Received: from /spool/local by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 Nov 2012 21:08:55 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 5 Nov 2012 21:08:53 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 42CBD6E804F for ; Mon, 5 Nov 2012 21:08:52 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qA628qs6300760 for ; Mon, 5 Nov 2012 21:08:52 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qA628pRv016081 for ; Mon, 5 Nov 2012 21:08:52 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qA628p9w016077; Mon, 5 Nov 2012 21:08:51 -0500 In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> To: Phillip Hallam-Baker MIME-Version: 1.0 X-KeepSent: 7D09602D:7E786A44-85257AAE:0007E349; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Mon, 5 Nov 2012 21:08:49 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 11/05/2012 21:08:51, Serialize complete at 11/05/2012 21:08:51 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12110602-5930-0000-0000-00000DDA1E37 Cc: "pkix@ietf.org" , Stefan Santesson Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 02:08:57 -0000 Phill: Why do you think that a non-critical CRL entry extension will result in clients accepting the referenced cert? RFC 5280 5.3 says that RP's can ignore unrecognized extensions to an entry, not that they can ignore entries containing unrecognized extensions. A CRL entry without an extension (indeed, almost any CRL entry except one containing reasonCode removeFromCRL) implies that the certificate should be rejected for current use. So marking reason non-critical shouldn't hurt anything. Tom Gindin From: Phillip Hallam-Baker To: Stefan Santesson , Cc: "pkix@ietf.org" Date: 11/01/2012 09:46 AM Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Sent by: pkix-bounces@ietf.org 1 and 3b Reading through the thread it appears that the poll has actually turned into 3a Do nothing 3b Add in unknown. But going back to the original straw poll, I think that it is pretty clear that any viable implementation of 'unknown' would have to be implemented as a CRL or OCSP entry that is marked 'Revoked' with a NON CRITICAL extension giving the revocation reason as 'It never existed' Marking the reason as non-critical looks like it is only going to result in the undesired behavior as clients will reject the CRL entry completely and accept the cert as good. Which is stupid behavior but so was not having the status 'never existed'. I would prefer the form of the OCSP 'does not exist' entry to specify a range of cert serial numbers that do not exist. This permits pre-signing of the responses and avoids a potential DoS issue. On Tue, Oct 30, 2012 at 5:52 AM, Stefan Santesson wrote: Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued by the CA. This request may be done deliberately, by mistake or as a consequence of a compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate with a particular serialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number does NOT represent a valid certificate issued by the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, such as: - It breaks nothing. A legitimate request for an issued certificate will get a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer than responding "good". - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will profile the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if this states that "good" MUST be returned unless the certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument that it is wrong and confusing to allow anything but "good" as a response to a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder). Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been "revoked" but where that OCSP responder for any other reason knows the certificate to be "bad". 2. Require that the OCSP responder MUST respond "good" in this situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long debates. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Tue Nov 6 08:20:03 2012 Return-Path: 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 0B45021F89E9 for ; Tue, 6 Nov 2012 08:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3TLS2babPsDP for ; Tue, 6 Nov 2012 08:20:02 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5092A21F89E5 for ; Tue, 6 Nov 2012 08:20:02 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7410D9A4005 for ; Tue, 6 Nov 2012 11:20:06 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id eOsAPlFKw2NL for ; Tue, 6 Nov 2012 11:19:57 -0500 (EST) Received: from dhcp-5421.meeting.ietf.org (dhcp-5421.meeting.ietf.org [130.129.84.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C0D339A4002 for ; Tue, 6 Nov 2012 11:20:03 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-39-249443742 Date: Tue, 6 Nov 2012 11:19:58 -0500 References: To: IETF PKIX Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [pkix] Fwd: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:20:03 -0000 --Apple-Mail-39-249443742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii People on this list might want to contribute to the discussion on the = TLS list. I just want to make sure you know it is happening .... Russ Begin forwarded message: > From: Darshak Thakore > Date: November 6, 2012 11:09:02 AM EST > To: "tls@ietf.org" > Subject: [TLS] New Authz extension to use DTCP certificates in TLS SD = handshake message >=20 > Folks, > I am sending this email to obtain feedback and guidance on the = following I-D, which proposes a new Authorization Data Format to the TLS = SupplementalData Handshake extension to use DTCP certificates as = authorization data. If this WG is not the forum to seek feedback on this = proposal, please redirect me accordingly. >=20 > http://tools.ietf.org/html/draft-dthakore-authz-01 >=20 > =46rom the Abstract: > "This document specifies the use of DTCP certificate as an > authorization extension in the Transport Layer Security Handshake > Protocol, according to guidelines in RFC 5878. Extensions carried = in > the client and server Hello messages confirm that both parties > support the desired authorization data types. Then if supported by > both the client and server, DTCP certificates are exchanged in the > supplemental data handshake TLS handshake message as specified in > RFC4680." > Thanks in advance=20 > Regards, > Darshak Thakore > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-39-249443742 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Darshak Thakore = <d.thakore@cablelabs.com>
Date: November 6, 2012 11:09:02 AM EST
Subject: [TLS] New Authz = extension to use DTCP certificates in TLS SD handshake = message

http://tools.i= etf.org/html/draft-dthakore-authz-01

=46rom = the Abstract:
  "This document specifies the use of DTCP certificate =
as an
   authorization extension in the Transport Layer Security Handshake
   Protocol, according to guidelines in RFC 5878.  Extensions carried in
   the client and server Hello messages confirm that both parties
   support the desired authorization data types.  Then if supported by
   both the client and server, DTCP certificates are exchanged in the
   supplemental data handshake TLS handshake message as specified in
   RFC4680."
TLS@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/tls

= --Apple-Mail-39-249443742-- From william.polk@nist.gov Tue Nov 6 13:25:21 2012 Return-Path: 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 1954621F848B for ; Tue, 6 Nov 2012 13:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bjE7rESzXsgg for ; Tue, 6 Nov 2012 13:25:19 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 897F221F8489 for ; Tue, 6 Nov 2012 13:25:19 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.421.2; Tue, 6 Nov 2012 16:24:53 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 6 Nov 2012 16:24:57 -0500 From: "Polk, William T." To: Russ Housley , IETF PKIX Date: Tue, 6 Nov 2012 16:22:58 -0500 Thread-Topic: [pkix] Fwd: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message Thread-Index: Ac28Ooaa92pulfc6T/Wo53E0kS5R5gAKl5ol Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [pkix] Fwd: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 21:25:21 -0000 BTW, the URL is wrong. The document is draft-dthakore-tls-authz-01 http://tools.ietf.org/html/draft-dthakore-tls-authz-01 ________________________________________ From: pkix-bounces@ietf.org [pkix-bounces@ietf.org] On Behalf Of Russ Housley [housley@vigilsec.com] Sent: Tuesday, November 06, 2012 11:19 AM To: IETF PKIX Subject: [pkix] Fwd: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message People on this list might want to contribute to the discussion on the TLS list. I just want to make sure you know it is happening .... Russ Begin forwarded message: From: Darshak Thakore > Date: November 6, 2012 11:09:02 AM EST To: "tls@ietf.org" > Subject: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message Folks, I am sending this email to obtain feedback and guidance on the following I-D, which proposes a new Authorization Data Format to the TLS SupplementalData Handshake extension to use DTCP certificates as authorization data. If this WG is not the forum to seek feedback on this proposal, please redirect me accordingly. http://tools.ietf.org/html/draft-dthakore-authz-01 >From the Abstract: "This document specifies the use of DTCP certificate as an authorization extension in the Transport Layer Security Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server Hello messages confirm that both parties support the desired authorization data types. Then if supported by both the client and server, DTCP certificates are exchanged in the supplemental data handshake TLS handshake message as specified in RFC4680." Thanks in advance Regards, Darshak Thakore _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Wed Nov 7 06:39:16 2012 Return-Path: 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 0F76321F8B47 for ; Wed, 7 Nov 2012 06:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 lnZTgO3W5Eup for ; Wed, 7 Nov 2012 06:39:15 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7A91C21F8735 for ; Wed, 7 Nov 2012 06:39:15 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2113A35E0B for ; Wed, 7 Nov 2012 15:39:14 +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 6iPdyJrEDT47 for ; Wed, 7 Nov 2012 15:39:13 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DF03835593 for ; Wed, 7 Nov 2012 15:39:13 +0100 (CET) Received: (qmail 87088 invoked from network); 7 Nov 2012 14:39:13 -0000 Received: from dhcp-170c.meeting.ietf.org (HELO [130.129.23.12]) (stefan@fiddler.nu@[130.129.23.12]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Nov 2012 14:39:13 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 07 Nov 2012 09:39:12 -0400 From: Stefan Santesson To: Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:39:16 -0000 I would suggest that what we are trying to do with OCSP in this update is NOT to fix problems with compromised CAs. We are simply allowing responders to provide a more accurate/functional/safer response in case of a status request for a non-issued cert. As said before, the current proposal: - Breaks on-one - Does not add ambiguity for responses to issued certs from good CAs - Does not add ambiguity in any case for those understanding the new extension. - Allows CAB Forum responders to be compliant with OCSP. Problems raised are purely philosophical. Not ONE practical real issue/problem has been presented. If I missed one, please let me know. /Stefan From piyush@ditenity.com Wed Nov 7 10:08:34 2012 Return-Path: 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 A77FA21F88FB for ; Wed, 7 Nov 2012 10:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QCbaIACIb7gd for ; Wed, 7 Nov 2012 10:08:33 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB38121F887F for ; Wed, 7 Nov 2012 10:08:33 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3170214iec.31 for ; Wed, 07 Nov 2012 10:08:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=DDU/evCMlpD0A2mViQrqq2jePS2jriZtvjto0XDkFNs=; b=KZZxS4DChNAI8sjwEPAn0z2882iQ1iyihNfhfMbNE2ALh/d5+d/YTQ45GwYOG/vVqu q64bktjefrCdI+w2KjnvAt7wKmTzaLD7RNpobUm6goWzzexLnWNOxjNs2/hrghyTRlM7 vSEIcyevsuagWRO8tw0iINCedC5nosNTuxLjhqolUaNYHJUHleEoDKdCrtoWE1ucIV9c zNT7RFpd4pW2GsS9fzEXpCC6TzCbMR8LfOcqtrJ8MKynbjs7qDa1XPrb0DcoM0hTLlPB qraXlyPKM+tcvtLRFuR8FRiwAzbpnrpR5/IoB/lzdJAqM9Yfc4WTFwf/dq6cSESWwG9k pPjA== Received: by 10.50.188.199 with SMTP id gc7mr17813995igc.4.1352311712196; Wed, 07 Nov 2012 10:08:32 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id vq4sm2439000igb.10.2012.11.07.10.08.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 10:08:31 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , References: In-Reply-To: Date: Wed, 7 Nov 2012 10:08:29 -0800 Message-ID: <010d01cdbd12$e58f7ee0$b0ae7ca0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHBfksJDS61w42CEfKL2ZLIOS7K2Zf3Ctqw Content-Language: en-us X-Gm-Message-State: ALoCoQnB0ndhwWkngy2L/3hgIAYGLauyWr1CiuWtErU8jjgvQLRfexoV6cpU2epWKHbeNFahWzT2 Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:08:34 -0000 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Wednesday, November 07, 2012 5:39 AM > To: pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP > > I would suggest that what we are trying to do with OCSP in this update is NOT > to fix problems with compromised CAs. [Piyush] [Piyush] This is a change. Until now, the only reason cited for proposing this was to deal with fraudulently issued certificates. > > We are simply allowing responders to provide a more > accurate/functional/safer response in case of a status request for a non- > issued cert. > [Piyush] Certificate is not marked as revoked, so returning revoked for such certificates is not more accurate. Given existing OCSP trust models, there is no additional safety/security. > As said before, the current proposal: > - Breaks on-one [Piyush] Not a reason to propose a change. > - Does not add ambiguity for responses to issued certs from good CAs > - Does not add ambiguity in any case for those understanding the new > extension. [Piyush] Nothing is ambiguous if you view it in a silo. Unfortunately, CAB forum's desire to make OCSP the granddaddy of all certification validation mechanisms without worrying about security, does not imply that other deployments share the same desire. The protocol specification does not say that it should only be used between CAs and browsers. Here are the ambiguities/confusion that you introduce for an implementer who needs to add x.509 support in his application - Is it safe to fallback from OCSP to CRL if OCSP is not available? Traditionally it has been. - What is the need for signature checking if responders can make claim about issuance? It has a performance impact on the client. - what is the meaning of non-issuance? Doesn't a valid signature imply that the certificate was issued? - If I cannot trust a signature on EE certificate, why should I trust the signature on OCSP responder issued by the same CA? > - Allows CAB Forum responders to be compliant with OCSP. [Piyush] What I fail to understand is why current text make such responders non-compliant. If a responder chooses to indicate revoked for fraudulently issued certificates, it can do so under the current guidelines. It is up to the operator of such responder to explain why a certificate is being reported revoked by OCSP and not by CRL. If you put this guideline in the standard, you are tacitly endorsing that it is okay for CAs to continue operations after they've been compromised. As I said before, It may make sense for CAs to do so, depending on the level of compromise. But if they make this business decision, they should be doing the explaining, instead of pointing to a PKIX document that endorses this behavior. > > Problems raised are purely philosophical. Not ONE practical real > issue/problem has been presented. > If I missed one, please let me know. > [Piyush] See above. And BTW, there is not a single practical use case that has been presented (other than CA compromise) where this proposal has any benefit. And in case of CA compromise, the only apparent benefit is that it allows CAs to detect a compromise. Don't get me wrong - I do not care what a compromised responder returns in a response (revoked, unknown, good, beautiful,ugly). The problems are: - presenting it as a minor change that does not affect interpretation of other sections in OCSP and that of other pkix documents. - Lack of accompanying security guidance which is fairly important given the range of claims/counter-claims that has been made about the benefits of this change. From simon@tardell.se Wed Nov 7 10:55:33 2012 Return-Path: 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 4F18121F8B17 for ; Wed, 7 Nov 2012 10:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 9mrdgXr7AAFz for ; Wed, 7 Nov 2012 10:55:32 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB221F8B16 for ; Wed, 7 Nov 2012 10:55:31 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so1619022lam.31 for ; Wed, 07 Nov 2012 10:55:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0GsSRS6mFQBGtwYWXCjdCOfMCRyoV3rXhFxdtbC9kjw=; b=ZUYwfzSu0jvwbfpHCjRoRNkPiv2mYN5a9wj13yvA4uyyJ9YFQEvN0p+IBm679/yGdV 5EIehtvTGnPAvJ7d1ZXKSD3oezQWuCq/czn+Gu9wqMvP6E6wsnUY1CNdZqnhau7ct53P YQF+f9lG9CFSLKkQlCtYimXHMXxcL7+QBl6ziwprpKveBeVHKxxcltFht+23n9vDZE0v PHoBcC9bsjWLbpoDLalU/O34vKMXs6C3vsTzobREQiAgONjVKRAJiYZQA2y8q/PbAAKI HnOCm8ASAuODNqA4OD0xzNvrhYEdvsziYC8MzlQCPSouiLjjz5QYNt94i3CgCckE5A8/ lIiA== MIME-Version: 1.0 Received: by 10.112.9.2 with SMTP id v2mr2265805lba.54.1352314530780; Wed, 07 Nov 2012 10:55:30 -0800 (PST) Received: by 10.112.134.102 with HTTP; Wed, 7 Nov 2012 10:55:30 -0800 (PST) In-Reply-To: <010d01cdbd12$e58f7ee0$b0ae7ca0$@ditenity.com> References: <010d01cdbd12$e58f7ee0$b0ae7ca0$@ditenity.com> Date: Wed, 7 Nov 2012 19:55:30 +0100 Message-ID: From: Simon Tardell To: Piyush Jain Content-Type: multipart/alternative; boundary=e0cb4efe287a3b572a04cdec43dd X-Gm-Message-State: ALoCoQldN4JyvfhXvj7wurPrzGvW1UmScK01pF0qS5Eibfi6c69KlkrmFHBY48D1jdUZY09bpzPR Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:55:33 -0000 --e0cb4efe287a3b572a04cdec43dd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 7, 2012 at 7:08 PM, Piyush Jain wrote: > > > - Allows CAB Forum responders to be compliant with OCSP. > [Piyush] What I fail to understand is why current text make such responders > non-compliant. > If a responder chooses to indicate revoked for fraudulently issued > certificates, it can do so under the current guidelines. It is up to the > operator of such responder to explain why a certificate is being reported > revoked by OCSP and not by CRL. > If you put this guideline in the standard, you are tacitly endorsing that > it > is okay for CAs to continue operations after they've been compromised. > > As I said before, It may make sense for CAs to do so, depending on the > level > of compromise. But if they make this business decision, they should be > doing > the explaining, instead of pointing to a PKIX document that endorses this > behavior. > > To me, this is not so much about endorsing CAs to respond on whether a certificate was issued or not. And certainly not promote the idea that CAs can continue operations beyond compromise. I mostly agree with the you about the futility of these ideas. However. I believe that cause is lost already. There are CAs out there that already check issuance. I want to prevent CAs from using "unknown" to indicate non-issuance, since I believe it breaks the protocol, and an important aspect of the protocol at that (besides from being highly illogical). Also, I want to stop this perennial beating of a horse with limited vital signs. The issuance issue and whether it should be reported and how has been discussed on this list on-and-off for well over ten years (at least twelve). I think all the caveats that you and others have pointed out should be summarized in the RFC. E.g. there should be a caution that if you implement some kind of white list functionality, you can't reliably fall back to CRLs etc. Once this issue is off the table I think it could be useful to discuss if there are real solutions to the problems that web PKI and national PKIs are facing (I believe there are), and if they warrant changes or extensions to formats and or protocols. /Simon --e0cb4efe287a3b572a04cdec43dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, N= ov 7, 2012 at 7:08 PM, Piyush Jain <piyush@ditenity.com> w= rote:
> - Allows CAB Forum responders to be compliant with OCSP.
[Piyush] What I fail to understand is why current text make such resp= onders
non-compliant.
If a responder chooses to indicate revoked for fraudulently issued
certificates, it can do so under the current guidelines. It is up to the operator of such responder to explain why a certificate is being reported revoked by OCSP and not by CRL.
If you put this guideline in the standard, you are tacitly endorsing that i= t
is okay for CAs to continue operations after they've been compromised.<= br>
As I said before, It may make sense for CAs to do so, depending on the leve= l
of compromise. But if they make this business decision, they should be doin= g
the explaining, instead of pointing to a PKIX document that endorses this behavior.


To me, this is= not so much about endorsing CAs to respond on whether a certificate was is= sued or not. And certainly not promote the idea that CAs can continue opera= tions beyond compromise. I mostly agree with the you about the futility of = these ideas. However. I believe that cause is lost already. There are CAs o= ut there that already check issuance. =A0I want to prevent CAs from using &= quot;unknown" to indicate non-issuance, since I believe it breaks the = protocol, and an important aspect of the protocol at that (besides from bei= ng highly illogical). Also, I want to stop this perennial beating of a hors= e with limited vital signs. The issuance issue and whether it should be rep= orted and how has been discussed on this list on-and-off for well over ten = years (at least twelve).

I think all the caveats that you and others have pointe= d out should be summarized in the RFC. E.g. there should be a caution that = if you implement some kind of white list functionality, you can't relia= bly fall back to CRLs etc.

Once this issue is off the table I think it could be us= eful to discuss if there are real solutions to the problems that web PKI an= d national PKIs are facing (I believe there are), and if they warrant chang= es or extensions to formats and or protocols.

/Simon
--e0cb4efe287a3b572a04cdec43dd-- From hallam@gmail.com Wed Nov 7 14:00:32 2012 Return-Path: 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 23F0521F8458 for ; Wed, 7 Nov 2012 14:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SYnDxn82obeE for ; Wed, 7 Nov 2012 14:00:30 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C23F21F8C53 for ; Wed, 7 Nov 2012 13:56:00 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2360529oag.31 for ; Wed, 07 Nov 2012 13:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ZyPG9+W+Sp/nba9tdtFUZ3LFlK1Qv2pNk07b8Go9Q0=; b=eaSKLJO5Hb/ihksNyms997+AClV3Nwyto2tTnZ+8KxuUMU7ICk5n7GvNzkeRXNOfPo r557B+yjVVVJEo0GIRJMU95p5jQAq+NTRmXl35Hxp5c8px8e7uCMM2ZNPCK5HTepeb2N WvsZ4kWtOBiNGtGX6EEiBr2RER5vD2/HNk9mWHVnmzljEQC31WWltBcOclKAlsdEcR3G xrjGi92y/+/gJtmQCi99MpxhFsWnRDy+XSvvLlEEVHTi0nMFaMY0CjUTG/0+dDKzOJHl eAh8sAvy/bLICWqWoIxEe9m91FAkAIKJLxA2RYtAYOKFBnQjMTw29HYcYtKQBMaUyRgX 49bQ== MIME-Version: 1.0 Received: by 10.60.28.42 with SMTP id y10mr3143648oeg.24.1352325359671; Wed, 07 Nov 2012 13:55:59 -0800 (PST) Received: by 10.76.27.103 with HTTP; Wed, 7 Nov 2012 13:55:59 -0800 (PST) In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> Date: Wed, 7 Nov 2012 16:55:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Tom Gindin Content-Type: multipart/alternative; boundary=e89a8f503b84af1aa204cdeec8a1 Cc: "pkix@ietf.org" , Stefan Santesson Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:00:32 -0000 --e89a8f503b84af1aa204cdeec8a1 Content-Type: text/plain; charset=ISO-8859-1 The reason I think that we should take a look at what the clients actually do here is that experience suggests that the specification is a poor guide to behavior even in the cases where it is unambiguous. On Mon, Nov 5, 2012 at 9:08 PM, Tom Gindin wrote: > Phill: > > Why do you think that a non-critical CRL entry extension will > result in clients accepting the referenced cert? RFC 5280 5.3 says that > RP's can ignore unrecognized extensions to an entry, not that they can > ignore entries containing unrecognized extensions. A CRL entry without an > extension (indeed, almost any CRL entry except one containing reasonCode > removeFromCRL) implies that the certificate should be rejected for current > use. So marking reason non-critical shouldn't hurt anything. > > Tom Gindin > > > > > From: Phillip Hallam-Baker > To: Stefan Santesson , > Cc: "pkix@ietf.org" > Date: 11/01/2012 09:46 AM > Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked > certificates. > Sent by: pkix-bounces@ietf.org > > > > 1 and 3b > > Reading through the thread it appears that the poll has actually turned > into > > 3a Do nothing > 3b Add in unknown. > > But going back to the original straw poll, I think that it is pretty clear > that any viable implementation of 'unknown' would have to be implemented > as a CRL or OCSP entry that is marked 'Revoked' with a NON CRITICAL > extension giving the revocation reason as 'It never existed' > > Marking the reason as non-critical looks like it is only going to result > in the undesired behavior as clients will reject the CRL entry completely > and accept the cert as good. Which is stupid behavior but so was not > having the status 'never existed'. > > I would prefer the form of the OCSP 'does not exist' entry to specify a > range of cert serial numbers that do not exist. This permits pre-signing > of the responses and avoids a potential DoS issue. > > > > On Tue, Oct 30, 2012 at 5:52 AM, Stefan Santesson > wrote: > Before we loose everyone engaged in this, I would like to make a > straw-poll: > > > Background: > A client may do a request for a certificate that has never been issued by > the CA. > This request may be done deliberately, by mistake or as a consequence of a > compromised CA. > > The OCSP protocol does not require OCSP responders to have any knowledge > about issued certificates. It must only know about revoked certificates > that are within it's current validity period. However, some OCSP > responders closely coupled with the CA may also know if a certificate with > a particular serialNumber value has been issued or not. > > The following is agreed: > - An OCSP responder is allowed to respond "good" to a status request > for a non-revoked certificate, disregarding if it has ever been issued. > > - A client, having no additional out-of-band knowledge about the OCSP > responder, will just know that the certificate is "not revoked" when > receiving a "good" response, unless the response includes one or more > response extensions that provides additional information. > > > The following is debated: > - Is an OCSP responder allowed to respond "revoked" even if a requested > certificate serial number is not on the list of revoked certificates, IF > the OCSP responder has positive knowledge that the requested serial number > does NOT represent a valid certificate issued by the identified CA? > > > Rationale for: > There are a number of reasons to allow this that has been mentioned, such > as: > - It breaks nothing. A legitimate request for an issued certificate will > get a legitimate deterministic response. > - It's safer. Responding "revoked" may not prevent a compromised CA from > being exploited. But if a request for a serialNumber that is known to be > bad is done nevertheless, a "revoked" response will at least be safer than > responding "good". > - Allowing extension definitions with further semantics. A response > extension may be defined in the future that adds more information about > the requested certificate. This may include a positive confirmation that > the certificate has been issued as well as information that this > particular OCSP responder will only respond "good" if it knows that the > requested certificate has been issued, otherwise it will respond > "revoked". An extension with such semantics can only be defined if the > base standard allows a status other than "good" in such situation. > - Supporting Web-PKI. The CAB-Forum has indicated that they will profile > the OCSP protocol for use with web server authentication. In such profile > they have indicated that they will NOT allow the "good" response unless > the requested certificate is known to have been issued. This means that > they will require OCSP responder in their infrastructure to have this > knowledge. Such profile would have to break the base OCSP standard if this > states that "good" MUST be returned unless the certificate has been > revoked. > > Rationale against: > The basic rationale against raised on this list has been the argument that > it is wrong and confusing to allow anything but "good" as a response to a > non-revoked certificate (if the cert is issued by a CA that is served by > this OCSP responder). > Another strong opinion is that it basically does not solve anything. A > broken CA is broken and can't be fixed by responding "revoked". It would > be easy to adapt an attack to circumvent such response, for example by > issuing a fake certificate that duplicates a legitimate serialNumber. > > > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). > > > > > Note: both alternatives are placed in a context where the certificate is > claimed to be issued by a CA that is served by this OCSP responder. The > exact meaning of "bad" is for later discussion. > > Please keep any motivation short and do not use this thread for long > debates. > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > -- Website: http://hallambaker.com/ --e89a8f503b84af1aa204cdeec8a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The reason I think that we should take a look at what the clients actually = do here is that experience suggests that the specification is a poor guide = to behavior even in the cases where it is unambiguous.


On Mon, Nov 5, 2012 at 9:08 PM, Tom Gind= in <tgindin@us.ibm.com> wrote:
=A0 =A0 =A0 =A0 Phill:

=A0 =A0 =A0 =A0 Why do you think that a non-critical CRL entry extension wi= ll
result in clients accepting the referenced cert? =A0RFC 5280 5.3 says that<= br> RP's can ignore unrecognized extensions to an entry, not that they can<= br> ignore entries containing unrecognized extensions. =A0A CRL entry without a= n
extension (indeed, almost any CRL entry except one containing reasonCode removeFromCRL) implies that the certificate should be rejected for current<= br> use. =A0So marking reason non-critical shouldn't hurt anything.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tom Gindin




From: =A0 Phillip Hallam-Baker <hall= am@gmail.com>
To: =A0 =A0 Stefan Santesson <stef= an@aaa-sec.com>,
Cc: =A0 =A0 "pkix@ietf.org" = <pkix@ietf.org>
Date: =A0 11/01/2012 09:46 AM
Subject: =A0 =A0 =A0 =A0Re: [pkix] Straw-poll on OCSP responses for non-rev= oked
certificates.
Sent by: =A0 =A0 =A0 =A0pkix-bounc= es@ietf.org



1 and 3b

Reading through the thread it appears that the poll has actually turned
into

3a Do nothing
3b Add in unknown.

But going back to the original straw poll, I think that it is pretty clear<= br> that any viable implementation of 'unknown' would have to be implem= ented
as a CRL or OCSP entry that is marked 'Revoked' with a NON CRITICAL=
extension giving the revocation reason as 'It never existed'

Marking the reason as non-critical looks like it is only going to result in the undesired behavior as clients will reject the CRL entry completely and accept the cert as good. Which is stupid behavior but so was not
having the status 'never existed'.

I would prefer the form of the OCSP 'does not exist' entry to speci= fy a
range of cert serial numbers that do not exist. This permits pre-signing of the responses and avoids a potential DoS issue.



On Tue, Oct 30, 2012 at 5:52 AM, Stefan Santesson <stefan@aaa-sec.com>
wrote:
Before we loose everyone engaged in this, I would like to make a
straw-poll:


Background:
A client may do a request for a certificate that has never been issued by the CA.
This request may be done deliberately, by mistake or as a consequence of a<= br> compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates
that are within it's current validity period. However, some OCSP
responders closely coupled with the CA may also know if a certificate with<= br> a particular serialNumber value has been issued or not.

The following is agreed:
=A0 =A0- An OCSP responder is allowed to respond "good" to a stat= us request
for a non-revoked certificate, disregarding if it has ever been issued.

=A0 =A0- A client, having no additional out-of-band knowledge about the OCS= P
responder, will just know that the certificate is "not revoked" w= hen
receiving a "good" response, unless the response includes one or = more
response extensions that provides additional information.


The following is debated:
=A0 =A0- Is an OCSP responder allowed to respond "revoked" even i= f a requested
certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number<= br> does NOT represent a valid certificate issued by the identified CA?


Rationale for:
There are a number of reasons to allow this that has been mentioned, such as:
=A0- It breaks nothing. A legitimate request for an issued certificate will=
get a legitimate deterministic response.
=A0- It's safer. Responding "revoked" may not prevent a compr= omised CA from
being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be s= afer than
responding "good".
=A0- Allowing extension definitions with further semantics. A response
extension may be defined in the future that adds more information about
the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this
particular OCSP responder will only respond "good" if it knows th= at the
requested certificate has been issued, otherwise it will respond
"revoked". An extension with such semantics can only be defined i= f the
base standard allows a status other than "good" in such situation= .
=A0- Supporting Web-PKI. The CAB-Forum has indicated that they will profile=
the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response = unless
the requested certificate is known to have been issued. This means that
they will require OCSP responder in their infrastructure to have this
knowledge. Such profile would have to break the base OCSP standard if this<= br> states that "good" MUST be returned unless the certificate has be= en
revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that<= br> it is wrong and confusing to allow anything but "good" as a respo= nse to a
non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder).
Another strong opinion is that it basically does not solve anything. A
broken CA is broken and can't be fixed by responding "revoked"= ;. It would
be easy to adapt an attack to circumvent such response, for example by
issuing a fake certificate that duplicates a legitimate serialNumber.


Please reply with either:

1. Allow "revoked" response for a certificate that has not been &= quot;revoked"
but where that OCSP responder for any other reason knows the certificate to be "bad".

2. Require that the OCSP responder MUST respond "good" in this si= tuation.

3. Neither 1 or 2 (motivate).




Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The
exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long
debates.






_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



--
Website: http://halla= mbaker.com/
_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix





--
= Website: http://hallambaker.com/
--e89a8f503b84af1aa204cdeec8a1-- From denis.pinkas@bull.net Thu Nov 8 00:32:09 2012 Return-Path: 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 61E1021F8661 for ; Thu, 8 Nov 2012 00:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 VwT3V3NzjFDC for ; Thu, 8 Nov 2012 00:32:08 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 73EAA21F88B2 for ; Thu, 8 Nov 2012 00:32:08 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 377881C9A9 for ; Thu, 8 Nov 2012 09:32:07 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012110809320655-693 ; Thu, 8 Nov 2012 09:32:06 +0100 Message-ID: <509B6DFC.8000009@bull.net> Date: Thu, 08 Nov 2012 09:31:56 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 08/11/2012 09:32:06, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 08/11/2012 09:32:06, Serialize complete at 08/11/2012 09:32:06 X-TNEFEvaluated: 1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 08:32:09 -0000 Stefan, There are two problems with the current proposal: 1) In France, currently, the technical specifications which are mandated=20 by the French legislation forbid the use of the suspension state: IV.9.13. Causes possibles d=92une suspension La suspension de certificats n'est pas autoris=E9e dans la pr=E9sente PC = Type. Sources: a) Annexe A8 au RGSv1.0 : PC Type - Signature. Identification du=20 document (OID) 1.2.250.1.137.2.2.1.2.2.2 2.3 date 11/02/2010 Page 41/82 b) Annexe A7 au RGSv1.0 : PC Type - Authentification. Identification du=20 document (OID) 1.2.250.1.137.2.2.1.2.2.1 2.3 Date 11/02/2010 Page 42/82 So requiring the support of the suspension state would either : a - prevent the CAs and OCSP responders which comply with that=20 legislation to take advantage of the indication of a certificate that is not in the database of issued certificates and=20 currently within their validity period, or b - mandate a change in the specification which will only be applicable=20 in the future. . 2=B0 For CAS which do not comply with that French legislation, and for=20 certificates used for non repudiation purposes, when an electronic signature is verified, if a certificate is suspended,=20 then the current logic is to consider that the status of the electronic signature is unknown but if it is possible=20 to make a final decision later on, another test will be done later on, since the suspension state (in the usual case) is=20 not going to last for ever. Since the proposal is deviating from the original meaning of the=20 suspension state, we would be in a case where the suspension state would last for ever. So the verifying applications=20 will keep continue to wait for the end of the suspended state and that end will never happen. I do not believe that=20 this is nice. Returning the unknown status is still the better choice in the case=20 where a certificate that is not in the database of issued certificates and currently within their validity period. Remember that is is a major difference between an unknown status=20 returned by an authoritative OCSP responder and an unknown status returned by an OCSP responder that is not=20 authoritative. In the former case, the relying party has no reason to switch to a CRL issuer (if it ever exist) , since the=20 OCSP responder is authoritative and did said "unknown". IMO, changing the semantics of "suspended" is not acceptable. Denis PS. A reply to Simon who said: " I want to prevent CAs from using=20 "unknown" to indicate non-issuance"; This sentence is not appropriate. CAs do not return certificate statuses=20 unless they act as CRL issuers or OCSP responders. Your main argument against the use of the unknown=20 status is the use of CRLs as a fall back mechanism. At this time, nobody said on the list under which=20 exact circumstances that fall back mechanism is being used in some code. Is it when there is no response=20 from the OCSP responder (in such a case, all solutions are equivalent) or under other=20 circumstances (which would need to be detailed) ? > I would suggest that what we are trying to do with OCSP in this update = is > NOT to fix problems with compromised CAs. > > We are simply allowing responders to provide a more > accurate/functional/safer response in case of a status request for a > non-issued cert. > > As said before, the current proposal: > - Breaks on-one > - Does not add ambiguity for responses to issued certs from good CAs > - Does not add ambiguity in any case for those understanding the new > extension. > - Allows CAB Forum responders to be compliant with OCSP. > > Problems raised are purely philosophical. Not ONE practical real > issue/problem has been presented. > If I missed one, please let me know. > > /Stefan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From i-barreira@izenpe.net Thu Nov 8 01:27:54 2012 Return-Path: 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 0728221F8679 for ; Thu, 8 Nov 2012 01:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_MEN=2.3, RCVD_IN_DNSWL_LOW=-1] 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 03i81Uyomsqg for ; Thu, 8 Nov 2012 01:27:53 -0800 (PST) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id 531B821F85F7 for ; Thu, 8 Nov 2012 01:27:52 -0800 (PST) Received: from ejlp023.ejgv ([212.55.29.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MD500HXRWYEBL80@ektmail1mta2.euskaltel.es> for pkix@ietf.org; Thu, 08 Nov 2012 10:27:50 +0100 (CET) Received: from AFE03.ejsarea.net (afe03 [10.200.192.20]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id qA89RgFT022715; Thu, 08 Nov 2012 10:27:42 +0100 Received: from AEX06.ejsarea.net ([10.200.198.15]) by AFE03.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 08 Nov 2012 10:27:50 +0100 Date: Thu, 08 Nov 2012 10:27:49 +0100 From: i-barreira@izenpe.net To: stefan@aaa-sec.com, pkix@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [pkix] What's the need to introduce fraudulently issuedcertificates in OCSP Thread-index: Ac289bC/mWdkCFKPSe6RON6MFuhuAgAmssUg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Nov 2012 09:27:50.0817 (UTC) FILETIME=[52A79910:01CDBD93] Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 09:27:54 -0000 Hi all, In the recent Straw poll after saying that this is not a way to fix it = and choose option 1 as the lesser evil, I=B4d like to clarify my = "proposal" and let you know that from a point of view of a PKI software = company that wants to implement this solution, it=B4s not easy and in = fact will not fix anything. So here it goes This "fix" tries to avoid that someone can issue a bogus certificate and = after that delete the log/registry of the issuance (This is the = Diginotar case). But this "fix" wouldn=B4t help/fix much: - if a bogus certificate has been issued, it means that the CA key has = been compromised so that CA has to be removed/deleted/destroyed. But - as I=B4m an evil hacker that get access to the CA, I can create the = bogus certificate without AIA - as I=B4m en evil hacket that get access to the CA, I can create the = bogus certificate without AIA and with CDP pointing to legitimate CRLs - as I=B4m en evil hacket that get access to the CA, I can create the = bogus certificate with an AIA that points to an OCSP responder that I = control/manage - as I=B4m en evil hacket that get access to the CA, I can create the = bogus certificate with a serial number of a valid certificate So, all third parties systems that use CRLs instead of OCSP to validate = certs, will consider this bogus cert as valid In summary, the VA has to manage, somehow, a kind of a white list that = can grow to the infinite. This VA has to "ask this list" every time an = OCSP responder is generated and has to update practically at the same = time than the issuance of the certificate. But the key question is that once this evil hacker has done "his job", = the only fix is to revoke the complete CA. It=B4s useless that the OCSP = responder gives a "revoked" for unknown certificates because the = browsers for example could be asking the bogus OCSP (the one controlled = by the hacker) or asking for a serial number of the bogus certificate = which is identical to a legitimate one. I know that we all know this situation so maybe this is useless, not = easy to implement for sure and with very limited good results. Regards I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de = Stefan Santesson Enviado el: mi=E9rcoles, 07 de noviembre de 2012 14:39 Para: pkix@ietf.org Asunto: Re: [pkix] What's the need to introduce fraudulently issued = certificates in OCSP I would suggest that what we are trying to do with OCSP in this update = is NOT to fix problems with compromised CAs. We are simply allowing responders to provide a more = accurate/functional/safer response in case of a status request for a = non-issued cert. As said before, the current proposal: - Breaks on-one - Does not add ambiguity for responses to issued certs from good CAs - Does not add ambiguity in any case for those understanding the new = extension. - Allows CAB Forum responders to be compliant with OCSP. Problems raised are purely philosophical. Not ONE practical real = issue/problem has been presented. If I missed one, please let me know. /Stefan _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From simon@tardell.se Thu Nov 8 02:10:30 2012 Return-Path: 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 CF7BB21F8A59 for ; Thu, 8 Nov 2012 02:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 rCv8qpjW0x6l for ; Thu, 8 Nov 2012 02:10:29 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14C9A21F8827 for ; Thu, 8 Nov 2012 02:10:28 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so2209437lbo.31 for ; Thu, 08 Nov 2012 02:10:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ncMSkbOq1p9v/9sE7DHmFLQoam2LpgwdCs6sZDYasVo=; b=ItgcvIZ4Ow8nks0tVCkupzPQ4twBFK8VWRQgz3EDK8mM2WffQmEKSDmnbqbKJHQzkT 2tpzdR/nproboNHlQJrcvesZdGDIbA83fuOU7suV2/jvL7B5wMkCrvNu5CClR8usIP13 aSGd054BWtdiR9aCy18/p9Q/M/F6CDLJofu/ktXMMilNRRwyQHJ9n5r3er+nXwiz6Mdh OMY4EFSkq8f+sazSh1kXzEim9QoQvZCwVinYOoTfa7HTtt+4KrF70fim76U6xlEYiuA0 Db8AsfLxC45MUfbrz+XimTVBulGzvGZYBWiOzPuzStJ3LQfGljAEBe08b5FNI2Xqrai5 Sjug== MIME-Version: 1.0 Received: by 10.112.102.196 with SMTP id fq4mr3023300lbb.125.1352369427585; Thu, 08 Nov 2012 02:10:27 -0800 (PST) Received: by 10.112.134.102 with HTTP; Thu, 8 Nov 2012 02:10:27 -0800 (PST) In-Reply-To: <509B6DFC.8000009@bull.net> References: <509B6DFC.8000009@bull.net> Date: Thu, 8 Nov 2012 11:10:27 +0100 Message-ID: From: Simon Tardell To: Denis Pinkas Content-Type: multipart/alternative; boundary=f46d04016ae5561a2704cdf90b91 X-Gm-Message-State: ALoCoQlxRrB6VY+f0m/O/w5I7pAqHP8rCcacZNwAYaxW4qZKhS3/a9xSObipHGm8bVayFcKlm1ex Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 10:10:31 -0000 --f46d04016ae5561a2704cdf90b91 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Nov 8, 2012 at 9:31 AM, Denis Pinkas wrote: > Stefan, > > There are two problems with the current proposal: > > 1) In France, currently, the technical specifications which are mandated > by the French legislation forbid the use of the suspension state: > > IV.9.13. Causes possibles d=92une suspension > La suspension de certificats n'est pas autoris=E9e dans la pr=E9sente PC = Type. > Well, that is ok. We are not proposing suspending any certificates, only non-certificates. (Note that it does *not* say that an OCSP responder must not respond with reason code certificate hold, it says *certificates* must not be put on hold, or equivalently that the validity period of the certificate must be continuous.) > 2=B0 For CAS which do not comply with that French legislation, and for > certificates used for non repudiation purposes, > when an electronic signature is verified, if a certificate is suspended, > then the current logic is to consider that > the status of the electronic signature is unknown but if it is possible t= o > make a final decision later on, another test > will be done later on, since the suspension state (in the usual case) is > not going to last for ever. > > Since the proposal is deviating from the original meaning of the > suspension state, we would be in a case where > the suspension state would last for ever. So the verifying applications > will keep continue to wait for the end of the > suspended state and that end will never happen. I do not believe that thi= s > is nice. > > [=85] > IMO, changing the semantics of "suspended" is not acceptable > Well, that is exactly what you did in the text above! You more or less reversed the meaning of revoked (certificateHold) and unknown. If a certificate is revoked at the time of use, the use is not approved by the CA. Period. The only thing special with reason code certificateHold is that it may become approved for use at a later point in time, but it can not change status at the current point in time. CertificateHold is useful when you have lost control of your token but may be able to recover it without it having been compromised (as in your wallet is missing, and you probably left it at home this morning, but you are not 100% sure). If you recover your token, you can unsuspend it again. But in the off chance that the cleaning lady used her keys to get into your apartment and found your wallet, used your card and put it back into place without you noticing anything, any signature created during the suspension period must be rejected. (And certificateHold makes sense only when replacing a token is expensive compared to the extra complexity of handling the suspension state, of course). Returning the unknown status is still the better choice in the case where a > certificate that is not in the database > of issued certificates and currently within their validity period. > Remember that is is a major difference between an unknown status returned > by an authoritative OCSP responder and > an unknown status returned by an OCSP responder that is not authoritative= . > In the former case, the relying party > has no reason to switch to a CRL issuer (if it ever exist) , since the > OCSP responder is authoritative and did said "unknown". Responding "unknown" means "I am not authoritative for this issuer, at least not right now.". The only difference in your authoritative and non-authoritative case is whether there is any one else to ask. An authoritative responder is probably less likely to respond "unknown", but could have outages too. PS. A reply to Simon who said: " I want to prevent CAs from using "unknown" > to indicate non-issuance"; > This sentence is not appropriate. CAs do not return certificate statuses > unless they act as CRL issuers > or OCSP responders. Your main argument against the use of the unknown > status is the use of CRLs as a > fall back mechanism. At this time, nobody said on the list under which > exact circumstances that fall back > mechanism is being used in some code. Is it when there is no response fro= m > the OCSP responder > (in such a case, all solutions are equivalent) or under other > circumstances (which would need to be detailed) ? "Unknown" is part of what makes it possible to provide timely revocation information in a distributed and redundant fashion. This is a useful feature which I would like you not to break for me. Falling back to CRLs is the least useful option, but what many clients (including Windows) will do. That is a security problem, if you let "unknown" be an assertion of non-issuance. /Simon --f46d04016ae5561a2704cdf90b91 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Thu, N= ov 8, 2012 at 9:31 AM, Denis Pinkas <denis.pinkas@bull.net> wrote:
Stefan,

There are two problems with the current proposal:

1) In France, currently, the technical specifications which are mandated by= the French legislation forbid the use of the suspension state:

IV.9.13. Causes possibles d=92une suspension
La suspension de certificats n'est pas autoris=E9e dans la pr=E9sente P= C Type.

Well, that is ok. We are not pr= oposing suspending any certificates, only non-certificates. (Note that it d= oes not say that an OCSP responder must not respond with reason code= certificate hold, it says certificates must not be put on hold, or = equivalently that the validity period of the certificate must be continuous= .)
=A0
2=B0 For CAS which do not comply with th= at French legislation, and for certificates used for non repudiation purpos= es,
when an electronic signature is verified, if a certificate is suspended, th= en the current logic is to consider that
the status of the electronic signature is unknown but if it is possible to = make a final decision later on, another test
will be done later on, since the suspension state (in the usual case) is no= t going to last for ever.

Since the proposal is deviating from the original meaning of the suspension= state, we would be in a case where
the suspension state would last for ever. So the verifying applications wil= l keep continue to wait for the end of the
suspended state and that end will never happen. I do not believe that this = is nice.

=A0[=85]
IMO, changing the semantics of "suspended" is not acceptable
<= /blockquote>

Well, that is exactly what you did in the t= ext above! You more or less reversed the meaning of revoked (certificateHol= d) and unknown.=A0

If a certificate is revoked at the time of use, the use= is not approved by the CA. Period. The only thing special with reason code= certificateHold is that it may become approved for use at a later point in= time, but it can not change status at the current point in time.=A0

CertificateHold is useful when you have lost control of= your token but may be able to recover it without it having been compromise= d (as in your wallet is missing, and you probably left it at home this morn= ing, but you are not 100% sure). If you recover your token, you can unsuspe= nd it again. But in the off chance that the cleaning lady used her keys to = get into your apartment and found your wallet, used your card and put it ba= ck into place without you noticing anything, any signature created during t= he suspension period must be rejected. (And certificateHold makes sense onl= y when replacing a token is expensive compared to the extra complexity of h= andling the suspension state, of course).

Returning the unknown status is still the b= etter choice in the case where a certificate that is not in the database of issued certificates and currently within their validity period.
Remem= ber that is is a major difference between an unknown status returned by an = authoritative OCSP responder and
an unknown status returned by an OCSP r= esponder that is not authoritative. In the former case, the relying party has no reason to switch to a CRL issuer (if it ever exist) , since the OCSP= responder is authoritative and did said "unknown".
<= div>
Responding "unknown" means "I am not auth= oritative for this issuer, at least not right now.". The only differen= ce in your authoritative and non-authoritative case is whether there is any= one else to ask. An authoritative responder is probably less likely to res= pond "unknown", but could have outages too.

PS. A reply to Simon who said: " I want to prevent CAs from using &quo= t;unknown" to indicate non-issuance";
This sentence is not appropriate. CAs do not return certificate statuses un= less they act as CRL issuers
or OCSP responders. Your main argument against the use of the unknown statu= s is the use of CRLs as a
fall back mechanism. At this time, nobody said on the list under which exac= t circumstances that fall back
mechanism is being used in some code. Is it when there is no response from = the OCSP responder
(in such a case, all solutions are equivalent) or under other circumstances= (which would need to be detailed) ?

"= Unknown" is part of what makes it possible to provide timely revocatio= n information in a distributed and redundant fashion. This is a useful feat= ure which I would like you not to break for me. Falling back to CRLs is the= least useful option, but what many clients (including Windows) will do. Th= at is a security problem, if you let "unknown" be an assertion of= non-issuance.=A0
=A0
/Simon

--f46d04016ae5561a2704cdf90b91-- From stefan@aaa-sec.com Thu Nov 8 05:51:29 2012 Return-Path: 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 CA2EB21F8B0C for ; Thu, 8 Nov 2012 05:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 VIXZNASofvhF for ; Thu, 8 Nov 2012 05:51:29 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 331C021F8B74 for ; Thu, 8 Nov 2012 05:51:28 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 3F21739E81 for ; Thu, 8 Nov 2012 14:51:26 +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 7D82fXHzgDwQ for ; Thu, 8 Nov 2012 14:51:24 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 28E65588CF for ; Thu, 8 Nov 2012 14:51:22 +0100 (CET) Received: (qmail 34764 invoked from network); 8 Nov 2012 13:51:21 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Nov 2012 13:51:21 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 08 Nov 2012 08:51:18 -0400 From: Stefan Santesson To: , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:51:29 -0000 Hi, On 11/8/12 5:27 AM, "i-barreira@izenpe.net" wrote: >This "fix" tries to avoid that someone can issue a bogus certificate and >after that delete the log/registry of the issuance (This is the Diginotar >case). But this "fix" wouldn=B4t help/fix much: You go wrong already here, and thus the rest goes wrong as well. This is NOT what the fix attempts to do. This is what CAB Forum attempts to do. If you think the CAB Forum deals with this the wrong way, you should really take this up on their mailing list. This fix (The OCSP update in PKIX) simply allows CAB forum to do what they feel they need to do in one particular area. /Stefan From stefan@aaa-sec.com Thu Nov 8 05:57:01 2012 Return-Path: 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 B7F2421F85F4 for ; Thu, 8 Nov 2012 05:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.551 X-Spam-Level: X-Spam-Status: No, score=-101.551 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396, 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 NSfYh4qlJr9h for ; Thu, 8 Nov 2012 05:57:01 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A37DB21F85E2 for ; Thu, 8 Nov 2012 05:57:00 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7928839A98 for ; Thu, 8 Nov 2012 14:56:59 +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 r_KbjxBMF00O for ; Thu, 8 Nov 2012 14:56:58 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id CE98F39C2A for ; Thu, 8 Nov 2012 14:56:58 +0100 (CET) Received: (qmail 36674 invoked from network); 8 Nov 2012 13:56:58 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Nov 2012 13:56:58 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 08 Nov 2012 08:56:54 -0400 From: Stefan Santesson To: Denis Pinkas , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <509B6DFC.8000009@bull.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:57:01 -0000 So you can't use this option for French CAs that needs to conform to this legislation. If the OCSP update says SHOULD set certificateHold, then you can set something else for those CAs (if that is what you want). Would that help? /Stefan On 11/8/12 4:31 AM, "Denis Pinkas" wrote: >Stefan, > >There are two problems with the current proposal: > >1) In France, currently, the technical specifications which are mandated >by the French legislation forbid the use of the suspension state: > >IV.9.13. Causes possibles d=B9une suspension >La suspension de certificats n'est pas autoris=E9e dans la pr=E9sente PC Type. > >Sources: > >a) Annexe A8 au RGSv1.0 : PC Type - Signature. Identification du >document (OID) 1.2.250.1.137.2.2.1.2.2.2 2.3 >date 11/02/2010 Page 41/82 > >b) Annexe A7 au RGSv1.0 : PC Type - Authentification. Identification du >document (OID) 1.2.250.1.137.2.2.1.2.2.1 2.3 >Date 11/02/2010 Page 42/82 > >So requiring the support of the suspension state would either : > >a - prevent the CAs and OCSP responders which comply with that >legislation to take advantage of the indication >of a certificate that is not in the database of issued certificates and >currently within their validity period, or > >b - mandate a change in the specification which will only be applicable >in the future. >. >2=B0 For CAS which do not comply with that French legislation, and for >certificates used for non repudiation purposes, >when an electronic signature is verified, if a certificate is suspended, >then the current logic is to consider that >the status of the electronic signature is unknown but if it is possible >to make a final decision later on, another test >will be done later on, since the suspension state (in the usual case) is >not going to last for ever. > >Since the proposal is deviating from the original meaning of the >suspension state, we would be in a case where >the suspension state would last for ever. So the verifying applications >will keep continue to wait for the end of the >suspended state and that end will never happen. I do not believe that >this is nice. > >Returning the unknown status is still the better choice in the case >where a certificate that is not in the database >of issued certificates and currently within their validity period. > >Remember that is is a major difference between an unknown status >returned by an authoritative OCSP responder and >an unknown status returned by an OCSP responder that is not >authoritative. In the former case, the relying party >has no reason to switch to a CRL issuer (if it ever exist) , since the >OCSP responder is authoritative and did said "unknown". > >IMO, changing the semantics of "suspended" is not acceptable. > >Denis > >PS. A reply to Simon who said: " I want to prevent CAs from using >"unknown" to indicate non-issuance"; >This sentence is not appropriate. CAs do not return certificate statuses >unless they act as CRL issuers >or OCSP responders. Your main argument against the use of the unknown >status is the use of CRLs as a >fall back mechanism. At this time, nobody said on the list under which >exact circumstances that fall back >mechanism is being used in some code. Is it when there is no response >from the OCSP responder >(in such a case, all solutions are equivalent) or under other >circumstances (which would need to be detailed) ? > >> I would suggest that what we are trying to do with OCSP in this update >>is >> NOT to fix problems with compromised CAs. >> >> We are simply allowing responders to provide a more >> accurate/functional/safer response in case of a status request for a >> non-issued cert. >> >> As said before, the current proposal: >> - Breaks on-one >> - Does not add ambiguity for responses to issued certs from good CAs >> - Does not add ambiguity in any case for those understanding the new >> extension. >> - Allows CAB Forum responders to be compliant with OCSP. >> >> Problems raised are purely philosophical. Not ONE practical real >> issue/problem has been presented. >> If I missed one, please let me know. >> >> /Stefan >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From i-barreira@izenpe.net Thu Nov 8 07:14:33 2012 Return-Path: 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 54F4A21F887F for ; Thu, 8 Nov 2012 07:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] 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 lV+YCRT4qjgc for ; Thu, 8 Nov 2012 07:14:31 -0800 (PST) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id A77BD21F85B2 for ; Thu, 8 Nov 2012 07:14:30 -0800 (PST) Received: from ejlp023.ejgv ([212.55.29.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MD600EPCD02RG40@ektmail1mta2.euskaltel.es> for pkix@ietf.org; Thu, 08 Nov 2012 16:14:27 +0100 (CET) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id qA8FEIN5002804; Thu, 08 Nov 2012 16:14:18 +0100 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 08 Nov 2012 16:14:26 +0100 Date: Thu, 08 Nov 2012 16:14:25 +0100 From: i-barreira@izenpe.net In-reply-to: To: stefan@aaa-sec.com, pkix@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B0615F46C@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Thread-index: Ac29uCrZA3qCIwRIRmGfT2vXko4Y/gACyHKA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> X-OriginalArrivalTime: 08 Nov 2012 15:14:26.0793 (UTC) FILETIME=[BE05B590:01CDBDC3] Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:14:33 -0000 Stefan, I think this is what the recent poll tries to do, say revoked for a non = issued certificate, and this is what will happen. As said i voted option = 1 but that does not mean that I=B4m agree with this situation because at = the end, the CA has to be revoked and for the OCSP responder knows what = certs have been issued or not, then you=B4ll need to manage a kind of a = big white list and this is not easy to implement. That=B4s it, I=B4m not = wrong whatsoever you want to call it I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Enviado el: jueves, 08 de noviembre de 2012 13:51 Para: Barreira Iglesias, I=F1igo; pkix@ietf.org Asunto: Re: [pkix] What's the need to introduce fraudulently issued = certificates in OCSP Hi, On 11/8/12 5:27 AM, "i-barreira@izenpe.net" = wrote: >This "fix" tries to avoid that someone can issue a bogus certificate=20 >and after that delete the log/registry of the issuance (This is the=20 >Diginotar case). But this "fix" wouldn=B4t help/fix much: You go wrong already here, and thus the rest goes wrong as well. This is NOT what the fix attempts to do. This is what CAB Forum attempts to do. If you think the CAB Forum deals = with this the wrong way, you should really take this up on their mailing = list. This fix (The OCSP update in PKIX) simply allows CAB forum to do what = they feel they need to do in one particular area. /Stefan From piyush@ditenity.com Thu Nov 8 08:02:35 2012 Return-Path: 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 4118821F8A60 for ; Thu, 8 Nov 2012 08:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 qsvttoeMaL7Q for ; Thu, 8 Nov 2012 08:02:34 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADCB21F8B7E for ; Thu, 8 Nov 2012 08:02:21 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so4941736iec.31 for ; Thu, 08 Nov 2012 08:02:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=Tu2KNs8+60fBHLAcW4p9IfetLA2oy7CFTeUtJtEb7uY=; b=MSF/MatcZTs5c7UGZ1MnYFs3q+o3bSjaLXclPtzpvRIcM1gztWoAIvVYz7YMOmZaAS sTIyywlIw6Rke22k8KVC5LsM22rb3Z0hXmc13gMiznQG1pktgrFOhumxYT0NzCGAwvk+ Q/yv61TvzH7aDPzsLmglM1Cd9cDR8XWq8qFNf+nL15qjHk66+LiCJk9Cj/NteI1k4W5p AFfXZD686DoRKODmU16WG89+fHBEX4XnW5K/ElCEJGtqV6JsVahEErP00ykV5Gk15OMv gnxKxV+rORe8rq/oRg6k5W/P765SHA3j8lQLksWvFYZ32UidyWEku+SuuBN+buJ7F/Bz MDWg== Received: by 10.50.156.232 with SMTP id wh8mr8639004igb.56.1352390540608; Thu, 08 Nov 2012 08:02:20 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id kp4sm5003219igc.1.2012.11.08.08.02.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:02:19 -0800 (PST) From: "Piyush Jain" To: "'Simon Tardell'" , "'Denis Pinkas'" References: <509B6DFC.8000009@bull.net> In-Reply-To: Date: Thu, 8 Nov 2012 08:02:16 -0800 Message-ID: <00d801cdbdca$6e3c2010$4ab46030$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01CDBD87.601D4CE0" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQHBfksJDS61w42CEfKL2ZLIOS7K2QEfYSOXATYQlVeX5euWMA== Content-Language: en-us X-Gm-Message-State: ALoCoQlUvdVj04b20cBKZ8rIT8NfHQ/nNE/0kzs8/c5KqZrMntlhcNvxQpb45qPKPtsnx5rjgElF Cc: pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:02:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D9_01CDBD87.601D4CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "Unknown" is part of what makes it possible to provide timely revocation information in a distributed and redundant fashion. This is a useful feature which I would like you not to break for me. Falling back to CRLs is the least useful option, but what many clients (including Windows) will do. That is a security problem, if you let "unknown" be an assertion of non-issuance. [Piyush] signature mismatch on the certificate is an assertion of non-issuance. Unknown is an assertion that revocation status is unknown. The notion that revoked/unknown is an assertion of non-issuance is a security problem. ------=_NextPart_000_00D9_01CDBD87.601D4CE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

"Unknown" is part of what makes it possible = to provide timely revocation information in a distributed and redundant = fashion. This is a useful feature which I would like you not to break = for me. Falling back to CRLs is the least useful option, but what many = clients (including Windows) will do. That is a security problem, if you = let "unknown" be an assertion of = non-issuance. 

 

[Piyush] signature mismatch on the certificate is an assertion of = non-issuance. Unknown is an assertion that revocation status is unknown. = The notion that revoked/unknown is an assertion of non-issuance is a = security problem.

------=_NextPart_000_00D9_01CDBD87.601D4CE0-- From piyush@ditenity.com Thu Nov 8 08:28:34 2012 Return-Path: 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 4AB4C21F8459 for ; Thu, 8 Nov 2012 08:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tPhS35V4Rwol for ; Thu, 8 Nov 2012 08:28:33 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9169521F8B89 for ; Thu, 8 Nov 2012 08:26:59 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so2310291iak.31 for ; Thu, 08 Nov 2012 08:26:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=IiJKdVtKMOS2IYBWBJdeu9NUPeCFgOkT0N5ppdbBmRo=; b=pM/dU8gU4VTUWrcBvFa92LUJfpgykCyZ5lSa98LhCqSGflWMwNzp3cTsLFFVp6eM7S J0n9LcjN4DWf11HqsgX972qhEb0Z+EgoJi4+F2s/YuQSe+zP3mR0JNIK/3KeTBfR8T3e nlcMDk0yA6l63eli6zzBXB6dgxw0MrZDNtzqzo8sx3i5fGkVYNhZ1jwX97d02RKfMxwv 9lubHk9ANy1owDstChn7EbBUtBA2biKZFjz0uEfnZEtoHPTSD/E7Dn+O1i3omkt1YkH9 8Dw1TV8VkK53Wzre3i8YEu64jGI6XWPwpT+7Qqu9sI2Bop+sGj5MynZ/v0MHsJbtPCWI bGbw== Received: by 10.50.213.99 with SMTP id nr3mr6104889igc.16.1352392018872; Thu, 08 Nov 2012 08:26:58 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s3sm5031205igb.14.2012.11.08.08.26.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:26:58 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , , References: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> In-Reply-To: Date: Thu, 8 Nov 2012 08:26:55 -0800 Message-ID: <00fd01cdbdcd$df954720$9ebfd560$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQJ6Ubc870fMiJvOf+zpNN87/Rk+z5aG7MaQ Content-Language: en-us X-Gm-Message-State: ALoCoQle676scbVZPTEkjf6NVUKIOd3GBRlLMw3XB847xoKEOeI1nYd1XV2vgqPfGTDUSIREqBdK Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:28:34 -0000 > >This "fix" tries to avoid that someone can issue a bogus certificate > >and after that delete the log/registry of the issuance (This is the > >Diginotar case). But this "fix" wouldn=B4t help/fix much: >=20 > You go wrong already here, and thus the rest goes wrong as well. >=20 > This is NOT what the fix attempts to do. >=20 > This is what CAB Forum attempts to do. If you think the CAB Forum = deals > with this the wrong way, you should really take this up on their = mailing list. >=20 [Piyush] If you are updating a PKIX document solely based on CAB forum's requirements, the merits of those requirements should be discussed here, = not in CAB forum. Otherwise CAB forum is free to create profile of OCSP that suits their needs. The current text in OCSP merely says that revoked is = an indication that certificate was revoked. It does not say the responders = MUST return revoked only if certificate is revoked by the CA. > This fix (The OCSP update in PKIX) simply allows CAB forum to do what = they > feel they need to do in one particular area. > [Piyush]=20 Not a reason to update a pkix document which has applications outside = the CAB community. Just because I feel that my responder should return revoked for = certificate of people who wear red shirts does not mean that PKIX should have text = in OCSP endorsing this. > /Stefan From stefan@aaa-sec.com Thu Nov 8 09:56:00 2012 Return-Path: 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 F194E21F8536 for ; Thu, 8 Nov 2012 09:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.075 X-Spam-Level: X-Spam-Status: No, score=-102.075 tagged_above=-999 required=5 tests=[AWL=0.175, 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 ZCWlqaiaZlsu for ; Thu, 8 Nov 2012 09:56:00 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3C321F852C for ; Thu, 8 Nov 2012 09:55:59 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 6384059823 for ; Thu, 8 Nov 2012 18:55:02 +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 vKJ4S7PCwHCl for ; Thu, 8 Nov 2012 18:55:00 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 18C3B59836 for ; Thu, 8 Nov 2012 18:54:59 +0100 (CET) Received: (qmail 36131 invoked from network); 8 Nov 2012 17:54:29 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Nov 2012 17:54:29 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 08 Nov 2012 12:54:10 -0400 From: Stefan Santesson To: Piyush Jain , , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <00fd01cdbdcd$df954720$9ebfd560$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:56:01 -0000 Piyush, We had a straw-poll and it clearly favoured to allow "revoked" to be returned for non-issued certs. Unless you can come up with a real issue where this creates real problems, I'm considering this issue closed. /Stefan On 11/8/12 12:26 PM, "Piyush Jain" wrote: >> >This "fix" tries to avoid that someone can issue a bogus certificate >> >and after that delete the log/registry of the issuance (This is the >> >Diginotar case). But this "fix" wouldn=B4t help/fix much: >>=20 >> You go wrong already here, and thus the rest goes wrong as well. >>=20 >> This is NOT what the fix attempts to do. >>=20 >> This is what CAB Forum attempts to do. If you think the CAB Forum deals >> with this the wrong way, you should really take this up on their mailing >list. >>=20 > >[Piyush] If you are updating a PKIX document solely based on CAB forum's >requirements, the merits of those requirements should be discussed here, >not >in CAB forum. Otherwise CAB forum is free to create profile of OCSP that >suits their needs. The current text in OCSP merely says that revoked is an >indication that certificate was revoked. It does not say the responders >MUST >return revoked only if certificate is revoked by the CA. > >> This fix (The OCSP update in PKIX) simply allows CAB forum to do what >>they >> feel they need to do in one particular area. >> >[Piyush]=20 >Not a reason to update a pkix document which has applications outside the >CAB community. >Just because I feel that my responder should return revoked for >certificate >of people who wear red shirts does not mean that PKIX should have text in >OCSP endorsing this. > >> /Stefan > From stefan@aaa-sec.com Thu Nov 8 09:59:04 2012 Return-Path: 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 E97AF21F8552 for ; Thu, 8 Nov 2012 09:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.109 X-Spam-Level: X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 T-H6F6nrmZzM for ; Thu, 8 Nov 2012 09:59:04 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2318421F8546 for ; Thu, 8 Nov 2012 09:59:04 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 431C1598E2 for ; Thu, 8 Nov 2012 18:58:12 +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 R6Hyy-FgfM3q for ; Thu, 8 Nov 2012 18:58:11 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DED4A598E0 for ; Thu, 8 Nov 2012 18:58:11 +0100 (CET) Received: (qmail 15404 invoked from network); 8 Nov 2012 17:58:11 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Nov 2012 17:58:11 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 08 Nov 2012 12:58:04 -0400 From: Stefan Santesson To: , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0615F46C@AEX06.ejsarea.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:59:05 -0000 Inigo, You are not wrong. But you don't have to manage any white list to conform with the updated OCSP spec. CAB Forum will require responders in their infrastructure to do it, so this also seems to be an issue for the CAB Forum. /Stefan On 11/8/12 11:14 AM, "i-barreira@izenpe.net" wrote: >Stefan, > >I think this is what the recent poll tries to do, say revoked for a non >issued certificate, and this is what will happen. As said i voted option >1 but that does not mean that I=B4m agree with this situation because at >the end, the CA has to be revoked and for the OCSP responder knows what >certs have been issued or not, then you=B4ll need to manage a kind of a big >white list and this is not easy to implement. That=B4s it, I=B4m not wrong >whatsoever you want to call it > > >I=F1igo Barreira >Responsable del =C1rea t=E9cnica >i-barreira@izenpe.net >945067705 > > >ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta >egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada >(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, >korreo honi erantzuna. KONTUZ! >ATENCION! Este mensaje contiene informacion privilegiada o confidencial a >la que solo tiene derecho a acceder el destinatario. Si usted lo recibe >por error le agradeceriamos que no hiciera uso de la informacion y que se >pusiese en contacto con el remitente. > > >-----Mensaje original----- >De: Stefan Santesson [mailto:stefan@aaa-sec.com] >Enviado el: jueves, 08 de noviembre de 2012 13:51 >Para: Barreira Iglesias, I=F1igo; pkix@ietf.org >Asunto: Re: [pkix] What's the need to introduce fraudulently issued >certificates in OCSP > >Hi, > >On 11/8/12 5:27 AM, "i-barreira@izenpe.net" wrote: > >>This "fix" tries to avoid that someone can issue a bogus certificate >>and after that delete the log/registry of the issuance (This is the >>Diginotar case). But this "fix" wouldn=B4t help/fix much: > >You go wrong already here, and thus the rest goes wrong as well. > >This is NOT what the fix attempts to do. > >This is what CAB Forum attempts to do. If you think the CAB Forum deals >with this the wrong way, you should really take this up on their mailing >list. > >This fix (The OCSP update in PKIX) simply allows CAB forum to do what >they feel they need to do in one particular area. > >/Stefan > > > From piyush@ditenity.com Thu Nov 8 10:32:07 2012 Return-Path: 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 A77EB21F8755 for ; Thu, 8 Nov 2012 10:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 2FR3jwO5Jr-y for ; Thu, 8 Nov 2012 10:32:07 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0A021F8201 for ; Thu, 8 Nov 2012 10:32:06 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so2417834iak.31 for ; Thu, 08 Nov 2012 10:32:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language :x-gm-message-state; bh=z3AF6/WlJqvbIK3c5UW/nEGD29/E71S2KxptyKp+wpg=; b=JxG3S6OCsihOMAjgYrmiXHvvAG/5u2kxJX9oiyKelPlVUI4EAiyE8NhQcPgg16+Sdb ktMsj1tRQjaIu31vw9C/yfNpSYNcSAKqqqNNhTNvJ9SmyIxxAJbTv2TxH7T5n+F+Vj2N Db8V0kN2XDUnGba9l9T09MaLYupcB2EoY48g5rhYXKGZzS1eT8pN6eEpPeAT0Yf6RQD2 8OQjbLPxSvaACzqKc3fJfMaQvAjMX03LglO7kHtV0lHJz4opNxYNuHv7SjQemG4DXoXB 27KpEmgaxMHw9E/6LOpVxbQTIHXoUHmfKx/DeXLF/wLY+SHnpd2OyRHd62c9tnuv6uTC lnDw== Received: by 10.50.219.233 with SMTP id pr9mr21247829igc.19.1352399526034; Thu, 08 Nov 2012 10:32:06 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id wm10sm4979991igc.2.2012.11.08.10.32.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 10:32:05 -0800 (PST) From: "Piyush Jain" To: Date: Thu, 8 Nov 2012 10:32:02 -0800 Message-ID: <013301cdbddf$5a3a9dc0$0eafd940$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: Ac293sELuLJSjmAzSIylnut4RTtVuQ== Content-Language: en-us X-Gm-Message-State: ALoCoQl9UKpy02/Kicd8Rl+0wE2gAL74tVNuhCfdu0fyBc2r6jovvmKOXB4lcDCO0H2grfH58BUZ Subject: [pkix] Making OCSP status flexible without creating a false sense of security X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:32:07 -0000 I appreciate the point that current text describing the status in OCSP is too restrictive and does not allow the responder to deal with situation where 'revoked' response seems to be a better choice than either 'good' or 'unknown' response. However, my understanding (based on a discussion with one of the original authors of OCSP long time ago) has always been that OCSP status only conveys revocation status and response extensions convey additional assertions. Many folks on this forum believe that negative assertion should be conveyed as a revoked status, primarily because millions of clients don't handle unknown correctly and consider 'good' to be more than 'not revoked'. While I do not believe that accommodating clients who do not follow the standard correctly, is a reason to change the standard, I believe that current text describing the revoked status is rigid. There is a way to address this without endorsing the method adopted by CAB forum to deal with compromised CAs, which IMO is inherently insecure. This is the text from last version of the draft 6: "The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)). This state SHOULD also be returned if the responder knows that the requested certificate has never been issued. Note that the receiver of a response may have to consult out-of-band knowledge, or information in an extension defined outside of this standard, to know whether a particular responder has knowledge about whether a requested certificate has been issued or not and whether it responds "good" or "revoked" to a status request for a non-issued certificate." While the above proposal attempts to provide flexibility in terms of what responder can return, it also introduces "non-issued" which is confusing given that until now signatures have been considered proof of issuance. Also, it just addresses one case of negative assertions. There may be other scenarios where a negative assertion is required. So if this forum is inclined to change the semantics of 'revoked' from indicating just the revocation status to indicating any negative assertion, the above proposal becomes limiting. Here is an alternative text that attempts to address these limitations, assuming that WG is inclined toward changing the meaning of revoked: "The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). This state MAY also be returned to indicate that the certificate should not be trusted by the relying party, even if it is not explicitly revoked by the CA". How the responder makes this determination is beyond the scope of this document." I believe that this alternative text allows flexibility to CAB forum without creating the impression that OCSP can be an alternative to signature checking. It puts the onus on CAB forum to explain the security (or lack thereof) of their adopted methods. Also, it allows implementations to use revoked for any negative assertion instead of limiting its use for just one kind of 'bad' certificate. Off course, we'll still need to provide guidance on what the revocationReason and revocationTime values should be in such cases. -Piyush From stefan@aaa-sec.com Thu Nov 8 16:54:51 2012 Return-Path: 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 07AED21F8AF2 for ; Thu, 8 Nov 2012 16:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 qIi2qRyBdTDE for ; Thu, 8 Nov 2012 16:54:50 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5C32221F8A84 for ; Thu, 8 Nov 2012 16:54:49 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id CB7E55A8A8 for ; Fri, 9 Nov 2012 01:54:26 +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 zQ-qI85gMbCH for ; Fri, 9 Nov 2012 01:54:26 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 9D7EC5A889 for ; Fri, 9 Nov 2012 01:54:26 +0100 (CET) Received: (qmail 5659 invoked from network); 9 Nov 2012 00:54:26 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Nov 2012 00:54:26 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 08 Nov 2012 19:54:21 -0400 From: Stefan Santesson To: Message-ID: Thread-Topic: Minutes from the PKIX meeting posted In-Reply-To: <013301cdbddf$5a3a9dc0$0eafd940$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] Minutes from the PKIX meeting posted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 00:54:51 -0000 The Minutes from the PKIX meeting in Atlanta are posted. http://www.ietf.org/proceedings/85/minutes/minutes-85-pkix Please let me know if something is wrong or missing. /Stefan From stefan@aaa-sec.com Thu Nov 8 17:00:00 2012 Return-Path: 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 88EB621F85CD for ; Thu, 8 Nov 2012 17:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_MEN=2.3, 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 5kR0GBBit6cf for ; Thu, 8 Nov 2012 17:00:00 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A629D21F8531 for ; Thu, 8 Nov 2012 16:59:59 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id E46805AB08 for ; Fri, 9 Nov 2012 01:58:24 +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 X7drG7HxkSsN for ; Fri, 9 Nov 2012 01:58:24 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 799C45A808 for ; Fri, 9 Nov 2012 01:58:24 +0100 (CET) Received: (qmail 24779 invoked from network); 9 Nov 2012 00:58:23 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Nov 2012 00:58:23 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 08 Nov 2012 19:58:17 -0400 From: Stefan Santesson To: , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 01:00:00 -0000 I think this is a very valid post for the CAB forum. In their context this is only a piece of the puzzle. I'm sure they will be able to respond to how this is a legitimate part of their strategy where they have other things in place that provides a more complete picture. The current update has never been proposed as a complete solution. /Stefan On 11/8/12 5:27 AM, "i-barreira@izenpe.net" wrote: >Hi all, > >In the recent Straw poll after saying that this is not a way to fix it >and choose option 1 as the lesser evil, I=B4d like to clarify my "proposal" >and let you know that from a point of view of a PKI software company that >wants to implement this solution, it=B4s not easy and in fact will not fix >anything. So here it goes > >This "fix" tries to avoid that someone can issue a bogus certificate and >after that delete the log/registry of the issuance (This is the Diginotar >case). But this "fix" wouldn=B4t help/fix much: > >- if a bogus certificate has been issued, it means that the CA key has >been compromised so that CA has to be removed/deleted/destroyed. >But >- as I=B4m an evil hacker that get access to the CA, I can create the bogus >certificate without AIA >- as I=B4m en evil hacket that get access to the CA, I can create the bogus >certificate without AIA and with CDP pointing to legitimate CRLs >- as I=B4m en evil hacket that get access to the CA, I can create the bogus >certificate with an AIA that points to an OCSP responder that I >control/manage >- as I=B4m en evil hacket that get access to the CA, I can create the bogus >certificate with a serial number of a valid certificate > >So, all third parties systems that use CRLs instead of OCSP to validate >certs, will consider this bogus cert as valid > >In summary, the VA has to manage, somehow, a kind of a white list that >can grow to the infinite. This VA has to "ask this list" every time an >OCSP responder is generated and has to update practically at the same >time than the issuance of the certificate. >But the key question is that once this evil hacker has done "his job", >the only fix is to revoke the complete CA. It=B4s useless that the OCSP >responder gives a "revoked" for unknown certificates because the browsers >for example could be asking the bogus OCSP (the one controlled by the >hacker) or asking for a serial number of the bogus certificate which is >identical to a legitimate one. > >I know that we all know this situation so maybe this is useless, not easy >to implement for sure and with very limited good results. > >Regards > >I=F1igo Barreira >Responsable del =C1rea t=E9cnica >i-barreira@izenpe.net >945067705 > > >ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta >egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada >(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, >korreo honi erantzuna. KONTUZ! >ATENCION! Este mensaje contiene informacion privilegiada o confidencial a >la que solo tiene derecho a acceder el destinatario. Si usted lo recibe >por error le agradeceriamos que no hiciera uso de la informacion y que se >pusiese en contacto con el remitente. > >-----Mensaje original----- >De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de >Stefan Santesson >Enviado el: mi=E9rcoles, 07 de noviembre de 2012 14:39 >Para: pkix@ietf.org >Asunto: Re: [pkix] What's the need to introduce fraudulently issued >certificates in OCSP > >I would suggest that what we are trying to do with OCSP in this update is >NOT to fix problems with compromised CAs. > >We are simply allowing responders to provide a more >accurate/functional/safer response in case of a status request for a >non-issued cert. > >As said before, the current proposal: >- Breaks on-one >- Does not add ambiguity for responses to issued certs from good CAs >- Does not add ambiguity in any case for those understanding the new >extension. >- Allows CAB Forum responders to be compliant with OCSP. > >Problems raised are purely philosophical. Not ONE practical real >issue/problem has been presented. >If I missed one, please let me know. > >/Stefan > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Fri Nov 9 00:25:00 2012 Return-Path: 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 5A9D721F8B9F for ; Fri, 9 Nov 2012 00:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 jKt-IhFcTipg for ; Fri, 9 Nov 2012 00:24:59 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 376E621F8B9C for ; Fri, 9 Nov 2012 00:24:59 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id BAABF1C7AA; Fri, 9 Nov 2012 09:24:57 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012110909245725-896 ; Fri, 9 Nov 2012 09:24:57 +0100 Message-ID: <509CBDDA.3000001@bull.net> Date: Fri, 09 Nov 2012 09:24:58 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 09:24:57, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 09:24:57, Serialize complete at 09/11/2012 09:24:57 X-TNEFEvaluated: 1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:25:00 -0000 Stefan, > So you can't use this option for French CAs that needs to conform to th= is > legislation. Correct. :-( In the PKIX minutes I also read: "Scott expressed concern about the certificateHold status since CAB Forum may hare requirements to never use certificateHold status when revoking certificates". > If the OCSP update says SHOULD set certificateHold, then you can set > something else for those CAs (if that is what you want). > Would that help? Not really. None of the currently defined secondary statuses seems to be=20 appropriate unless using "unspecified" (0). So why not using unspecified ? Denis > /Stefan > > > On 11/8/12 4:31 AM, "Denis Pinkas" wrote: > >> Stefan, >> >> There are two problems with the current proposal: >> >> 1) In France, currently, the technical specifications which are mandat= ed >> by the French legislation forbid the use of the suspension state: >> >> IV.9.13. Causes possibles d=B9une suspension >> La suspension de certificats n'est pas autoris=E9e dans la pr=E9sente = PC Type. >> >> Sources: >> >> a) Annexe A8 au RGSv1.0 : PC Type - Signature. Identification du >> document (OID) 1.2.250.1.137.2.2.1.2.2.2 2.3 >> date 11/02/2010 Page 41/82 >> >> b) Annexe A7 au RGSv1.0 : PC Type - Authentification. Identification d= u >> document (OID) 1.2.250.1.137.2.2.1.2.2.1 2.3 >> Date 11/02/2010 Page 42/82 >> >> So requiring the support of the suspension state would either : >> >> a - prevent the CAs and OCSP responders which comply with that >> legislation to take advantage of the indication >> of a certificate that is not in the database of issued certificates an= d >> currently within their validity period, or >> >> b - mandate a change in the specification which will only be applicabl= e >> in the future. >> . >> 2=B0 For CAS which do not comply with that French legislation, and for >> certificates used for non repudiation purposes, >> when an electronic signature is verified, if a certificate is suspende= d, >> then the current logic is to consider that >> the status of the electronic signature is unknown but if it is possibl= e >> to make a final decision later on, another test >> will be done later on, since the suspension state (in the usual case) = is >> not going to last for ever. >> >> Since the proposal is deviating from the original meaning of the >> suspension state, we would be in a case where >> the suspension state would last for ever. So the verifying application= s >> will keep continue to wait for the end of the >> suspended state and that end will never happen. I do not believe that >> this is nice. >> >> Returning the unknown status is still the better choice in the case >> where a certificate that is not in the database >> of issued certificates and currently within their validity period. >> >> Remember that is is a major difference between an unknown status >> returned by an authoritative OCSP responder and >> an unknown status returned by an OCSP responder that is not >> authoritative. In the former case, the relying party >> has no reason to switch to a CRL issuer (if it ever exist) , since the >> OCSP responder is authoritative and did said "unknown". >> >> IMO, changing the semantics of "suspended" is not acceptable. >> >> Denis >> >> PS. A reply to Simon who said: " I want to prevent CAs from using >> "unknown" to indicate non-issuance"; >> This sentence is not appropriate. CAs do not return certificate status= es >> unless they act as CRL issuers >> or OCSP responders. Your main argument against the use of the unknown >> status is the use of CRLs as a >> fall back mechanism. At this time, nobody said on the list under which >> exact circumstances that fall back >> mechanism is being used in some code. Is it when there is no response > >from the OCSP responder >> (in such a case, all solutions are equivalent) or under other >> circumstances (which would need to be detailed) ? >> >>> I would suggest that what we are trying to do with OCSP in this updat= e >>> is >>> NOT to fix problems with compromised CAs. >>> >>> We are simply allowing responders to provide a more >>> accurate/functional/safer response in case of a status request for a >>> non-issued cert. >>> >>> As said before, the current proposal: >>> - Breaks on-one >>> - Does not add ambiguity for responses to issued certs from good CAs >>> - Does not add ambiguity in any case for those understanding the new >>> extension. >>> - Allows CAB Forum responders to be compliant with OCSP. >>> >>> Problems raised are purely philosophical. Not ONE practical real >>> issue/problem has been presented. >>> If I missed one, please let me know. >>> >>> /Stefan >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Fri Nov 9 00:26:03 2012 Return-Path: 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 197C321F844C for ; Fri, 9 Nov 2012 00:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.789 X-Spam-Level: X-Spam-Status: No, score=-4.789 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MANGLED_MEN=2.3, RCVD_IN_DNSWL_MED=-4] 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 kbKn5WeisXeT for ; Fri, 9 Nov 2012 00:26:02 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 570DF21F8442 for ; Fri, 9 Nov 2012 00:25:59 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id C63BC1C753 for ; Fri, 9 Nov 2012 09:25:58 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012110909255810-898 ; Fri, 9 Nov 2012 09:25:58 +0100 Message-ID: <509CBE17.8090104@bull.net> Date: Fri, 09 Nov 2012 09:25:59 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 09:25:58, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 09:25:58, Serialize complete at 09/11/2012 09:25:58 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------050402090708040109070607" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:26:03 -0000 This is a multi-part message in MIME format. --------------050402090708040109070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I=F1igo, There are two goals: The first goal is to allow an OCSP client to *detect* an abnormal=20 situation and to alert the OCSP server. This is only a *detection* mechanism which may be=20 followed by a *recovery* mechanism. This is not a *prevention* mechanism. draft-pinkas-2560bis-certinfo-00.txt includes a text about security=20 considerations which provides more details. For convenience, it is copied below: " When an OCSP server receives an alert from an OCSP client, it shoul= d use the information provided by the OCSP client to investigate the case. If the target certificate is unknown to the OCSP server, but has been regularly issued, it is necessary to discriminate between a denial of service attack or an accident and to correct the problem so that the situation does not persist. If the target certificate has not been regularly issued, its serial number should be immediately added by the CA to the list of revoked certificates. Then after, the OCSP server should continue to investigate the case: - either the extend of the damage can be evaluated by the CA and only those certificates which have been fraudulently issued shall be revoked by the CA, or - the extend of damage cannot be evaluated and in that case the CA should ask to its superior CA to revoke its CA certificate. It is up to the CA and to the OCSP server to cooperate together in order to attempt to recover from these situations. OCSP servers and CAs should include in their recovery plans, the above situations". The second goal is to avoid to return the "good" revocation status when t= he OCSP responder has access to a database of issued (and currently valid) certificates and when it knows that the serial number is not in the=20 database. Denis > Hi all, > > In the recent Straw poll after saying that this is not a way to fix it = and choose option 1 as the lesser evil, I=B4d like to clarify my "proposa= l" and let you know that from a point of view of a PKI software company t= hat wants to implement this solution, it=B4s not easy and in fact will no= t fix anything. So here it goes > > This "fix" tries to avoid that someone can issue a bogus certificate an= d after that delete the log/registry of the issuance (This is the Diginot= ar case). But this "fix" wouldn=B4t help/fix much: > > - if a bogus certificate has been issued, it means that the CA key has = been compromised so that CA has to be removed/deleted/destroyed. > But > - as I=B4m an evil hacker that get access to the CA, I can create the b= ogus certificate without AIA > - as I=B4m en evil hacket that get access to the CA, I can create the b= ogus certificate without AIA and with CDP pointing to legitimate CRLs > - as I=B4m en evil hacket that get access to the CA, I can create the b= ogus certificate with an AIA that points to an OCSP responder that I cont= rol/manage > - as I=B4m en evil hacket that get access to the CA, I can create the b= ogus certificate with a serial number of a valid certificate > > So, all third parties systems that use CRLs instead of OCSP to validate= certs, will consider this bogus cert as valid > > In summary, the VA has to manage, somehow, a kind of a white list that = can grow to the infinite. This VA has to "ask this list" every time an OC= SP responder is generated and has to update practically at the same time = than the issuance of the certificate. > But the key question is that once this evil hacker has done "his job", = the only fix is to revoke the complete CA. It=B4s useless that the OCSP r= esponder gives a "revoked" for unknown certificates because the browsers = for example could be asking the bogus OCSP (the one controlled by the hac= ker) or asking for a serial number of the bogus certificate which is iden= tical to a legitimate one. > > I know that we all know this situation so maybe this is useless, not ea= sy to implement for sure and with very limited good results. > > Regards > > I=F1igo Barreira > Responsable del =C1rea t=E9cnica > i-barreira@izenpe.net > 945067705 > > > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta ego= tea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea = gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi = erantzuna. KONTUZ! > ATENCION! Este mensaje contiene informacion privilegiada o confidencial= a la que solo tiene derecho a acceder el destinatario. Si usted lo recib= e por error le agradeceriamos que no hiciera uso de la informacion y que = se pusiese en contacto con el remitente. > > -----Mensaje original----- > De:pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de S= tefan Santesson > Enviado el: mi=E9rcoles, 07 de noviembre de 2012 14:39 > Para:pkix@ietf.org > Asunto: Re: [pkix] What's the need to introduce fraudulently issued cer= tificates in OCSP > > I would suggest that what we are trying to do with OCSP in this update = is NOT to fix problems with compromised CAs. > > We are simply allowing responders to provide a more accurate/functional= /safer response in case of a status request for a non-issued cert. > > As said before, the current proposal: > - Breaks on-one > - Does not add ambiguity for responses to issued certs from good CAs > - Does not add ambiguity in any case for those understanding the new ex= tension. > - Allows CAB Forum responders to be compliant with OCSP. > > Problems raised are purely philosophical. Not ONE practical real issue/= problem has been presented. > If I missed one, please let me know. > > /Stefan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------050402090708040109070607 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Iñigo,

There are two goals:

The first goal is to allow an OCSP client to *detect* an abnormal situation and to alert
the OCSP server. This is only a *detection* mechanism which may be followed by a
*recovery* mechanism. This is not a *prevention* mechanism.

draft-pinkas-2560bis-certinfo-00.txt includes a text about security considerations which
provides more details. For convenience, it is copied below:
 
   " When an OCSP server receives an alert from an OCSP client, it should
   use the information provided by the OCSP client to investigate the
   case.

   If the target certificate is unknown to the OCSP server, but has
   been regularly issued, it is necessary to discriminate between a
   denial of service attack or an accident and to correct the problem
   so that the situation does not persist.

   If the target certificate has not been regularly issued, its serial
   number should be immediately added by the CA to the list of revoked
   certificates.

   Then after, the OCSP server should continue to investigate the case:

     - either the extend of the damage can be evaluated by the CA and
       only those certificates which have been fraudulently issued
       shall be revoked by the CA, or

     - the extend of damage cannot be evaluated and in that case the CA
       should ask to its superior CA to revoke its CA certificate.

   It is up to the CA and to the OCSP server to cooperate together in
   order to attempt to recover from these situations.  OCSP servers and
   CAs should include in their recovery plans, the above situations".

The second goal is to avoid to return the "good" revocation status when the
OCSP responder has access to a database of issued (and currently valid)
certificates and when it knows that the serial number is not in the database.

Denis

Hi all,

In the recent Straw poll after saying that this is not a way to fix it and choose option 1 as the lesser evil, I´d like to clarify my "proposal" and let you know that from a point of view of a PKI software company that wants to implement this solution, it´s not easy and in fact will not fix anything. So here it goes

This "fix" tries to avoid that someone can issue a bogus certificate and after that delete the log/registry of the issuance (This is the Diginotar case). But this "fix" wouldn´t help/fix much:

- if a bogus certificate has been issued, it means that the CA key has been compromised so that CA has to be removed/deleted/destroyed.
But
- as I´m an evil hacker that get access to the CA, I can create the bogus certificate without AIA
- as I´m en evil hacket that get access to the CA, I can create the bogus certificate without AIA and with CDP pointing to legitimate CRLs
- as I´m en evil hacket that get access to the CA, I can create the bogus certificate with an AIA that points to an OCSP responder that I control/manage
- as I´m en evil hacket that get access to the CA, I can create the bogus certificate with a serial number of a valid certificate

So, all third parties systems that use CRLs instead of OCSP to validate certs, will consider this bogus cert as valid

In summary, the VA has to manage, somehow, a kind of a white list that can grow to the infinite. This VA has to "ask this list" every time an OCSP responder is generated and has to update practically at the same time than the issuance of the certificate.
But the key question is that once this evil hacker has done "his job", the only fix is to revoke the complete CA. It´s useless that the OCSP responder gives a "revoked" for unknown certificates because the browsers for example could be asking the bogus OCSP (the one controlled by the hacker) or asking for a serial number of the bogus certificate which is identical to a legitimate one.

I know that we all know this situation so maybe this is useless, not easy to implement for sure and with very limited good results.

Regards

Iñigo Barreira
Responsable del Área técnica
i-barreira@izenpe.net
945067705


ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

-----Mensaje original-----
De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de Stefan Santesson
Enviado el: miércoles, 07 de noviembre de 2012 14:39
Para: pkix@ietf.org
Asunto: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

I would suggest that what we are trying to do with OCSP in this update is NOT to fix problems with compromised CAs.

We are simply allowing responders to provide a more accurate/functional/safer response in case of a status request for a non-issued cert.

As said before, the current proposal:
- Breaks on-one
- Does not add ambiguity for responses to issued certs from good CAs
- Does not add ambiguity in any case for those understanding the new extension.
- Allows CAB Forum responders to be compliant with OCSP.

Problems raised are purely philosophical. Not ONE practical real issue/problem has been presented.
If I missed one, please let me know.

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix


--------------050402090708040109070607-- From denis.pinkas@bull.net Fri Nov 9 00:30:52 2012 Return-Path: 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 39C2021F8200 for ; Fri, 9 Nov 2012 00:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 AVrqfkqgdbaF for ; Fri, 9 Nov 2012 00:30:51 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id ED64B21F8436 for ; Fri, 9 Nov 2012 00:30:49 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id D0D4D1C7AA for ; Fri, 9 Nov 2012 09:30:45 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012110909304542-900 ; Fri, 9 Nov 2012 09:30:45 +0100 Message-ID: <509CBF36.1060000@bull.net> Date: Fri, 09 Nov 2012 09:30:46 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 09:30:45, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 09:30:45, Serialize complete at 09/11/2012 09:30:45 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------050202050801090708020901" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:30:52 -0000 This is a multi-part message in MIME format. --------------050202050801090708020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stefan, As responded to I=F1igo, what we are trying to do with OCSP in this updat= e=20 is *not only* "to provide a more accurate/functional/safer response in case of a status request=20 for a non-issued cert". BTW, using the terminology "non-issued cert" is restrictive, since two=20 cases may happen: - either the target certificate has indeed not been issued and=20 thus is a forged certificate, - or the target certificate which was indeed regularly issued has=20 been removed from the database by an attacker (as the result of a denial of service attack)=20 or by accident. So the primary revocation status would need to reflect both cases as=20 detailed above. The second aspect, which is equally important, is to allow an OCSP=20 client to *detect* an abnormal situation and to alert the OCSP server to fix it. This is only a *detection*=20 mechanism, which needs to be followed by a *recovery* mechanism. > I would suggest that what we are trying to do with OCSP in this update = is > NOT to fix problems with compromised CAs. > > We are simply allowing responders to provide a more > accurate/functional/safer response in case of a status request for a > non-issued cert. > > As said before, the current proposal: > - Breaks on-one 1) Not really: it would prevent CAs which need to comply with the=20 French legislation from taking advantage of the new feature. 2) it seems to be a problem for the CAB forum as well: "Scott expressed concern about the certificateHold status since CAB Forum may hare requirements to never use certificateHold status when revoking certificates". 2) It breaks the logic of some relying parties which verify=20 electronic signatures: they will wait for end of the suspension state, or a time out which does not exist today would need to be added. So, why=20 not using "unspecified" ? > - Does not add ambiguity for responses to issued certs from good CAs This is not a matter of "good" or "bad" CA, until an abnormal situation=20 is detected by the OCSP client > - Does not add ambiguity in any case for those understanding the new ex= tension. This is not a new extension, but a change in the semantics of the=20 "revoked" status and that may have further implications on its processing. > - Allows CAB Forum responders to be compliant with OCSP. Well, could someone post the requirements terms of the CAB forum, so we=20 can know what they really are ? > Problems raised are purely philosophical. Not ONE practical real > issue/problem has been presented. > If I missed one, please let me know. See above. Denis > /Stefan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------050202050801090708020901 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

As responded to Iñigo, what we are trying to do with OCSP in this update is *not only* "to provide
a more accurate/functional/safer response in case of a status request for a non-issued cert".

BTW, using the terminology "non-issued cert" is restrictive, since two cases may happen:

      - either the target certificate has indeed not been issued and thus is a forged certificate,

      - or the target certificate which was indeed regularly issued has been removed from the database
         by an attacker (as the result of a denial of service attack) or by accident.

So the primary revocation status would need to reflect both cases as detailed above.

The second aspect, which is equally important, is to allow an OCSP client to *detect* an abnormal situation
and to alert the OCSP server to fix it. This is only a *detection* mechanism, which needs to be followed by
a *recovery* mechanism. 

I would suggest that what we are trying to do with OCSP in this update is
NOT to fix problems with compromised CAs.

We are simply allowing responders to provide a more
accurate/functional/safer response in case of a status request for a
non-issued cert.

As said before, the current proposal:
- Breaks on-one
  1) Not really:  it would prevent CAs which need to comply with the French legislation from taking advantage of the new feature.

  2) it seems to be a problem for the CAB forum as well:

"Scott expressed concern about the certificateHold status since CAB
Forum may hare requirements to never use certificateHold status
when revoking certificates".


  2) It breaks the logic of some relying parties which verify electronic signatures: they will wait for end of the suspension state,
or a time out which does not exist today would need to be added. So, why not using "unspecified" ?

 
- Does not add ambiguity for responses to issued certs from good CAs

This is not a matter of "good" or "bad" CA, until an abnormal situation is detected by the OCSP client 

- Does not add ambiguity in any case for those understanding the new extension.

This is not a new extension, but a change in the semantics of the "revoked" status and that may have further implications
on its processing.

- Allows CAB Forum responders to be compliant with OCSP.

Well, could someone post the requirements terms of the CAB forum, so we can know what they really are  ?
Problems raised are purely philosophical. Not ONE practical real
issue/problem has been presented.
If I missed one, please let me know.

See above.

Denis

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix


--------------050202050801090708020901-- From simon@tardell.se Fri Nov 9 01:17:54 2012 Return-Path: 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 E3B5821F843F for ; Fri, 9 Nov 2012 01:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 6ccboIqLRbLb for ; Fri, 9 Nov 2012 01:17:53 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78ACE21F84C2 for ; Fri, 9 Nov 2012 01:17:52 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so2719411qca.31 for ; Fri, 09 Nov 2012 01:17:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+yg+A396oh37VBN7sGE7cCcTXOtxB3+x6QlVFpP8iDA=; b=fqlsh6kJQVGnLpaSgodgTvjIYNyF3Xn0u1/Pbh9iu6JeX/cEP5LEnm2zVwmwKSQfda vI3H2vSFwUzVz/xyx4Lqubbt2OPsJls1cmQJBRlTGYJF6aS25R0C3YEChlzecFOIRt8z fHlFI8KPio95NEdMxACo0tYU8R7sTyChDxJ5ZyqEmy+oqgu8r7l62RcEX1jq/neOGGAX iEdi/lajvSN80DXj4L9sURIUKh4fkEge6weF2Zul578FpoKCu1YSlb/dwz9WSInH69i8 wKiKBbw7pr9u7mg0Uqfczb+w0XmMrTlOG7C5ePJGE2PyK3sWjMz+j5u0lofh62leA6sg 5Eqg== MIME-Version: 1.0 Received: by 10.49.72.1 with SMTP id z1mr18995259qeu.2.1352452671641; Fri, 09 Nov 2012 01:17:51 -0800 (PST) Received: by 10.49.94.116 with HTTP; Fri, 9 Nov 2012 01:17:51 -0800 (PST) In-Reply-To: <509CBF36.1060000@bull.net> References: <509CBF36.1060000@bull.net> Date: Fri, 9 Nov 2012 10:17:51 +0100 Message-ID: From: Simon Tardell To: Denis Pinkas Content-Type: multipart/alternative; boundary=047d7b6da0c411977204ce0c6d84 X-Gm-Message-State: ALoCoQnvi9MWvICaTCRSfvqoTeUkB2lOrPCjMf86bqICIPJzHOv4ASpt/DF4EQpRj/pgNObnP/gG Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 09:17:54 -0000 --047d7b6da0c411977204ce0c6d84 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 9, 2012 at 9:30 AM, Denis Pinkas wrote: > As said before, the current proposal: > - Breaks on-one > > 1) Not really: it would prevent CAs which need to comply with the > French legislation from taking advantage of the new feature. > As I noted earlier I don't read it that way. The text is about what you can do to a *certificate*. You can't *suspend a certificate*. But the proposed text is about responding certificateHold for *anything but a certificate*. > 2) it seems to be a problem for the CAB forum as well: > > > "Scott expressed concern about the certificateHold status since CAB > Forum may hare requirements to never use certificateHold status > when revoking certificates". > Well, that's easier to solve. It is not a practical problem, for the very same reason (actual certificates will never be on hold, so they will only have one continuous validity period, which is the simplification I believe they are after). And CAB Forum is perhaps easier to reason with than a French ministry (given my prejudice about the napoleonic system of government ;)-. 2) It breaks the logic of some relying parties which verify electronic > signatures: they will wait for end of the suspension state, > or a time out which does not exist today would need to be added. > That logic is clearly against the specification, so why should we accommodate it? Perhaps we need some clarifying language somewhere else to prevent this practice from proliferating. > So, why not using "unspecified" ? > Because it is still definite. A serial number which is not issued today may be issued tomorrow. So you have to use a reason code that carries with it that it is valid _now_ but may change the next time you ask. > This is not a new extension, but a change in the semantics of the > "revoked" status and that may have further implications > on its processing. > I don't agree here. It does not change anything for clients that are already complying with relevant PKIX standards. The only parties that *may* need to change something are OCSP responders, and that's only if they want to take advantage of this functionality. /Simon --047d7b6da0c411977204ce0c6d84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, N= ov 9, 2012 at 9:30 AM, Denis Pinkas <denis.pinkas@bull.net> wrote:
=20 =20 =20 
As said before, the cu=
rrent proposal:
- Breaks on-one
=A0 1) Not really:=A0 it would prevent CAs which need to comply with th= e French legislation from taking advantage of the new feature.
<= /blockquote>

As I noted earlier I don't read it that= way. The text is about what you can do to a certificate. You can= 9;t suspend a certificate. But the proposed text is about responding= certificateHold for anything but a certificate.=A0
=A0
=A0 2) it seems to be a problem for the CAB forum as well:


"Scott expressed concern about the certificateHold status since CA= B
Forum may hare requirements to never use certificateHold status
when revoking certificates".

=
Well, that's easier to solve. It is not a practical problem,= for the very same reason (actual certificates will never be on hold, so th= ey will only have one continuous validity period, which is the simplificati= on I believe they are after). And CAB Forum is perhaps easier to reason wit= h than a French ministry (given my prejudice about the napoleonic system of= government ;)-.

=A0 2) It breaks the logic of some relying parties which verify electronic signatures: they will wait for end of the suspension state,
or a time out which does not exist today would need to be added.
=

That logic is clearly against the specific= ation, so why should we accommodate it? Perhaps we need some clarifying lan= guage somewhere else to prevent this practice from proliferating.
=A0
So, why not using "unspecified" ?

Because it is still definite. A serial number which is not issued to= day may be issued tomorrow. So you have to use a reason code that carries w= ith it that it is valid _now_ but may change the next time you ask.
=A0
This is not a new extension, but a change in the semantics of = the "revoked" status and that may have further implications
on its processing.

I don't ag= ree here. It does not change anything for clients that are already complyin= g with relevant PKIX standards. The only parties that *may* need to change = something are OCSP responders, and that's only if they want to take adv= antage of this functionality.
=A0
/Simon
--047d7b6da0c411977204ce0c6d84-- From denis.pinkas@bull.net Fri Nov 9 03:22:18 2012 Return-Path: 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 2E4C221F8605 for ; Fri, 9 Nov 2012 03:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 7IZihPVwXhAI for ; Fri, 9 Nov 2012 03:22:14 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC521F8587 for ; Fri, 9 Nov 2012 03:22:14 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 3F4351CC4C; Fri, 9 Nov 2012 12:22:13 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012110912221209-928 ; Fri, 9 Nov 2012 12:22:12 +0100 Message-ID: <509CE760.4000902@bull.net> Date: Fri, 09 Nov 2012 12:22:08 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Simon Tardell References: <509CBF36.1060000@bull.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 12:22:12, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/11/2012 12:22:13, Serialize complete at 09/11/2012 12:22:13 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------020202090309050205030800" Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:22:18 -0000 This is a multi-part message in MIME format. --------------020202090309050205030800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Simon, Thank you for your detailed response. [Denis] So, why not using "unspecified" ? [Simon] Because it is still definite. A serial number which is not=20 *issued* today may be issued tomorrow. So you have to use a reason code that carries with it that it is valid=20 _now_ but may change the next time you ask. Reading again your sentence twice, I know understand. You mean that a=20 serial number which is not yet *used* today, m ight be used tomorrow for a newly issued certificate and since=20 "unspecified" is a definite response, its status cannot be changed later on to "good". (...) [Simon] We are not proposing suspending any certificates, only=20 non-certificates. (Note that it does /not/ say that an OCSP responder must not respond with reason code certificate=20 hold, it says /certificates/ must not be put on hold, or equivalently that the validity period of the certificate=20 must be continuous.) Well, I don't know your skills in French, but mine are rather good. :-) When you have the sentence: "La suspension de certificats n'est pas=20 autoris=E9e dans la pr=E9sente PC Type ", an auditor verifying the compliance of the CA would not expect when=20 asking for tests to receive a response which says that the certificate is revoked with one of the=20 ReasonFlagsset to "certificateHold". The advantage of using "unknown" is that there is no need to give any=20 revocation reason and any revocation date (however a new non-critical extension may be added to provide more=20 details for those able to understand it). The current definition from RFC 2560 is: The "unknown" state indicates that the responder doesn't know about the=20 certificate being requested. You said: "Responding "unknown" means " I am not authoritative for this=20 issuer, at least not right now." This is not what the sentence states above. This is your interpretation. You also said: "The only difference in your authoritative and=20 non-authoritative case is whether there is any one else to ask". No. The difference is that you know that the responder is authoritative=20 only if response for that serial number is signed either by the right CA and the right key or by an OCSP Responder which=20 received an OCSP certificate from the right CA and the right key. You said: An authoritative responder is probably less likely to respond=20 "unknown", but could have outages too. So this demonstrates that your interpretation above of the unknown=20 status is too restrictive. An "unknown" response from an authoritative authority is a response at=20 the time of the request: it might be that there is temporarily no access to the data base or that there is temporarily no access to the=20 CRLs. So it is not a definitive response. If there is another OCSP server, it may be tried, but switching to CRLs=20 as a backup mechanism is a matter of local policy, since there may be an associated risk. Which local policy should be used=20 is outside the definition of the protocol and may only be discussed in the security considerations section. If some implementations use as a local policy to switch to CRLs when an=20 authoritative OCSP responder responds "unknown", it is not a problem that we should attempt to solve. The solution is to=20 change the local policy in these implementations. Nota: If a non-authoritative OCSP responder responds "unknown", this=20 simply means that the request was addressed to the wrong OCSP server. Denis : > > On Fri, Nov 9, 2012 at 9:30 AM, Denis Pinkas > wrote: > >> As said before, the current proposal: >> - Breaks on-one > 1) Not really: it would prevent CAs which need to comply with > the French legislation from taking advantage of the new feature. > > > As I noted earlier I don't read it that way. The text is about what=20 > you can do to a /certificate/. You can't /suspend a certificate/. But=20 > the proposed text is about responding certificateHold for /anything=20 > but a certificate/. > > 2) it seems to be a problem for the CAB forum as well: > > > "Scott expressed concern about the certificateHold status since CAB > Forum may hare requirements to never use certificateHold status > when revoking certificates". > > > Well, that's easier to solve. It is not a practical problem, for the=20 > very same reason (actual certificates will never be on hold, so they=20 > will only have one continuous validity period, which is the=20 > simplification I believe they are after). And CAB Forum is perhaps=20 > easier to reason with than a French ministry (given my prejudice about=20 > the napoleonic system of government ;)-. > > 2) It breaks the logic of some relying parties which verify > electronic signatures: they will wait for end of the suspension > state, > or a time out which does not exist today would need to be added. > > > That logic is clearly against the specification, so why should we=20 > accommodate it? Perhaps we need some clarifying language somewhere=20 > else to prevent this practice from proliferating. > > So, why not using "unspecified" ? > > > Because it is still definite. A serial number which is not issued=20 > today may be issued tomorrow. So you have to use a reason code that=20 > carries with it that it is valid _now_ but may change the next time=20 > you ask. > > This is not a new extension, but a change in the semantics of the > "revoked" status and that may have further implications > on its processing. > > > I don't agree here. It does not change anything for clients that are=20 > already complying with relevant PKIX standards. The only parties that=20 > *may* need to change something are OCSP responders, and that's only if=20 > they want to take advantage of this functionality. > /Simon --------------020202090309050205030800 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Simon,

Thank you for your detailed response.

[Denis] So, why not using "unspecified" ?

 

[Simon] Because it is still definite. A serial number which is not *issued* today may be issued tomorrow.
So you have to use a reason code that carries with it that it is valid _now_ but may change the next time you ask.

 

Reading again your sentence twice, I know understand. You mean that a serial number which is not yet *used* today, m
ight be used tomorrow for a newly issued certificate and since “unspecified” is a definite response, its status cannot
be changed later on to “good”.

 

(…)

 

[Simon] We are not proposing suspending any certificates, only non-certificates. (Note that it does not say
that an OCSP responder must not respond with reason code certificate hold, it says certificates must not be
put on hold, or equivalently that the validity period of the certificate must be continuous.)

 

Well, I don’t know your skills in French, but mine are rather good.  :-)


When you have the sentence: “La suspension de certificats n'est pas autorisée dans la présente PC Type ”,
an auditor verifying the compliance of the CA would not expect when asking for tests to receive a response
which says that the certificate is revoked with one of the ReasonFlags set to “certificateHold”.

 

The advantage of using "unknown" is that there is no need to give any revocation reason and any revocation date
(however a new non-critical extension may be added to provide more details for those able to understand it).


The current definition from RFC 2560 is:
The "unknown" state indicates that the responder doesn't know about the certificate being requested.

You said: “Responding "unknown" means " I am not authoritative for this issuer, at least not right now." This is not what
the sentence states above. This is your interpretation.

 

You also said: “The only difference in your authoritative and non-authoritative case is whether there is any one else to ask”.

 

No. The difference is that you know that the responder is authoritative only if response for that serial number is signed
either by the right CA and the right key or by an OCSP Responder which received an OCSP certificate from the right CA
and the right key.

 

You said: An authoritative responder is probably less likely to respond "unknown", but could have outages too.
So this demonstrates that your interpretation above of the unknown status is too restrictive.

 

An "unknown" response from an authoritative authority is a response at the time of the request: it might be that there is temporarily
no access to the data base or that there is temporarily no access to the CRLs. So it is not a definitive response.

 

If there is another OCSP server, it may be tried, but switching to CRLs as a backup mechanism is a matter of local policy,
since there may be an associated risk. Which local policy should be used is outside the definition of the protocol and may only be
discussed in the security considerations section.

 

If some implementations use as a local policy to switch to CRLs when an authoritative OCSP responder responds “unknown”,
it is not a problem that we should attempt to solve. The solution is to change the local policy in these implementations.

 

Nota: If a non-authoritative OCSP responder responds “unknown”, this simply means that the request was addressed to the
wrong OCSP server.

 

Denis

:

On Fri, Nov 9, 2012 at 9:30 AM, Denis Pinkas <denis.pinkas@bull.net> wrote:
As said before, the current proposal:
- Breaks on-one
  1) Not really:  it would prevent CAs which need to comply with the French legislation from taking advantage of the new feature.

As I noted earlier I don't read it that way. The text is about what you can do to a certificate. You can't suspend a certificate. But the proposed text is about responding certificateHold for anything but a certificate. 
 
  2) it seems to be a problem for the CAB forum as well:


"Scott expressed concern about the certificateHold status since CAB
Forum may hare requirements to never use certificateHold status
when revoking certificates".

Well, that's easier to solve. It is not a practical problem, for the very same reason (actual certificates will never be on hold, so they will only have one continuous validity period, which is the simplification I believe they are after). And CAB Forum is perhaps easier to reason with than a French ministry (given my prejudice about the napoleonic system of government ;)-.

  2) It breaks the logic of some relying parties which verify electronic signatures: they will wait for end of the suspension state,
or a time out which does not exist today would need to be added.

That logic is clearly against the specification, so why should we accommodate it? Perhaps we need some clarifying language somewhere else to prevent this practice from proliferating.
 
So, why not using "unspecified" ?

Because it is still definite. A serial number which is not issued today may be issued tomorrow. So you have to use a reason code that carries with it that it is valid _now_ but may change the next time you ask.
 
This is not a new extension, but a change in the semantics of the "revoked" status and that may have further implications
on its processing.

I don't agree here. It does not change anything for clients that are already complying with relevant PKIX standards. The only parties that *may* need to change something are OCSP responders, and that's only if they want to take advantage of this functionality.
 
/Simon

--------------020202090309050205030800-- From peter.sylvester@edelweb.fr Fri Nov 9 05:05:57 2012 Return-Path: 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 E8C2721F8585 for ; Fri, 9 Nov 2012 05:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599] 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 Otcx3f7YHrEf for ; Fri, 9 Nov 2012 05:05:56 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5A66D21F8583 for ; Fri, 9 Nov 2012 05:05:56 -0800 (PST) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 3F1665E093 for ; Fri, 9 Nov 2012 14:03:18 +0100 (CET) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id 2A6815E092 for ; Fri, 9 Nov 2012 14:03:18 +0100 (CET) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id D2D7C5E2FE for ; Fri, 9 Nov 2012 14:05:38 +0100 (CET) Received: from smtps.on-x.com (unknown [192.168.14.34]) by mail1.on-x.com (Postfix) with ESMTP id C70DE5E226 for ; Fri, 9 Nov 2012 14:05:38 +0100 (CET) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id E90DD5E49B for ; Fri, 9 Nov 2012 14:04:12 +0100 (CET) Message-ID: <509CFFAA.2080103@edelweb.fr> Date: Fri, 09 Nov 2012 14:05:46 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <509CBF36.1060000@bull.net> <509CE760.4000902@bull.net> In-Reply-To: <509CE760.4000902@bull.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:05:57 -0000 hI, "Suspension of a real certificate means certificateHold ni a CRL entry" is equivalent to "having certficateHold cannot mean Suspension of a real certificate" (and not more). Since we are talking about non existing certs, this is out of scope of the RGS IMO. In other words: An RP that talks to an RGS conformant RGS seeing certificateHold MAY interprete this as (left as an execise). The reason of the text in the RGS is the difficulty to assume that a relying party can handle resumption of a real existing suspended cert. I do not make a comment on the usefulness of certificateHold as a reasonCode for non existing certs /p From stefan@aaa-sec.com Fri Nov 9 07:00:32 2012 Return-Path: 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 8F61821F866C for ; Fri, 9 Nov 2012 07:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.32 X-Spam-Level: X-Spam-Status: No, score=-101.32 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 2xX-FfMTVOUE for ; Fri, 9 Nov 2012 07:00:31 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 41FE321F85C3 for ; Fri, 9 Nov 2012 07:00:28 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2E11F5CAF4 for ; Fri, 9 Nov 2012 16:00:27 +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 CJnAnXDgSTR2 for ; Fri, 9 Nov 2012 16:00:26 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8CAB45CDD5 for ; Fri, 9 Nov 2012 16:00:26 +0100 (CET) Received: (qmail 80699 invoked from network); 9 Nov 2012 15:00:25 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Nov 2012 15:00:25 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 09 Nov 2012 10:00:21 -0400 From: Stefan Santesson To: Simon Tardell , Denis Pinkas Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3435300026_24945092" Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:00:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3435300026_24945092 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 to what Simon says here. Well put. /Stefan From: Simon Tardell Date: Friday, November 9, 2012 5:17 AM To: Denis Pinkas Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP > > > > On Fri, Nov 9, 2012 at 9:30 AM, Denis Pinkas wrote: >> >> >>> As said before, the current proposal: >>> - Breaks on-one >>> >> 1) Not really: it would prevent CAs which need to comply with the French >> legislation from taking advantage of the new feature. > > As I noted earlier I don't read it that way. The text is about what you can do > to a certificate. You can't suspend a certificate. But the proposed text is > about responding certificateHold for anything but a certificate. > >> 2) it seems to be a problem for the CAB forum as well: >> >> >> "Scott expressed concern about the certificateHold status since CAB >> Forum may hare requirements to never use certificateHold status >> when revoking certificates". > > Well, that's easier to solve. It is not a practical problem, for the very same > reason (actual certificates will never be on hold, so they will only have one > continuous validity period, which is the simplification I believe they are > after). And CAB Forum is perhaps easier to reason with than a French ministry > (given my prejudice about the napoleonic system of government ;)-. > >> 2) It breaks the logic of some relying parties which verify electronic >> signatures: they will wait for end of the suspension state, >> or a time out which does not exist today would need to be added. > > That logic is clearly against the specification, so why should we accommodate > it? Perhaps we need some clarifying language somewhere else to prevent this > practice from proliferating. > >> So, why not using "unspecified" ? > > Because it is still definite. A serial number which is not issued today may be > issued tomorrow. So you have to use a reason code that carries with it that it > is valid _now_ but may change the next time you ask. > >> This is not a new extension, but a change in the semantics of the "revoked" >> status and that may have further implications >> on its processing. > > I don't agree here. It does not change anything for clients that are already > complying with relevant PKIX standards. The only parties that *may* need to > change something are OCSP responders, and that's only if they want to take > advantage of this functionality. > > /Simon > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3435300026_24945092 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
+1 to what Simon says here. = Well put.

/Stefan

From: Simon Tardell <simon@tardell.se>
Date: Friday, November 9, 2012 5:17 AM
To: Denis Pinkas <denis.pinkas@bu= ll.net>
Cc: "pkix@ietf.org" <pkix@= ietf.org>
Subject: Re: [pki= x] What's the need to introduce fraudulently issued certificates in OCSP
=




On Fri, Nov 9, 2012 at= 9:30 AM, Denis Pinkas <denis.pinkas@bull.net> wrote:
As said before, the curren=
t proposal:
- Breaks on-one
  1) Not really:  it would prevent CAs which need to comply w= ith the French legislation from taking advantage of the new feature.
<= /blockquote>

As I noted earlier I don't read it that way.= The text is about what you can do to a certificate. You can't sus= pend a certificate. But the proposed text is about responding certificat= eHold for anything but a certificate. 
 
  2) it seems to be a problem for the CAB forum as well:


"Scott expressed concern about the certificateHold status since CAB
= Forum may hare requirements to never use certificateHold status
when revoking certificates".

Well, that's easier to solve. It is not a practical problem, for the v= ery same reason (actual certificates will never be on hold, so they will onl= y have one continuous validity period, which is the simplification I believe= they are after). And CAB Forum is perhaps easier to reason with than a Fren= ch ministry (given my prejudice about the napoleonic system of government ;)= -.

  2) It breaks the logic of some relying parties which verify electronic signatures: they will wait for end of the suspension state,
or a time out which does not exist today would need to be added.
=

That logic is clearly against the specifica= tion, so why should we accommodate it? Perhaps we need some clarifying langu= age somewhere else to prevent this practice from proliferating.
&n= bsp;
So= , why not using "unspecified" ?

Bec= ause it is still definite. A serial number which is not issued today may be = issued tomorrow. So you have to use a reason code that carries with it that = it is valid _now_ but may change the next time you ask.
 
This is no= t a new extension, but a change in the semantics of the "revoked" status and that may have further implications
on its processing.

I don't agree = here. It does not change anything for clients that are already complying wit= h relevant PKIX standards. The only parties that *may* need to change someth= ing are OCSP responders, and that's only if they want to take advantage of t= his functionality.
 
/Simon
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix --B_3435300026_24945092-- From piyush@ditenity.com Fri Nov 9 07:44:52 2012 Return-Path: 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 41E1521F8680 for ; Fri, 9 Nov 2012 07:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, MANGLED_MEN=2.3, RCVD_IN_DNSWL_LOW=-1] 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 sR+HgaaiJzJA for ; Fri, 9 Nov 2012 07:44:51 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7578121F85EA for ; Fri, 9 Nov 2012 07:44:51 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so6772382iec.31 for ; Fri, 09 Nov 2012 07:44:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=FdjPolhuhpApR4BcBw8SOXhsq4FtYgy2CpJxV9SGz/s=; b=nueYDycCpSeFj2sCXvbD9l2dOLNL/Dc8HDPb6k2bdwit+AlCN3WjsYjGly/jkwY0Tj 8FYrNMeiM6/wpgDr9MOHigrNV1ZtTWQg9eVvlNSKcwpf8KuMML2JT2bm8Q064JJcfyDd 3k5+cNbzHhOnFfUcZOxMtZAmY12wrSA8cB3A+A8mqhzhfHmkEtOtB6g/3GmUDojS3Ypa /KwJgrIoaaV3BqkUeaIbkDK95XEiQMPAs/FDziIE09lnQJhd1PwuCzcmzl7UVL16r6pP nFces/76wocFMudeSZfF4fpShHVCpi7AmcyCAyo7TL0bGdUMgEHyH0N/lpNJ/ZX9ta4s 7F5g== Received: by 10.50.237.6 with SMTP id uy6mr1691038igc.31.1352475891015; Fri, 09 Nov 2012 07:44:51 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ex10sm1601333igc.15.2012.11.09.07.44.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 07:44:50 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , , References: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> In-Reply-To: Date: Fri, 9 Nov 2012 07:44:47 -0800 Message-ID: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHj2Argu21Os330NGfAzmQweW+ew5e1by0Q Content-Language: en-us X-Gm-Message-State: ALoCoQnYLQvnQHUwXterXE9V/mCvjZAjuNemRv4GEOlpF4nzSgV0HL6giFK9ENcBFZ4PM7OGAnnE Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:44:52 -0000 Stefan, It seems the goal of you proposal is to just make the status flexible enough, so CAB forum responders stay compliant when they return revoked = for fraudulently issued certificates. You've dismissed any discussions about usefulness or security implications of their proposed method by saying = that it is CAB forum's problem to solve. Here is a modified version of your proposal. It provides flexibility to return revoked for any 'bad' certificates as opposed to only = fraudulently issued ones. It also makes the discussions on certificate hold, = revocation time moot (these discussions don't make sense anyway for so called non-issued certificates) "The "revoked" state indicates that the certificate has been revoked = (either permanently or temporarily (on hold)). This state MAY also be returned = to indicate that the certificate should not be trusted by the relying = party, even if it is not revoked by the CA". How the responder makes this determination is beyond the scope of this document." Thoughts? -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > Stefan Santesson > Sent: Thursday, November 08, 2012 3:58 PM > To: i-barreira@izenpe.net; pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP >=20 > I think this is a very valid post for the CAB forum. >=20 > In their context this is only a piece of the puzzle. I'm sure they = will be able to > respond to how this is a legitimate part of their strategy where they = have > other things in place that provides a more complete picture. >=20 > The current update has never been proposed as a complete solution. >=20 > /Stefan >=20 > On 11/8/12 5:27 AM, "i-barreira@izenpe.net" > wrote: >=20 > >Hi all, > > > >In the recent Straw poll after saying that this is not a way to fix = it > >and choose option 1 as the lesser evil, I=B4d like to clarify my = "proposal" > >and let you know that from a point of view of a PKI software company > >that wants to implement this solution, it=B4s not easy and in fact = will > >not fix anything. So here it goes > > > >This "fix" tries to avoid that someone can issue a bogus certificate > >and after that delete the log/registry of the issuance (This is the > >Diginotar case). But this "fix" wouldn=B4t help/fix much: > > > >- if a bogus certificate has been issued, it means that the CA key = has > >been compromised so that CA has to be removed/deleted/destroyed. > >But > >- as I=B4m an evil hacker that get access to the CA, I can create the > >bogus certificate without AIA > >- as I=B4m en evil hacket that get access to the CA, I can create the > >bogus certificate without AIA and with CDP pointing to legitimate = CRLs > >- as I=B4m en evil hacket that get access to the CA, I can create the > >bogus certificate with an AIA that points to an OCSP responder that I > >control/manage > >- as I=B4m en evil hacket that get access to the CA, I can create the > >bogus certificate with a serial number of a valid certificate > > > >So, all third parties systems that use CRLs instead of OCSP to = validate > >certs, will consider this bogus cert as valid > > > >In summary, the VA has to manage, somehow, a kind of a white list = that > >can grow to the infinite. This VA has to "ask this list" every time = an > >OCSP responder is generated and has to update practically at the same > >time than the issuance of the certificate. > >But the key question is that once this evil hacker has done "his = job", > >the only fix is to revoke the complete CA. It=B4s useless that the = OCSP > >responder gives a "revoked" for unknown certificates because the > >browsers for example could be asking the bogus OCSP (the one = controlled > >by the > >hacker) or asking for a serial number of the bogus certificate which = is > >identical to a legitimate one. > > > >I know that we all know this situation so maybe this is useless, not > >easy to implement for sure and with very limited good results. > > > >Regards > > > >I=F1igo Barreira > >Responsable del =C1rea t=E9cnica > >i-barreira@izenpe.net > >945067705 > > > > > >ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta > >egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada > >(helbidea gaizki idatzi, transmisioak huts egin) eman abisu = igorleari, > >korreo honi erantzuna. KONTUZ! > >ATENCION! Este mensaje contiene informacion privilegiada o = confidencial > >a la que solo tiene derecho a acceder el destinatario. Si usted lo > >recibe por error le agradeceriamos que no hiciera uso de la = informacion > >y que se pusiese en contacto con el remitente. > > > >-----Mensaje original----- > >De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de > >Stefan Santesson Enviado el: mi=E9rcoles, 07 de noviembre de 2012 = 14:39 > >Para: pkix@ietf.org > >Asunto: Re: [pkix] What's the need to introduce fraudulently issued > >certificates in OCSP > > > >I would suggest that what we are trying to do with OCSP in this = update > >is NOT to fix problems with compromised CAs. > > > >We are simply allowing responders to provide a more > >accurate/functional/safer response in case of a status request for a > >non-issued cert. > > > >As said before, the current proposal: > >- Breaks on-one > >- Does not add ambiguity for responses to issued certs from good CAs > >- Does not add ambiguity in any case for those understanding the new > >extension. > >- Allows CAB Forum responders to be compliant with OCSP. > > > >Problems raised are purely philosophical. Not ONE practical real > >issue/problem has been presented. > >If I missed one, please let me know. > > > >/Stefan > > > > > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Fri Nov 9 08:01:45 2012 Return-Path: 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 1824621F8743 for ; Fri, 9 Nov 2012 08:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 18WiddfZoDQJ for ; Fri, 9 Nov 2012 08:01:44 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1E21F873C for ; Fri, 9 Nov 2012 08:01:44 -0800 (PST) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id qA9G1guj087808 for ; Fri, 9 Nov 2012 11:01:42 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.101]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0421.002; Fri, 9 Nov 2012 11:01:42 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Thread-Index: AQHNvpOCHiGZAgvmmU6Tj4zoRbQ1+A== Date: Fri, 9 Nov 2012 16:01:41 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8439BC2A2@clavin.missi.ncsc.mil> References: <763539E260C37C46A0D6B340B5434C3B0615F265@AEX06.ejsarea.net> <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> In-Reply-To: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:01:45 -0000 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piy= ush Jain > "The "revoked" state indicates that the certificate has > been revoked (either permanently or temporarily (on hold)). > This state MAY also be returned to indicate that the certificate > should not be trusted by the relying party, even if it is not > revoked by the CA". How the responder makes this determination > is beyond the scope of this document." +1 From stefan@aaa-sec.com Fri Nov 9 08:06:13 2012 Return-Path: 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 A1D6421F8756 for ; Fri, 9 Nov 2012 08:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.816 X-Spam-Level: X-Spam-Status: No, score=-100.816 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_MEN=2.3, 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 2PhD-KlUXKZt for ; Fri, 9 Nov 2012 08:06:12 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 554D421F873C for ; Fri, 9 Nov 2012 08:06:11 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id C44F03D3EA for ; Fri, 9 Nov 2012 17:06:10 +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 836P3jpLcOB1 for ; Fri, 9 Nov 2012 17:06:09 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E84BB5CDF5 for ; Fri, 9 Nov 2012 17:06:09 +0100 (CET) Received: (qmail 65169 invoked from network); 9 Nov 2012 16:06:09 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Nov 2012 16:06:09 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 09 Nov 2012 11:06:06 -0400 From: Stefan Santesson To: Piyush Jain , , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:06:13 -0000 Hi, I con't possibly come up with more than 3 states of a randomly selected cert serial number: It is either: 1) Never issued (never included in any issued certificates by this CA). 2) Has been issued and is revoked. 3) Has been issued but is not revoked The other dimension of this is whether the cert is within its validity period or not. I reaaly want to stay out of that aspect due to all variants of dealing with historic validation. My fear is that responders that adopts your text may want to include cert expiration into the determination of "bad". And then we have really created confusion as to what "revoked" really means. /Stefan On 11/9/12 11:44 AM, "Piyush Jain" wrote: >Stefan, > >It seems the goal of you proposal is to just make the status flexible >enough, so CAB forum responders stay compliant when they return revoked >for >fraudulently issued certificates. You've dismissed any discussions about >usefulness or security implications of their proposed method by saying >that >it is CAB forum's problem to solve. > >Here is a modified version of your proposal. It provides flexibility to >return revoked for any 'bad' certificates as opposed to only fraudulently >issued ones. It also makes the discussions on certificate hold, revocation >time moot (these discussions don't make sense anyway for so called >non-issued certificates) > >"The "revoked" state indicates that the certificate has been revoked >(either >permanently or temporarily (on hold)). This state MAY also be returned to >indicate that the certificate should not be trusted by the relying party, >even if it is not revoked by the CA". How the responder makes this >determination is beyond the scope of this document." > >Thoughts? > >-Piyush > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stefan Santesson >> Sent: Thursday, November 08, 2012 3:58 PM >> To: i-barreira@izenpe.net; pkix@ietf.org >> Subject: Re: [pkix] What's the need to introduce fraudulently issued >> certificates in OCSP >>=20 >> I think this is a very valid post for the CAB forum. >>=20 >> In their context this is only a piece of the puzzle. I'm sure they will >>be >able to >> respond to how this is a legitimate part of their strategy where they >>have >> other things in place that provides a more complete picture. >>=20 >> The current update has never been proposed as a complete solution. >>=20 >> /Stefan >>=20 >> On 11/8/12 5:27 AM, "i-barreira@izenpe.net" >> wrote: >>=20 >> >Hi all, >> > >> >In the recent Straw poll after saying that this is not a way to fix it >> >and choose option 1 as the lesser evil, I=B4d like to clarify my >>"proposal" >> >and let you know that from a point of view of a PKI software company >> >that wants to implement this solution, it=B4s not easy and in fact will >> >not fix anything. So here it goes >> > >> >This "fix" tries to avoid that someone can issue a bogus certificate >> >and after that delete the log/registry of the issuance (This is the >> >Diginotar case). But this "fix" wouldn=B4t help/fix much: >> > >> >- if a bogus certificate has been issued, it means that the CA key has >> >been compromised so that CA has to be removed/deleted/destroyed. >> >But >> >- as I=B4m an evil hacker that get access to the CA, I can create the >> >bogus certificate without AIA >> >- as I=B4m en evil hacket that get access to the CA, I can create the >> >bogus certificate without AIA and with CDP pointing to legitimate CRLs >> >- as I=B4m en evil hacket that get access to the CA, I can create the >> >bogus certificate with an AIA that points to an OCSP responder that I >> >control/manage >> >- as I=B4m en evil hacket that get access to the CA, I can create the >> >bogus certificate with a serial number of a valid certificate >> > >> >So, all third parties systems that use CRLs instead of OCSP to validate >> >certs, will consider this bogus cert as valid >> > >> >In summary, the VA has to manage, somehow, a kind of a white list that >> >can grow to the infinite. This VA has to "ask this list" every time an >> >OCSP responder is generated and has to update practically at the same >> >time than the issuance of the certificate. >> >But the key question is that once this evil hacker has done "his job", >> >the only fix is to revoke the complete CA. It=B4s useless that the OCSP >> >responder gives a "revoked" for unknown certificates because the >> >browsers for example could be asking the bogus OCSP (the one controlled >> >by the >> >hacker) or asking for a serial number of the bogus certificate which is >> >identical to a legitimate one. >> > >> >I know that we all know this situation so maybe this is useless, not >> >easy to implement for sure and with very limited good results. >> > >> >Regards >> > >> >I=F1igo Barreira >> >Responsable del =C1rea t=E9cnica >> >i-barreira@izenpe.net >> >945067705 >> > >> > >> >ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta >> >egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada >> >(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, >> >korreo honi erantzuna. KONTUZ! >> >ATENCION! Este mensaje contiene informacion privilegiada o confidencial >> >a la que solo tiene derecho a acceder el destinatario. Si usted lo >> >recibe por error le agradeceriamos que no hiciera uso de la informacion >> >y que se pusiese en contacto con el remitente. >> > >> >-----Mensaje original----- >> >De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de >> >Stefan Santesson Enviado el: mi=E9rcoles, 07 de noviembre de 2012 14:39 >> >Para: pkix@ietf.org >> >Asunto: Re: [pkix] What's the need to introduce fraudulently issued >> >certificates in OCSP >> > >> >I would suggest that what we are trying to do with OCSP in this update >> >is NOT to fix problems with compromised CAs. >> > >> >We are simply allowing responders to provide a more >> >accurate/functional/safer response in case of a status request for a >> >non-issued cert. >> > >> >As said before, the current proposal: >> >- Breaks on-one >> >- Does not add ambiguity for responses to issued certs from good CAs >> >- Does not add ambiguity in any case for those understanding the new >> >extension. >> >- Allows CAB Forum responders to be compliant with OCSP. >> > >> >Problems raised are purely philosophical. Not ONE practical real >> >issue/problem has been presented. >> >If I missed one, please let me know. >> > >> >/Stefan >> > >> > >> >_______________________________________________ >> >pkix mailing list >> >pkix@ietf.org >> >https://www.ietf.org/mailman/listinfo/pkix >> >_______________________________________________ >> >pkix mailing list >> >pkix@ietf.org >> >https://www.ietf.org/mailman/listinfo/pkix >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > From piyush@ditenity.com Fri Nov 9 08:31:13 2012 Return-Path: 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 83D7821F8646 for ; Fri, 9 Nov 2012 08:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, MANGLED_MEN=2.3, RCVD_IN_DNSWL_LOW=-1] 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 pr0J9Kla0E8D for ; Fri, 9 Nov 2012 08:31:12 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94BCE21F84DC for ; Fri, 9 Nov 2012 08:31:12 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so6859092iec.31 for ; Fri, 09 Nov 2012 08:31:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=dioKiX0Sn1HmywMQrwoFHa1t+hATlTOIIXFQn3hk4xE=; b=kUZ2F6+g0l5wEhf4eEx/drpLJwqy/zE8dKXI2k4LvLffG7/f+M4UORM+NZafUl1gzk DLcv0AxJ7G0my40SQNqMhYl6Zb8fWomfTxkPopz7TE1nHP8XYOCKsh+OL5JfGr2/n/dd /uPbsg95ZlRzg6xXrn6YpI/RUpEpkpnff6eLKwnDmi9fQvVMfyHSeT+Swo/zghhGCYRx BWVzthylcH03B6prj81iyQefq9OKJOVIFyhkalDaK8kcMuuw/aykGLXDYbhQ1Dl4enCK zQg8jccuDMxwW2lAqminw9V7FGiQ5HqPECLECmYbnVtT9T83TTj7u182AD8ZWMRLUut3 9dLg== Received: by 10.50.41.165 with SMTP id g5mr1747567igl.66.1352478671932; Fri, 09 Nov 2012 08:31:11 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id gs6sm1706872igc.11.2012.11.09.08.31.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 08:31:10 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , , References: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> In-Reply-To: Date: Fri, 9 Nov 2012 08:31:07 -0800 Message-ID: <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9t+VoicQPVo7sjsjegMJ5SMZoK5gBuW9w Content-Language: en-us X-Gm-Message-State: ALoCoQldGBjY/lQYYZp7kQN3z14SqKOd1USxu7Penz3/HuHx69oyY9LtsQU4TGxpzljIa2BSmbOU Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:31:13 -0000 The first state that you refer to has no practical value. Clients don't = send OCSP requests for randomly selected certificates. I think the cause of confusion is the misnomer "non-issued-certificates". The reasoning = offered for this proposal was that it helps CAs to deal with digiNotor like scenarios. If I've missed any discussion on usefulness of providing = status for random serial numbers which are not tied to a certificate, please = let me know. > The other dimension of this is whether the cert is within its validity period or > not.> I reaaly want to stay out of that aspect due to all variants of dealing with > historic validation. >=20 The changed text actually helps us stay out of those discussions > My fear is that responders that adopts your text may want to include = cert > expiration into the determination of "bad". And then we have really created confusion as to what "revoked" really > means. I don't see any practical problem even if the responders decide to do = so. The arguments that are made for returning revoked for non-issued are applicable even for expired certificates or for that matter any bad certificate. Its more secure for clients who do not deal with expired certificates correctly - same as revoked for 'non-issued', which is more secure for clients who do not deal with 'unknown' correctly. BTW - I think that above text is actually clearer in conveying the = changed meaning, from just 'revocation status' to negative proof. > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Friday, November 09, 2012 7:06 AM > To: Piyush Jain; i-barreira@izenpe.net; pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP >=20 > Hi, >=20 >=20 > I con't possibly come up with more than 3 states of a randomly = selected cert > serial number: > It is either: > 1) Never issued (never included in any issued certificates by this = CA). > 2) Has been issued and is revoked. > 3) Has been issued but is not revoked >=20 > The other dimension of this is whether the cert is within its validity period or > not. > I reaaly want to stay out of that aspect due to all variants of = dealing with > historic validation. >=20 > My fear is that responders that adopts your text may want to include = cert > expiration into the determination of "bad". > And then we have really created confusion as to what "revoked" really > means. >=20 > /Stefan >=20 >=20 > On 11/9/12 11:44 AM, "Piyush Jain" wrote: >=20 > >Stefan, > > > >It seems the goal of you proposal is to just make the status flexible > >enough, so CAB forum responders stay compliant when they return > revoked > >for fraudulently issued certificates. You've dismissed any = discussions > >about usefulness or security implications of their proposed method by > >saying that it is CAB forum's problem to solve. > > > >Here is a modified version of your proposal. It provides flexibility = to > >return revoked for any 'bad' certificates as opposed to only > >fraudulently issued ones. It also makes the discussions on = certificate > >hold, revocation time moot (these discussions don't make sense anyway > >for so called non-issued certificates) > > > >"The "revoked" state indicates that the certificate has been revoked > >(either permanently or temporarily (on hold)). This state MAY also be > >returned to indicate that the certificate should not be trusted by = the > >relying party, even if it is not revoked by the CA". How the = responder > >makes this determination is beyond the scope of this document." > > > >Thoughts? > > > >-Piyush > > > >> -----Original Message----- > >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On = Behalf > >> Of Stefan Santesson > >> Sent: Thursday, November 08, 2012 3:58 PM > >> To: i-barreira@izenpe.net; pkix@ietf.org > >> Subject: Re: [pkix] What's the need to introduce fraudulently = issued > >> certificates in OCSP > >> > >> I think this is a very valid post for the CAB forum. > >> > >> In their context this is only a piece of the puzzle. I'm sure they > >>will be > >able to > >> respond to how this is a legitimate part of their strategy where = they > >>have other things in place that provides a more complete picture. > >> > >> The current update has never been proposed as a complete solution. > >> > >> /Stefan > >> > >> On 11/8/12 5:27 AM, "i-barreira@izenpe.net" > >> wrote: > >> > >> >Hi all, > >> > > >> >In the recent Straw poll after saying that this is not a way to = fix > >> >it and choose option 1 as the lesser evil, I=B4d like to clarify = my > >>"proposal" > >> >and let you know that from a point of view of a PKI software = company > >> >that wants to implement this solution, it=B4s not easy and in fact > >> >will not fix anything. So here it goes > >> > > >> >This "fix" tries to avoid that someone can issue a bogus = certificate > >> >and after that delete the log/registry of the issuance (This is = the > >> >Diginotar case). But this "fix" wouldn=B4t help/fix much: > >> > > >> >- if a bogus certificate has been issued, it means that the CA key > >> >has been compromised so that CA has to be > removed/deleted/destroyed. > >> >But > >> >- as I=B4m an evil hacker that get access to the CA, I can create = the > >> >bogus certificate without AIA > >> >- as I=B4m en evil hacket that get access to the CA, I can create = the > >> >bogus certificate without AIA and with CDP pointing to legitimate > >> >CRLs > >> >- as I=B4m en evil hacket that get access to the CA, I can create = the > >> >bogus certificate with an AIA that points to an OCSP responder = that > >> >I control/manage > >> >- as I=B4m en evil hacket that get access to the CA, I can create = the > >> >bogus certificate with a serial number of a valid certificate > >> > > >> >So, all third parties systems that use CRLs instead of OCSP to > >> >validate certs, will consider this bogus cert as valid > >> > > >> >In summary, the VA has to manage, somehow, a kind of a white list > >> >that can grow to the infinite. This VA has to "ask this list" = every > >> >time an OCSP responder is generated and has to update practically = at > >> >the same time than the issuance of the certificate. > >> >But the key question is that once this evil hacker has done "his > >> >job", the only fix is to revoke the complete CA. It=B4s useless = that > >> >the OCSP responder gives a "revoked" for unknown certificates > >> >because the browsers for example could be asking the bogus OCSP = (the > >> >one controlled by the > >> >hacker) or asking for a serial number of the bogus certificate = which > >> >is identical to a legitimate one. > >> > > >> >I know that we all know this situation so maybe this is useless, = not > >> >easy to implement for sure and with very limited good results. > >> > > >> >Regards > >> > > >> >I=F1igo Barreira > >> >Responsable del =C1rea t=E9cnica > >> >i-barreira@izenpe.net > >> >945067705 > >> > > >> > > >> >ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez = babestuta > >> >egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada > >> >(helbidea gaizki idatzi, transmisioak huts egin) eman abisu > >> >igorleari, korreo honi erantzuna. KONTUZ! > >> >ATENCION! Este mensaje contiene informacion privilegiada o > >> >confidencial a la que solo tiene derecho a acceder el = destinatario. > >> >Si usted lo recibe por error le agradeceriamos que no hiciera uso = de > >> >la informacion y que se pusiese en contacto con el remitente. > >> > > >> >-----Mensaje original----- > >> >De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre > >> >de Stefan Santesson Enviado el: mi=E9rcoles, 07 de noviembre de = 2012 > >> >14:39 > >> >Para: pkix@ietf.org > >> >Asunto: Re: [pkix] What's the need to introduce fraudulently = issued > >> >certificates in OCSP > >> > > >> >I would suggest that what we are trying to do with OCSP in this > >> >update is NOT to fix problems with compromised CAs. > >> > > >> >We are simply allowing responders to provide a more > >> >accurate/functional/safer response in case of a status request for = a > >> >non-issued cert. > >> > > >> >As said before, the current proposal: > >> >- Breaks on-one > >> >- Does not add ambiguity for responses to issued certs from good = CAs > >> >- Does not add ambiguity in any case for those understanding the = new > >> >extension. > >> >- Allows CAB Forum responders to be compliant with OCSP. > >> > > >> >Problems raised are purely philosophical. Not ONE practical real > >> >issue/problem has been presented. > >> >If I missed one, please let me know. > >> > > >> >/Stefan > >> > > >> > > >> >_______________________________________________ > >> >pkix mailing list > >> >pkix@ietf.org > >> >https://www.ietf.org/mailman/listinfo/pkix > >> >_______________________________________________ > >> >pkix mailing list > >> >pkix@ietf.org > >> >https://www.ietf.org/mailman/listinfo/pkix > >> > >> > >> _______________________________________________ > >> pkix mailing list > >> pkix@ietf.org > >> https://www.ietf.org/mailman/listinfo/pkix > > >=20 From stefan@aaa-sec.com Fri Nov 9 09:03:09 2012 Return-Path: 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 596AD21F876A for ; Fri, 9 Nov 2012 09:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.879 X-Spam-Level: X-Spam-Status: No, score=-101.879 tagged_above=-999 required=5 tests=[AWL=0.370, 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 QwUChmKVmuvz for ; Fri, 9 Nov 2012 09:03:09 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8A21F874E for ; Fri, 9 Nov 2012 09:03:08 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id BFDA15D369 for ; Fri, 9 Nov 2012 18:03:07 +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 tjEdqeWhqcb0 for ; Fri, 9 Nov 2012 18:03:07 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 88AC65D309 for ; Fri, 9 Nov 2012 18:03:07 +0100 (CET) Received: (qmail 9459 invoked from network); 9 Nov 2012 17:03:07 -0000 Received: from dhcp-42ed.meeting.ietf.org (HELO [130.129.66.237]) (stefan@fiddler.nu@[130.129.66.237]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Nov 2012 17:03:07 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 09 Nov 2012 12:03:07 -0400 From: Stefan Santesson To: Piyush Jain , , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:03:09 -0000 On 11/9/12 12:31 PM, "Piyush Jain" wrote: >Clients don't send >OCSP requests for randomly selected certificates. An attacker may, e.g. in order to harvest information/data that may be useful to form attacks. A responder must be prepared to deal with all possible requests. I'm reluctant to take this discussion any further unless something really new comes up. We have already established our level of disagreement. /Stefan From eabalea@gmail.com Fri Nov 9 09:09:46 2012 Return-Path: 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 52C4B21F84E1 for ; Fri, 9 Nov 2012 09:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 byyWjODO+-xL for ; Fri, 9 Nov 2012 09:09:45 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF8021F84E3 for ; Fri, 9 Nov 2012 09:09:45 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so3427377lam.31 for ; Fri, 09 Nov 2012 09:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=foc9YTiEJXErXiQr5HKRQtEpG89F0kUCrd7IN26zYLY=; b=WKGvHo4+zliHnIKuvT2kRJ9VaA5M51QFCw1arfM92XWHI9qdvDaXtXbYLEoQVPuglG QcVd/H/FY8jt/J146wTlrU2f+x6rZm46eR8161h4Dh0U0IMVs3vDprUE/1/PxwfQfQNm cHBeGt+E4NdLMw76t1lRG1hhIRTN5yflTH554FTXfDomuv0XroVb4bQfu2L4v9j3Mg3k t1GhhvcHTiaDv6Vs2xAy2Zx8fKsPuswDjDo5FK/z+YYyM+now4o4B7ZLbf2mqWiuFNyt hiuj/Z8Aew+t7icGQbag0EV0JTnUUNBNhLPRDDqYhHrzhmbrU9kqKEblAgootQkrt5fH kUpQ== MIME-Version: 1.0 Received: by 10.152.106.162 with SMTP id gv2mr10995207lab.14.1352480984485; Fri, 09 Nov 2012 09:09:44 -0800 (PST) Received: by 10.114.25.74 with HTTP; Fri, 9 Nov 2012 09:09:44 -0800 (PST) In-Reply-To: <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> References: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> Date: Fri, 9 Nov 2012 18:09:44 +0100 Message-ID: From: Erwann Abalea To: Piyush Jain Content-Type: multipart/alternative; boundary=f46d04083aa5a54db904ce13048b Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:09:46 -0000 --f46d04083aa5a54db904ce13048b Content-Type: text/plain; charset=UTF-8 2012/11/9 Piyush Jain > The first state that you refer to has no practical value. Clients don't > send > OCSP requests for randomly selected certificates. I think the cause of > They do. Everyday. Some are purely bogus requests, some are crafted ones. The OCSP responder has to respond to those. -- Erwann. --f46d04083aa5a54db904ce13048b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2012/11/9 Piyush = Jain <piyush@ditenity.com>
The first state that you refer to has no practical value. Clients don't= send
OCSP requests for randomly selected certificates. I think the cause of
<= /blockquote>

They do. Everyday. Some are purely bogus re= quests, some are crafted ones.
The OCSP responder has to respond = to those.

--
Erwann.
--f46d04083aa5a54db904ce13048b-- From piyush@ditenity.com Fri Nov 9 09:14:49 2012 Return-Path: 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 B5BE021F8742 for ; Fri, 9 Nov 2012 09:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 MJUVgHM7RuZf for ; Fri, 9 Nov 2012 09:14:48 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C572721F86FC for ; Fri, 9 Nov 2012 09:14:48 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so6935654iec.31 for ; Fri, 09 Nov 2012 09:14:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=5xtUr9sKIdwVEPaLvQVUO1aj+xEf7VQOBYCtj25j3Sg=; b=TlXYdK9vL8sUNr7JGiX7yXeFBMkxL2F7EqcMUnkhGMOJnHo0Z2HIdle6lvT/YAFZNx kfD/yS5f36Nwsbf1BHEGHSiS4zDQ1fAlXASMqBKCdre6TVanoVXWsRg+zpjE0JOWl+HB titqC6jD5jdEmWnciGJNlBwVd8fVWS179lZ9S/YSY08xc2+P7zotuhdXWHmEPWJ4ixKv q9E3Xqe3kZIRN7b0hY3zLWr20McisxIxawDOEbgUDkyXa6J3jPuQCH/lUYGqkhoBOnrv HJxwKyEx0JpgxekxOlt+9W2ikhI0vP/Wg5dro60LXWrE5PLOheyOVebjPIgUuK+6mzzZ OfYQ== Received: by 10.50.159.170 with SMTP id xd10mr1946408igb.44.1352481288377; Fri, 09 Nov 2012 09:14:48 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id xn10sm1652963igb.4.2012.11.09.09.14.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 09:14:47 -0800 (PST) From: "Piyush Jain" To: "'Erwann Abalea'" References: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> In-Reply-To: Date: Fri, 9 Nov 2012 09:14:45 -0800 Message-ID: <00cd01cdbe9d$b84b2dd0$28e18970$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01CDBE5A.AA2C0C80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLHkUKBn1JpvKWa6zcj+D9+CDvHvgG9t+VoAa7PmtICZvieSpW/e6NQ Content-Language: en-us X-Gm-Message-State: ALoCoQk0O7phxtnceDpUZdlEQONppEFRmvv/H1jANJyYPgCSZuN77md7QZvUJSvgwOjfgHk/280K Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:14:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CE_01CDBE5A.AA2C0C80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Erwaan, =20 What do you think is the right response in such cases? One large public CA vendor returns unsigned =E2=80=98try later=E2=80=99 = for such requests. The reasoning is to not waste CPU cycles and = bandwidth on such requests because they have no practical value. =20 -Piyush =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, November 09, 2012 9:10 AM To: Piyush Jain Cc: Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued = certificates in OCSP =20 =20 2012/11/9 Piyush Jain The first state that you refer to has no practical value. Clients don't = send OCSP requests for randomly selected certificates. I think the cause of =20 They do. Everyday. Some are purely bogus requests, some are crafted = ones. The OCSP responder has to respond to those. =20 --=20 Erwann. ------=_NextPart_000_00CE_01CDBE5A.AA2C0C80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Erwaan,

 

What do you think is the right response in such = cases?

One large public CA vendor returns unsigned =E2=80=98try = later=E2=80=99 for such requests. The reasoning is to not waste CPU = cycles and bandwidth on such requests because they have no practical = value.

 

-Piyush

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = November 09, 2012 9:10 AM
To: Piyush Jain
Cc: Stefan = Santesson; i-barreira@izenpe.net; pkix@ietf.org
Subject: Re: = [pkix] What's the need to introduce fraudulently issued certificates in = OCSP

 

 

2012/11/9 Piyush Jain <piyush@ditenity.com>

The first state that you refer to has no practical = value. Clients don't send
OCSP requests for randomly selected = certificates. I think the cause of

 

They do. Everyday. Some are purely bogus requests, = some are crafted ones.

The = OCSP responder has to respond to = those.

 

-- =
Erwann.

------=_NextPart_000_00CE_01CDBE5A.AA2C0C80-- From eabalea@gmail.com Fri Nov 9 09:35:42 2012 Return-Path: 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 1961621F877D for ; Fri, 9 Nov 2012 09:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 iLilAg6J1Mw2 for ; Fri, 9 Nov 2012 09:35:39 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB41A21F8778 for ; Fri, 9 Nov 2012 09:35:38 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so3505909lbo.31 for ; Fri, 09 Nov 2012 09:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oKewv3itKDdeTF1Jtyrgbt7kxgwY8Y+6ccS5ytrdzyY=; b=TbK4cj6UgGmja/78HmymnJAZRxHBXBNg7KaNaK0TYh9LkSdApXfX3i5YXsl1q8jWDZ qTKF0J2aGSt+crpT2dxisy8KLxtZMe5zBHKq9zix1eCinYGOC3yKNzrgZ9iDuHom4uro ztFRPtKVltH8bhQVk4czq1OaIk5cQBaGHTTNkYkjg1OAFK3iynx3qTdx6hopavSwtpk4 m2oSGircAlGTEIAyWeTX+BxPlO5ZOtk09rb+Giqq8SIOAxTODZVXDmTZ1XWoOS1dYl5t gJSG8IBIA/tXDFQEXVoW203uGFVksgRK/vJvY+inSuuwPpPanEWG59WTvwmsiycqari1 1g6A== MIME-Version: 1.0 Received: by 10.112.39.233 with SMTP id s9mr4909438lbk.71.1352482537918; Fri, 09 Nov 2012 09:35:37 -0800 (PST) Received: by 10.114.25.74 with HTTP; Fri, 9 Nov 2012 09:35:37 -0800 (PST) In-Reply-To: <00cd01cdbe9d$b84b2dd0$28e18970$@ditenity.com> References: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> <00cd01cdbe9d$b84b2dd0$28e18970$@ditenity.com> Date: Fri, 9 Nov 2012 18:35:37 +0100 Message-ID: From: Erwann Abalea To: Piyush Jain Content-Type: multipart/alternative; boundary=e0cb4efe30703cd16104ce136110 Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:35:42 -0000 --e0cb4efe30703cd16104ce136110 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd reply an unsigned response. "unauthorized" seems better than "tryLater" (the later is obviously an invitation to retry, which is undesired). It's easier to define in the CABForum context because of the 'B'rowsers participation. That's why I responded #3 to the stray poll, with the hope that some constraints or guidelines could be set on RP. 2012/11/9 Piyush Jain > Erwaan,**** > > ** ** > > What do you think is the right response in such cases?**** > > One large public CA vendor returns unsigned =E2=80=98try later=E2=80=99 f= or such requests. > The reasoning is to not waste CPU cycles and bandwidth on such requests > because they have no practical value.**** > > ** ** > > -Piyush**** > > ** ** > > *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Friday, November 09, 2012 9:10 AM > *To:* Piyush Jain > *Cc:* Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org > > *Subject:* Re: [pkix] What's the need to introduce fraudulently issued > certificates in OCSP**** > > ** ** > > ** ** > > 2012/11/9 Piyush Jain **** > > The first state that you refer to has no practical value. Clients don't > send > OCSP requests for randomly selected certificates. I think the cause of***= * > > ** ** > > They do. Everyday. Some are purely bogus requests, some are crafted ones.= * > *** > > The OCSP responder has to respond to those.**** > > ** ** > > -- > Erwann.**** > --=20 Erwann. --e0cb4efe30703cd16104ce136110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd reply an unsigned response. "unauthorized" seems better t= han "tryLater" (the later is obviously an invitation to retry, wh= ich is undesired).
It's easier to define in the CABForum context be= cause of the 'B'rowsers participation.

That's why I responded #3 to t= he stray poll, with the hope that some constraints or guidelines could be s= et on RP.

2012/11/9 Piyush Jain <piyus= h@ditenity.com>

Erwaan,

=C2=A0

What do you think i= s the right response in such cases?

One large public CA vendo= r returns unsigned =E2=80=98try later=E2=80=99 for such requests. The reaso= ning is to not waste CPU cycles and bandwidth on such requests because they= have no practical value.

=C2=A0

-Piyush

=C2=A0

From: Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, November 09, 2012 9:10 AM
To: Piyush JainCc: Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org


Subject: Re: [pkix] What's the need to int= roduce fraudulently issued certificates in OCSP

<= /div>

=C2=A0

=C2=A0

2012/11/9 Piyush Jain &= lt;piyush@ditenity= .com>

The first state that you refer to has no practical value. Clients don'= t send
OCSP requests for randomly selected certificates. I think the cause of

=C2=A0

They do. Everyday. Some are purely bogus requests, = some are crafted ones.

The OCSP responder has to respond to thos= e.

=C2=A0

<= p class=3D"MsoNormal"> --
Erwann.




--
Erwann.
--e0cb4efe30703cd16104ce136110-- From piyush@ditenity.com Fri Nov 9 09:51:38 2012 Return-Path: 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 20B7221F876C for ; Fri, 9 Nov 2012 09:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.48 X-Spam-Level: X-Spam-Status: No, score=-4.48 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 GNZWGjHzPWY8 for ; Fri, 9 Nov 2012 09:51:37 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5C521F8760 for ; Fri, 9 Nov 2012 09:51:37 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so6993656iec.31 for ; Fri, 09 Nov 2012 09:51:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=Zkq47MgHU9sY6zBmQt8CD4IdlRYx9WFV0kYvLG0IsFU=; b=YHI/WlbIHzRKZg+AZt0KrAy0FmAvPvc3JEaibyCEgONysjV6WBbvl7cXtJ7dfQDWit ApHOrHxbwrHPlC1RPfYjkUpUdOD3mnGXMN0runplpUQOoRL64fb8wWj77NcsPtf/WGJx T36B9gyUIn5U85r8c6chT+Rmj1sjzhGnDIqjwkqqelbgtusL5Djusxp2FTMavYKy+NCx +AUe2aYPrpiCL7/P8UIlQeO+Yw2UlgOecEMJwbtxlZRU0bk8o4PQjTGBy98u9ibNMLlW jhgR9Em+hv8e3xp0I6OrzEdOo7tE9Xrpx/guoZoWcsCS/eiJaVYwWRGTU+aXYecJ88aU zh7g== Received: by 10.50.182.166 with SMTP id ef6mr2055162igc.65.1352483496832; Fri, 09 Nov 2012 09:51:36 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id az6sm1711726igb.11.2012.11.09.09.51.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 09:51:35 -0800 (PST) From: "Piyush Jain" To: "'Erwann Abalea'" References: <00a501cdbe91$2723b7c0$756b2740$@ditenity.com> <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> <00cd01cdbe9d$b84b2dd0$28e18970$@ditenity.com> In-Reply-To: Date: Fri, 9 Nov 2012 09:51:33 -0800 Message-ID: <010101cdbea2$dc8eae10$95ac0a30$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0102_01CDBE5F.CE6D1BC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLHkUKBn1JpvKWa6zcj+D9+CDvHvgG9t+VoAa7PmtICZvieSgJN5NC7ARvOgzSVpDk4MA== Content-Language: en-us X-Gm-Message-State: ALoCoQmPKDlKflU/9zswUubWBTdAn4uK9zyncY5t8eCBXvWwWkY5jMQcgJrEN4R9xEN+Xfa7+cs2 Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:51:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0102_01CDBE5F.CE6D1BC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Erwann, =20 Unsigned Unauthorized indeed seems to be a better choice. =20 -Piyush =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, November 09, 2012 9:36 AM To: Piyush Jain Cc: Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued = certificates in OCSP =20 I'd reply an unsigned response. "unauthorized" seems better than = "tryLater" (the later is obviously an invitation to retry, which is = undesired). It's easier to define in the CABForum context because of the 'B'rowsers = participation. =20 That's why I responded #3 to the stray poll, with the hope that some = constraints or guidelines could be set on RP. 2012/11/9 Piyush Jain Erwaan, =20 What do you think is the right response in such cases? One large public CA vendor returns unsigned =E2=80=98try later=E2=80=99 = for such requests. The reasoning is to not waste CPU cycles and = bandwidth on such requests because they have no practical value. =20 -Piyush =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, November 09, 2012 9:10 AM To: Piyush Jain Cc: Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued = certificates in OCSP =20 =20 2012/11/9 Piyush Jain The first state that you refer to has no practical value. Clients don't = send OCSP requests for randomly selected certificates. I think the cause of =20 They do. Everyday. Some are purely bogus requests, some are crafted = ones. The OCSP responder has to respond to those. =20 --=20 Erwann. =20 --=20 Erwann. ------=_NextPart_000_0102_01CDBE5F.CE6D1BC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks Erwann,

 

Unsigned Unauthorized indeed seems to be a better = choice.

 

-Piyush

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = November 09, 2012 9:36 AM
To: Piyush Jain
Cc: Stefan = Santesson; i-barreira@izenpe.net; pkix@ietf.org
Subject: Re: = [pkix] What's the need to introduce fraudulently issued certificates in = OCSP

 

I'd reply an = unsigned response. "unauthorized" seems better than = "tryLater" (the later is obviously an invitation to retry, = which is undesired).

It's easier = to define in the CABForum context because of the 'B'rowsers = participation.

 

That's why I responded #3 to the stray = poll, with the hope that some constraints or guidelines could be set on = RP.

2012/11/9 Piyush Jain <piyush@ditenity.com>

Erwaan,

 

What do you think is the right response in such = cases?

One large public CA vendor returns unsigned =E2=80=98try = later=E2=80=99 for such requests. The reasoning is to not waste CPU = cycles and bandwidth on such requests because they have no practical = value.

 

-Piyush

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = November 09, 2012 9:10 AM
To: Piyush Jain
Cc: Stefan = Santesson; i-barreira@izenpe.net; pkix@ietf.org


Subject: Re: [pkix] What's the need to = introduce fraudulently issued certificates in = OCSP

 <= /o:p>

 <= /o:p>

2012/11/9 = Piyush Jain <piyush@ditenity.com>

The first = state that you refer to has no practical value. Clients don't = send
OCSP requests for randomly selected certificates. I think the = cause of

 <= /o:p>

They do. = Everyday. Some are purely bogus requests, some are crafted = ones.

The OCSP = responder has to respond to = those.

 

-- =
Erwann.



 

-- =
Erwann.

------=_NextPart_000_0102_01CDBE5F.CE6D1BC0-- From stefan@aaa-sec.com Fri Nov 9 10:22:50 2012 Return-Path: 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 787DA21F87FA for ; Fri, 9 Nov 2012 10:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 R7fTYrerl78c for ; Fri, 9 Nov 2012 10:22:49 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id BE8A021F86F0 for ; Fri, 9 Nov 2012 10:22:47 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 468995D612 for ; Fri, 9 Nov 2012 19:22:46 +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 7Ho0oeXP7YJz for ; Fri, 9 Nov 2012 19:22:45 +0100 (CET) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 304155D62E for ; Fri, 9 Nov 2012 19:22:45 +0100 (CET) Received: (qmail 29084 invoked from network); 9 Nov 2012 18:22:44 -0000 Received: from dhcp-170c.meeting.ietf.org (HELO [130.129.23.12]) (stefan@fiddler.nu@[130.129.23.12]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Nov 2012 18:22:44 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 09 Nov 2012 13:22:40 -0400 From: Stefan Santesson To: Erwann Abalea , Piyush Jain Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3435312164_25542144" Cc: "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:22:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3435312164_25542144 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Just for clarity, The current proposal does not preclude you from responding "unauthorized". It just allows you to respond "revoked". /Stefan From: Erwann Abalea Date: Friday, November 9, 2012 1:35 PM To: Piyush Jain Cc: Stefan Santesson , , "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP > I'd reply an unsigned response. "unauthorized" seems better than "tryLate= r" > (the later is obviously an invitation to retry, which is undesired). > It's easier to define in the CABForum context because of the 'B'rowsers > participation. >=20 > That's why I responded #3 to the stray poll, with the hope that some > constraints or guidelines could be set on RP. >=20 > 2012/11/9 Piyush Jain >> Erwaan, >> =20 >> What do you think is the right response in such cases? >> One large public CA vendor returns unsigned =8Ctry later=B9 for such request= s. >> The reasoning is to not waste CPU cycles and bandwidth on such requests >> because they have no practical value. >> =20 >> -Piyush >> =20 >>=20 >> From: Erwann Abalea [mailto:eabalea@gmail.com] >> Sent: Friday, November 09, 2012 9:10 AM >> To: Piyush Jain >> Cc: Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org >>=20 >> Subject: Re: [pkix] What's the need to introduce fraudulently issued >> certificates in OCSP >> =20 >>=20 >> =20 >>=20 >> 2012/11/9 Piyush Jain >>=20 >> The first state that you refer to has no practical value. Clients don't = send >> OCSP requests for randomly selected certificates. I think the cause of >>=20 >> =20 >>=20 >> They do. Everyday. Some are purely bogus requests, some are crafted ones= . >>=20 >> The OCSP responder has to respond to those. >>=20 >> =20 >> --=20 >> Erwann. >=20 >=20 >=20 > --=20 > Erwann. --B_3435312164_25542144 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Just for clarity,
=
The current proposal does not preclude you from responding "u= nauthorized". It just allows you to respond "revoked".

<= div>/Stefan

From: Er= wann Abalea <eabalea@gmail.com>=
Date: Friday, November 9, 2012 1:= 35 PM
To: Piyush Jain <piyush@ditenity.com>
Cc: Stefan Santesson <stefan@aaa-sec.com>, <i-barreira@izenpe.net>, "pkix@ietf.= org" <pkix@ietf.org>
Subject: Re: [pkix] What's the need to intro= duce fraudulently issued certificates in OCSP

I'd reply an unsigned response. "un= authorized" seems better than "tryLater" (the later is obviously an invitati= on to retry, which is undesired).
It's easier to define in the CABForum = context because of the 'B'rowsers participation.

That's why I responded #3 to the stray poll, with the hope = that some constraints or guidelines could be set on RP.

2012/11/9 Piyush Jain <piyush@ditenity.com>

Erwaan,

 

What do you think is the right response in such cases?=

One large public CA vendo= r returns unsigned ‘try later’ for such requests. The reasoning = is to not waste CPU cycles and bandwidth on such requests because they have = no practical value.

 

-Piyu= sh

 =

From: Erwann Abalea [mailto:eabalea@gmail.com]
= Sent: Friday, November 09, 2012 9:10 AM
To: Piyush Jain
= Cc: Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org


Subject: Re: [p= kix] What's the need to introduce fraudulently issued certificates in OCSP

 

 

2012/11/9 Piyush Jain <piyush@ditenity.com>

<= p class=3D"MsoNormal">The first state that you refer to has no practical value= . Clients don't send
OCSP requests for randomly selected certificates. I think the cause of

 

They do. Everyday. Some are purely bogus requests, some a= re crafted ones.

The OCSP r= esponder has to respond to those.

<= span class=3D"HOEnZb">

&= nbsp;

--
Erwann.




--
Erwann.
--B_3435312164_25542144-- From piyush@ditenity.com Fri Nov 9 10:38:55 2012 Return-Path: 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 7B7D621F86EF for ; Fri, 9 Nov 2012 10:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fUV+M0E0FR1g for ; Fri, 9 Nov 2012 10:38:55 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4C1121F86DD for ; Fri, 9 Nov 2012 10:38:54 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so3284316iak.31 for ; Fri, 09 Nov 2012 10:38:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=wGJWeQcv4n52MU5FmXRRb3Sxaxbl2MtkVN57JkcwJt8=; b=Aa1zyoBSJ0I23h7k4BpfmlgmK2yQWIG8PbH0iZOp38iF3yBHfaWzVc+rj5+JqxClMr SgArfKI8GknvEwR29g445mvqXF6drqjHKTFrht4eag9Dn6RGJx/8IQwewOLd0O/46qZ3 yK1rYZ6X3/t4J2z3HTHByi48jwn33s46mzWKPtFJncuCsqMnZDh49UY2xIJDy3nItwTB up4HtqjUnxfVezJrecR2uGwbHZ5EtH2Y4uC6Q6flWsNVWvNH6eMdiyK6t/qv0D1JqtYy GA831eun1n4cXLudSx2nNIp804KjFlaMHUMh0vBs/K28RxwgMpzipekEwbcIgL++rpDX 2R2Q== Received: by 10.50.159.198 with SMTP id xe6mr2191138igb.46.1352486333418; Fri, 09 Nov 2012 10:38:53 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id v12sm1987134igv.3.2012.11.09.10.38.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 10:38:52 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , , References: <00c501cdbe97$a04e0820$e0ea1860$@ditenity.com> In-Reply-To: Date: Fri, 9 Nov 2012 10:38:49 -0800 Message-ID: <012f01cdbea9$7776d780$66648680$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLJr+Dk17pBMhvuayGHfE3YPQeHrpXp7npQ Content-Language: en-us X-Gm-Message-State: ALoCoQmHZxXLFWZBqzbMKpQ2kDqD0WXOcbxLN4UwoK3Nmagk/+UZWnJsT5Gt5W5hRtVM8eO1lako Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:38:55 -0000 Stefan, Could you also respond to second part of my post, which I think was your primary reason for shooting down the alternative text that I proposed? I'm interested in knowing why revoked makes sense only for some cases of 'bad', but not for all cases of 'bad'. Don't you think it will be little presumptuous of this WG to pre-determine what those 'bad' certificates could be. We've been bitten once by assuming that signatures are enough to establish issuance. For your reference, here is the text that did not make it in your last response. >> My fear is that responders that adopts your text may want to include >> cert expiration into the determination of "bad". And then we have >> really >>created confusion as to what "revoked" really >> means. I> don't see any practical problem even if the responders decide to do so. >The arguments that are made for returning revoked for non-issued are applicable even for expired certificates or for that matter any bad certificate. Its more secure for clients who do not deal with expired >certificates correctly - same as revoked for 'non-issued', which is more secure for clients who do not deal with 'unknown' correctly. >BTW - I think that above text is actually clearer in conveying the changed meaning, from just 'revocation status' to negative proof. From piyush@ditenity.com Fri Nov 9 10:46:22 2012 Return-Path: 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 CB5F621F870F for ; Fri, 9 Nov 2012 10:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.531 X-Spam-Level: X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SXcBo98FtDmF for ; Fri, 9 Nov 2012 10:46:21 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0419221F8713 for ; Fri, 9 Nov 2012 10:46:20 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so7076856iec.31 for ; Fri, 09 Nov 2012 10:46:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=ATg36jCu1Hxb+nhl5Y+qbecq7cTm7ta0ig011rbTMiA=; b=jeHM1+Y142Y5LOUr2zLRxmpeoEFN3nXXS1eFepFlmfr9QN7V4W3hG3JXumoZ7iaMuv bNz34sC9OlUu2GDPTBpnP+3Am3SA7nr2a7xKtKfz5vQ3J+NktUK6ktnKN3kJ9yvKudNl ipq+EonkuBKcApLGuf8Uhb7mLtD2rKm8Logm0Q8squ6FpuhMq+J5gbsab6HPHSyqWgY6 FO6Ah5G8XktyRdxA+61XvWHTGO/6i8H2F3JD5P/VwYBUmlmg369zG25NdZNdewDrcCWA SK7zrz2hHZLNjNsQVhf/f+uNQGpX0+Wh9gikZUrxY0lHrYn3lmkd3WDEnle6d/I163aK eAlQ== Received: by 10.42.101.11 with SMTP id c11mr10764341ico.52.1352486780616; Fri, 09 Nov 2012 10:46:20 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s20sm1989174igs.10.2012.11.09.10.46.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 10:46:19 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Erwann Abalea'" References: In-Reply-To: Date: Fri, 9 Nov 2012 10:46:16 -0800 Message-ID: <013401cdbeaa$81e70090$85b501b0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0135_01CDBE67.73C60A80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIHsQZOzQwH/6Z6mhgI6UGIzW5KGJdt8RZA Content-Language: en-us X-Gm-Message-State: ALoCoQlbDYE9jhor8aKcLK5zAp9bnoa+SCqSr6tkAmyXZLohPGvZ61vqJqrtcI7NRAT4LOZqDFwR Cc: pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:46:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0135_01CDBE67.73C60A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My apologies Stefan. I was not trying to question if changing the meaning of revoked makes sense. That issue has been put to rest. I think that most folks believe that changing the meaning of revoked to imply a negative assertion (beyond revocation status) about the certificate makes sense. From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Friday, November 09, 2012 9:23 AM To: Erwann Abalea; Piyush Jain Cc: i-barreira@izenpe.net; pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Just for clarity, The current proposal does not preclude you from responding "unauthorized". It just allows you to respond "revoked". /Stefan From: Erwann Abalea Date: Friday, November 9, 2012 1:35 PM To: Piyush Jain Cc: Stefan Santesson , , "pkix@ietf.org" Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP I'd reply an unsigned response. "unauthorized" seems better than "tryLater" (the later is obviously an invitation to retry, which is undesired). It's easier to define in the CABForum context because of the 'B'rowsers participation. That's why I responded #3 to the stray poll, with the hope that some constraints or guidelines could be set on RP. 2012/11/9 Piyush Jain Erwaan, What do you think is the right response in such cases? One large public CA vendor returns unsigned 'try later' for such requests. The reasoning is to not waste CPU cycles and bandwidth on such requests because they have no practical value. -Piyush From: Erwann Abalea [mailto:eabalea@gmail.com] Sent: Friday, November 09, 2012 9:10 AM To: Piyush Jain Cc: Stefan Santesson; i-barreira@izenpe.net; pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP 2012/11/9 Piyush Jain The first state that you refer to has no practical value. Clients don't send OCSP requests for randomly selected certificates. I think the cause of They do. Everyday. Some are purely bogus requests, some are crafted ones. The OCSP responder has to respond to those. -- Erwann. -- Erwann. ------=_NextPart_000_0135_01CDBE67.73C60A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My apologies Stefan.  I was not trying to question if changing = the meaning of revoked makes sense. That issue has been put to rest. I = think that most folks believe that changing the meaning of revoked to = imply a negative assertion (beyond revocation status) about the = certificate makes sense.

 

 

From:= = Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, = November 09, 2012 9:23 AM
To: Erwann Abalea; Piyush = Jain
Cc: i-barreira@izenpe.net; = pkix@ietf.org
Subject: Re: [pkix] What's the need to introduce = fraudulently issued certificates in = OCSP

 

Just for clarity,

 

The current proposal does not preclude you from responding = "unauthorized". It just allows you to respond = "revoked".

 

/Stefan

 

From: Erwann Abalea <eabalea@gmail.com>
Date: = Friday, November 9, 2012 1:35 PM
To: Piyush Jain <piyush@ditenity.com>
Cc:= Stefan Santesson <stefan@aaa-sec.com>, <i-barreira@izenpe.net>, = "pkix@ietf.org" <pkix@ietf.org>
Subject: = Re: [pkix] What's the need to introduce fraudulently issued = certificates in OCSP

 

I'd reply an unsigned response. "unauthorized" seems better = than "tryLater" (the later is obviously an invitation to = retry, which is undesired).

It's easier to define in the CABForum context because of the 'B'rowsers = participation.

 

That's why I responded #3 to the stray poll, with the hope that some = constraints or guidelines could be set on = RP.

2012/11/9 Piyush Jain <piyush@ditenity.com>

<= div>

Erwaan,

 

What do you think is the right response in such cases?

One large public CA vendor returns unsigned ‘try later’ = for such requests. The reasoning is to not waste CPU cycles and = bandwidth on such requests because they have no practical = value.

 

-Piyush

 

= From:= Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = November 09, 2012 9:10 AM
To: Piyush Jain
Cc: Stefan = Santesson; i-barreira@izenpe.net; pkix@ietf.org


Subject: Re: [pkix] What's the need to introduce = fraudulently issued certificates in = OCSP

 

 

2012/11/9 Piyush Jain <piyush@ditenity.com>

<= div>

The first state that you refer to has no practical = value. Clients don't send
OCSP requests for randomly selected = certificates. I think the cause of

 

They do. Everyday. Some are purely bogus requests, = some are crafted ones.

The OCSP responder has to respond to = those.

 

-- =
Erwann.



 

-- =
Erwann.

------=_NextPart_000_0135_01CDBE67.73C60A80-- From stefan@aaa-sec.com Fri Nov 9 12:47:07 2012 Return-Path: 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 4677421F873F for ; Fri, 9 Nov 2012 12:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 ToXoENgyOMYA for ; Fri, 9 Nov 2012 12:47:06 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 99E3121F8739 for ; Fri, 9 Nov 2012 12:47:05 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 39FFB5DA89 for ; Fri, 9 Nov 2012 21:47:04 +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 Ti0rxf3jJRfj for ; Fri, 9 Nov 2012 21:47:03 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id CD7AF5DA64 for ; Fri, 9 Nov 2012 21:47:03 +0100 (CET) Received: (qmail 34666 invoked from network); 9 Nov 2012 20:47:03 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.220]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Nov 2012 20:47:03 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 09 Nov 2012 15:47:02 -0400 From: Stefan Santesson To: Piyush Jain , , Message-ID: Thread-Topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP In-Reply-To: <012f01cdbea9$7776d780$66648680$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:47:07 -0000 Piyush, We are walking on a mine field because we have to respect a huge deployed base that needs to work and be in compliance also after the update. I get scared of using a such broad term such as "bad" as reason for responding revoked of reasons in my previous mail. If it leads to responders responding revoked because the certificate has expired, then we could create some serious problems. At, least I'm not sure that it is safe. That is why I don't like your generic approach. To go down that path would require us to take a huge step back in the process and explore the consequences thoroughly. I'm reluctant to do that at this stage. You may have noticed how every new detail stirs up huge discussions :) /Stefan On 11/9/12 2:38 PM, "Piyush Jain" wrote: >Stefan, > >Could you also respond to second part of my post, which I think was your >primary reason for shooting down the alternative text that I proposed? > I'm interested in knowing why revoked makes sense only for some cases of >'bad', but not for all cases of 'bad'. Don't you think it will be little >presumptuous of this WG to pre-determine what those 'bad' certificates >could >be. We've been bitten once by assuming that signatures are enough to >establish issuance. > >For your reference, here is the text that did not make it in your last >response. > >>> My fear is that responders that adopts your text may want to include >>> cert expiration into the determination of "bad". And then we have >>> really >>>created confusion as to what "revoked" really >>> means. > >I> don't see any practical problem even if the responders decide to do so. >>The arguments that are made for returning revoked for non-issued are >applicable even for expired certificates or for that matter any bad >certificate. Its more secure for clients who do not deal with expired >>certificates correctly - same as revoked for 'non-issued', which is more >secure for clients who do not deal with 'unknown' correctly. >>BTW - I think that above text is actually clearer in conveying the >>changed >meaning, from just 'revocation status' to negative proof. > > > From piyush@ditenity.com Fri Nov 9 14:35:45 2012 Return-Path: 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 4B19821F86BA for ; Fri, 9 Nov 2012 14:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 sEKCINGHmJLK for ; Fri, 9 Nov 2012 14:35:44 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE72821F86B8 for ; Fri, 9 Nov 2012 14:35:44 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so7384113iec.31 for ; Fri, 09 Nov 2012 14:35:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=ScF/96JZ4dTD0cWyf/gvB9mum7uLfbk3LRVJWsofS+g=; b=l4pYsyEenkJ+vMfijpEu36TUNm6cWncjWOeKpGHZYTRGz/iNPBEdUVs0j97K4hlyIt t9Fowi13U3WRkX8NkKIR5jxwnL8v0yToJMurE9hOCMvRU+XhqubU8hoYdMkfRtn47BqS WdC3hSOizkNqGybAojAWzlt7ZSRC2n+XXUorjxEQz9Y/2xnUN5Dm9+1A6cWztwnL6kJb z1zqbYBrUaEYT+PisWx+3qMJpWkYX8QooB9SAH03S9KCA/quhjW3XJYf1PYvZMlTcOYb 9eWaNV7o+h+MtWWVKt0/YJ1zvZXGFVeDLpbS+u+SrMrhhSEBHZllW7g3uGW1ENrG9XL2 khfQ== Received: by 10.43.97.8 with SMTP id ci8mr11492798icc.28.1352500544219; Fri, 09 Nov 2012 14:35:44 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id x7sm2477736igk.8.2012.11.09.14.35.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 14:35:42 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , , References: <012f01cdbea9$7776d780$66648680$@ditenity.com> In-Reply-To: Date: Fri, 9 Nov 2012 14:34:46 -0800 Message-ID: <017d01cdbeca$8d637870$a82a6950$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH/sdsYBJeSvvqj0EB7cTnzPNyfN5d+IvSg Content-Language: en-us X-Gm-Message-State: ALoCoQlp0Vdyn3VXI1lo12GQ04bIdoaVK8/RUpQthUm5+X2qg7/VEdXW7jJJ4WWoB0rZ4Iup1qSC Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 22:35:45 -0000 > > Piyush, > > We are walking on a mine field because we have to respect a huge deployed > base that needs to work and be in compliance also after the update. [Piyush] Agree with that assessment. Every change that is proposed here should be evaluated based on its impact of the whole base, not just on a single requirement > > I get scared of using a such broad term such as "bad" as reason for > responding revoked of reasons in my previous mail. > If it leads to responders responding revoked because the certificate has > expired, then we could create some serious problems. [Piyush] Stefan - we are still discussing the impact of introducing non-issued on how other deployments which use revocation reason, revocation date, CRLs as backup revocation check mechanism are affected. My proposed change just moves those discussions out of this WG puts the onus on implementers who decide to deploy their responder this way. > At, least I'm not sure that it is safe. [Piyush] I think you are pretty comfortable with the notion that only responders who decided to respond this way are affected and that none of the clients are affected by this. This was your reasoning all along and that reasoning still applies to the alternative text. > > That is why I don't like your generic approach. > To go down that path would require us to take a huge step back in the > process and explore the consequences thoroughly. > I'm reluctant to do that at this stage. [Piyush] Again - what consequences? It only affects the responders who want to use revoked this way and it does not require changes in any of the clients. The new text also communicates the change precisely and concisely. Revoked, now implies any negative assertion about the certificate, not just a revoked status. The benefit is obvious. Allows CAB forum responders to be compliant and allows OCSP to abstain from making judgments on their choice. With your proposal, at the minimum we'll need to update OCSP text to provide guidance on how this affects other fields and also on the security implications. Plus, it would be restrictive if tomorrow we find that there is another use case where it makes sense for the responder to make a negative assertion about the certificate. BTW, I bet if you do a straw poll asking what the responder should return for a certificate that cannot be trusted, you will still find that majority will vote for revoked. > > You may have noticed how every new detail stirs up huge discussions :) > [Piyush] I think only the ones where opinions are divided lead to huge discussions. Discussions die if everyone is in agreement :). From pkix@inbox.lv Mon Nov 12 09:18:41 2012 Return-Path: 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 99B3221F86E1 for ; Mon, 12 Nov 2012 09:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] 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 3MQiJtYJqKHr for ; Mon, 12 Nov 2012 09:18:41 -0800 (PST) Received: from shark3.inbox.lv (shark3.inbox.lv [89.111.3.83]) by ietfa.amsl.com (Postfix) with ESMTP id A590221F86E4 for ; Mon, 12 Nov 2012 09:18:40 -0800 (PST) Received: by shark3.inbox.lv (Postfix, from userid 1000) id 9FA0F105C1; Mon, 12 Nov 2012 19:18:32 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark3-plain-b64d2.inbox.lv (Postfix) with ESMTP id 88E6F105B1 for ; Mon, 12 Nov 2012 19:18:32 +0200 (EET) Received: from localhost ([10.0.1.20]) by localhost (shark3.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id Hn0ZN8POpx6f for ; Mon, 12 Nov 2012 19:18:32 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Mon, 12 Nov 2012 19:18:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w10.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 Message-ID: <1352740712.50a12f6872fee@mail.inbox.lv> Date: Mon, 12 Nov 2012 19:18:32 +0200 From: "Andris Berzins" To: pkix@ietf.org User-Agent: Inbox.lv Webmail Subject: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:20:25 -0000 >From RFC 3280: "The signatureAlgorithm field contains the identifier for the cryptographic= algorithm used by the CA to sign this certificate." "This field MUST contain the same algorithm identifier as the signature fie= ld in the sequence tbsCertificate (section 4.1.2.3)." If "signatureAlgorithm" and "signature" field has the same meaning, then wh= y the spec has been designed to include it twice? From housley@vigilsec.com Mon Nov 12 09:27:07 2012 Return-Path: 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 9EEEF21F847D for ; Mon, 12 Nov 2012 09:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, 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 I5Wn3DFdY-ap for ; Mon, 12 Nov 2012 09:27:05 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D0EDC21F847C for ; Mon, 12 Nov 2012 09:26:52 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 523939A4008; Mon, 12 Nov 2012 12:26:57 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ilLLLhN0PUpO; Mon, 12 Nov 2012 12:26:39 -0500 (EST) Received: from [192.168.2.105] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AA33E9A4002; Mon, 12 Nov 2012 12:26:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <1352740712.50a12f6872fee@mail.inbox.lv> Date: Mon, 12 Nov 2012 12:26:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C2B46D4-6B74-4C00-9ADD-8F0285691212@vigilsec.com> References: <1352740712.50a12f6872fee@mail.inbox.lv> To: "Andris Berzins" X-Mailer: Apple Mail (2.1085) Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:27:07 -0000 One is protected by the signature itself, and the other is not. Russ On Nov 12, 2012, at 12:18 PM, Andris Berzins wrote: > =46rom RFC 3280: > "The signatureAlgorithm field contains the identifier for the = cryptographic algorithm used by the CA to sign this certificate." > "This field MUST contain the same algorithm identifier as the = signature field in the sequence tbsCertificate (section 4.1.2.3)." >=20 > If "signatureAlgorithm" and "signature" field has the same meaning, = then why the spec has been designed to include it twice? >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pkix@inbox.lv Mon Nov 12 09:31:27 2012 Return-Path: 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 6267921F862E for ; Mon, 12 Nov 2012 09:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 78RSwhwHtSpi for ; Mon, 12 Nov 2012 09:31:26 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9F821F8623 for ; Mon, 12 Nov 2012 09:31:26 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id 69A8B67D4; Mon, 12 Nov 2012 19:31:21 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id 4745B6666; Mon, 12 Nov 2012 19:31:21 +0200 (EET) Received: from localhost ([10.0.1.13]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id lz2CnbaT723d; Mon, 12 Nov 2012 19:31:18 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Mon, 12 Nov 2012 19:31:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w3.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 Message-ID: <1352741478.50a13266a8a8e@mail.inbox.lv> Date: Mon, 12 Nov 2012 19:31:18 +0200 From: "Andris Berzins" To: "Russ Housley" User-Agent: Inbox.lv Webmail Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:31:27 -0000 Why does the signatureAlgorithm field has to be protected by signature itse= lf? Does it prevent some attacks? Why to include also non-protected duplicate? Quoting "Russ Housley" : > One is protected by the signature itself, and the other is not. >=20 > Russ >=20 >=20 > On Nov 12, 2012, at 12:18 PM, Andris Berzins wrote: >=20 >> From RFC 3280: >> "The signatureAlgorithm field contains the identifier for the cryptograp= hic=20 >>algorithm used by the CA to sign this certificate." >> "This field MUST contain the same algorithm identifier as the signature = fiel >>d in the sequence tbsCertificate (section 4.1.2.3)." >>=20 >> If "signatureAlgorithm" and "signature" field has the same meaning, then= why >> the spec has been designed to include it twice? >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Mon Nov 12 09:36:04 2012 Return-Path: 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 60BB321F8587 for ; Mon, 12 Nov 2012 09:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] 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 abpVT1K7e3mv for ; Mon, 12 Nov 2012 09:36:03 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3512E21F859C for ; Mon, 12 Nov 2012 09:36:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,764,1344225600"; d="scan'208";a="2405297" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 12 Nov 2012 12:35:37 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 12 Nov 2012 12:35:34 -0500 From: Santosh Chokhani To: Andris Berzins , Russ Housley Date: Mon, 12 Nov 2012 12:35:32 -0500 Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3A+5kGCIgJJmNNR/iHFr67AAM+CAAADx1w Message-ID: References: <1352741478.50a13266a8a8e@mail.inbox.lv> In-Reply-To: <1352741478.50a13266a8a8e@mail.inbox.lv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:36:04 -0000 While I cannot answer your question, the term "protected" is a bit too stro= ng. I would use the term, one is used in signature computation and the oth= er is not. Specifically, when EC and Discrete Log type algorithms are involved, you sh= ould not use parameters from either location. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of And= ris Berzins Sent: Monday, November 12, 2012 12:31 PM To: Russ Housley Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates Why does the signatureAlgorithm field has to be protected by signature itse= lf? Does it prevent some attacks? Why to include also non-protected duplicate? Quoting "Russ Housley" : > One is protected by the signature itself, and the other is not. >=20 > Russ >=20 >=20 > On Nov 12, 2012, at 12:18 PM, Andris Berzins wrote: >=20 >> From RFC 3280: >> "The signatureAlgorithm field contains the identifier for the=20 >>cryptographic algorithm used by the CA to sign this certificate." >> "This field MUST contain the same algorithm identifier as the=20 >>signature fiel d in the sequence tbsCertificate (section 4.1.2.3)." >>=20 >> If "signatureAlgorithm" and "signature" field has the same meaning,=20 >> then why the spec has been designed to include it twice? >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Nov 12 19:20:41 2012 Return-Path: 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 4212021F874D for ; Mon, 12 Nov 2012 19:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.087 X-Spam-Level: X-Spam-Status: No, score=-10.087 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 71X6MpNt8KbE for ; Mon, 12 Nov 2012 19:20:40 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 64BDC21F85C0 for ; Mon, 12 Nov 2012 19:20:39 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qAD3KaQf019101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2012 04:20:36 +0100 (MET) In-Reply-To: <1352740712.50a12f6872fee@mail.inbox.lv> To: Andris Berzins Date: Tue, 13 Nov 2012 04:19:13 +0100 (CET) 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: <20121113031913.5DD3E1A368@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 03:20:41 -0000 Andris Berzins wrote: > >From RFC 3280: > "The signatureAlgorithm field contains the identifier for the > cryptographic algorithm used by the CA to sign this certificate." > "This field MUST contain the same algorithm identifier as the > signature field in the sequence tbsCertificate (section 4.1.2.3)." > > If "signatureAlgorithm" and "signature" field has the same meaning, > then why the spec has been designed to include it twice? That looks like a historic artifact (=useless baggage) from an early X.509 design. In practice, many implementations completely ignore the signatureAlgorithm field inside the Certificate ToBeSigned and use the outer (unsigned) AlgId, i.e. ignoring that silly MUST in rfc3280 section 4.1.2.3. While the original idea might have been that one wanted to support ambiguous AlgId parameters that would have needed integrity protection, this option was killed by Certificate being the only signed object that contains a signatureAlgorithm property within the signed data. There is no such protection for the signatureAlgorithm AlgId in X.509 CRLs, nor in OCSP, nor in PKCS#7 / CMS. So it would probably amount to shooting oneself in the foot when creating AlgId parameters that need to be protected, because none such protection exists in other essential protocol PDUs that are typically used with X.509 certs. -Martin From i-barreira@izenpe.net Tue Nov 13 00:44:13 2012 Return-Path: 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 B811D21F8595 for ; Tue, 13 Nov 2012 00:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] 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 0sHjQ-k5pnw7 for ; Tue, 13 Nov 2012 00:44:12 -0800 (PST) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA921F8585 for ; Tue, 13 Nov 2012 00:44:11 -0800 (PST) Received: from ejlp023.ejgv ([212.55.29.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MDF002I549LXIB0@ektmail1mta2.euskaltel.es> for pkix@ietf.org; Tue, 13 Nov 2012 09:44:10 +0100 (CET) Received: from AFE03.ejsarea.net (afe03 [10.200.192.20]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id qAD8i1F9024844; Tue, 13 Nov 2012 09:44:01 +0100 Received: from AEX06.ejsarea.net ([10.200.198.15]) by AFE03.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Nov 2012 09:44:10 +0100 Date: Tue, 13 Nov 2012 09:44:08 +0100 From: i-barreira@izenpe.net In-reply-to: To: stefan@aaa-sec.com, pkix@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B061F8294@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [pkix] What's the need to introduce fraudulently issued certificates in OCSP Thread-index: Ac292sG00hBapIpERDmA612//W+8vgDn6LNQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <763539E260C37C46A0D6B340B5434C3B0615F46C@AEX06.ejsarea.net> X-OriginalArrivalTime: 13 Nov 2012 08:44:10.0272 (UTC) FILETIME=[0CC0EA00:01CDC17B] Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:44:13 -0000 Stefan, I know is something CABF is worried about, what I=B4m trying to say is = that this "solution" is not easy to implement, at least from my point of = view (a CA), and it wouldn=B4t help to prevent the CA to be attacked and = compromised, which is the main issue here. It=B4s a way forward solution = that does not prevent an attack and maybe not issuing fraudulent = certificates, but at least it=B4s better than doing nothing. I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Enviado el: jueves, 08 de noviembre de 2012 17:58 Para: Barreira Iglesias, I=F1igo; pkix@ietf.org Asunto: Re: [pkix] What's the need to introduce fraudulently issued = certificates in OCSP Inigo, You are not wrong. But you don't have to manage any white list to conform with the updated = OCSP spec. CAB Forum will require responders in their infrastructure to do it, so = this also seems to be an issue for the CAB Forum. /Stefan On 11/8/12 11:14 AM, "i-barreira@izenpe.net" = wrote: >Stefan, > >I think this is what the recent poll tries to do, say revoked for a non = >issued certificate, and this is what will happen. As said i voted=20 >option >1 but that does not mean that I=B4m agree with this situation because = at=20 >the end, the CA has to be revoked and for the OCSP responder knows what = >certs have been issued or not, then you=B4ll need to manage a kind of a = >big white list and this is not easy to implement. That=B4s it, I=B4m = not=20 >wrong whatsoever you want to call it > > >I=F1igo Barreira >Responsable del =C1rea t=E9cnica >i-barreira@izenpe.net >945067705 > > >ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta=20 >egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada=20 >(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,=20 >korreo honi erantzuna. KONTUZ! >ATENCION! Este mensaje contiene informacion privilegiada o confidencial = >a la que solo tiene derecho a acceder el destinatario. Si usted lo=20 >recibe por error le agradeceriamos que no hiciera uso de la informacion = >y que se pusiese en contacto con el remitente. > > >-----Mensaje original----- >De: Stefan Santesson [mailto:stefan@aaa-sec.com] Enviado el: jueves, 08 = >de noviembre de 2012 13:51 >Para: Barreira Iglesias, I=F1igo; pkix@ietf.org >Asunto: Re: [pkix] What's the need to introduce fraudulently issued=20 >certificates in OCSP > >Hi, > >On 11/8/12 5:27 AM, "i-barreira@izenpe.net" = wrote: > >>This "fix" tries to avoid that someone can issue a bogus certificate=20 >>and after that delete the log/registry of the issuance (This is the=20 >>Diginotar case). But this "fix" wouldn=B4t help/fix much: > >You go wrong already here, and thus the rest goes wrong as well. > >This is NOT what the fix attempts to do. > >This is what CAB Forum attempts to do. If you think the CAB Forum deals = >with this the wrong way, you should really take this up on their=20 >mailing list. > >This fix (The OCSP update in PKIX) simply allows CAB forum to do what=20 >they feel they need to do in one particular area. > >/Stefan > > > From prvs=06643b516f=rybar@nbusr.sk Tue Nov 13 00:53:46 2012 Return-Path: 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 B6BA721F8619 for ; Tue, 13 Nov 2012 00:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 bDu5ie0QIjC5 for ; Tue, 13 Nov 2012 00:53:46 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id D329421F860A for ; Tue, 13 Nov 2012 00:53:44 -0800 (PST) Message-Id: <201211130853.qAD8rdfM038657@mail.nbusr.sk> From: "Peter Rybar" To: "'Piyush Jain'" , "'Stefan Santesson'" , i-barreira@izenpe.net, pkix@ietf.org Date: Tue, 13 Nov 2012 09:53:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <017d01cdbeca$8d637870$a82a6950$@ditenity.com> Thread-Index: AQH/sdsYBJeSvvqj0EB7cTnzPNyfN5d+IvSggAVk0xA= X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.6 X-NAI-Spam-Version: 2.2.0.9309 : core <4400> : streams <857388> : uri <1266824> Subject: Re: [pkix] What's the need to introduce fraudulently issuedcertificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:53:46 -0000 Only when CA is/was compromised then "non-issued" certificates can/could = be created by such CA and only that case is the important one which must = be detected.=20 Randomly created serial numbers in OCSP request must be ignored as = unauthorized (quick unsigned response when all issued certificates are = known for OCSP responder) or unknown (general signed response). When the serial number of a "non-issued" certificate is a serial number = reused from correctly issued certificate (one of the cases described by = Stefan in points 2) or 3)) then only positive statement single extension = as a hash value of certificate whose status OCSP response provides is a = solution for detection of such attacks/problems. Relying parties can provide such detection to accreditation organization = or to the issuer of compromised CA certificate to make corrections. It is a wrong expectation that compromised CA will be able to provide = the correct data for the OCSP responder and OCSP responder will be able = to revoke such certificate as the "non-issued" certificate.=20 Once CA is compromised then it is unclear what else was also compromised = under CA key. [Stefan] I can't possibly come up with more than 3 states of a randomly selected = cert serial number: It is either: 1) Never issued (never included in any issued certificates by this CA). 2) Has been issued and is revoked. 3) Has been issued but is not revoked Peter Rybar -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Piyush Jain Sent: Friday, November 09, 2012 11:35 PM To: 'Stefan Santesson'; i-barreira@izenpe.net; pkix@ietf.org Subject: Re: [pkix] What's the need to introduce fraudulently = issuedcertificates in OCSP >=20 > Piyush, >=20 > We are walking on a mine field because we have to respect a huge = deployed > base that needs to work and be in compliance also after the update. [Piyush] Agree with that assessment. Every change that is proposed here should be evaluated based on its impact of the whole base, not just on a single requirement >=20 > I get scared of using a such broad term such as "bad" as reason for > responding revoked of reasons in my previous mail. > If it leads to responders responding revoked because the certificate = has > expired, then we could create some serious problems. [Piyush] Stefan - we are still discussing the impact of introducing non-issued on how other deployments which use revocation reason, = revocation date, CRLs as backup revocation check mechanism are affected.=20 My proposed change just moves those discussions out of this WG puts the = onus on implementers who decide to deploy their responder this way. > At, least I'm not sure that it is safe. [Piyush] I think you are pretty comfortable with the notion that only responders who decided to respond this way are affected and that none of = the clients are affected by this. This was your reasoning all along and that reasoning still applies to the alternative text. >=20 > That is why I don't like your generic approach. > To go down that path would require us to take a huge step back in the > process and explore the consequences thoroughly. > I'm reluctant to do that at this stage. [Piyush] Again - what consequences? It only affects the responders who = want to use revoked this way and it does not require changes in any of the clients.=20 The new text also communicates the change precisely and concisely. = Revoked, now implies any negative assertion about the certificate, not just a = revoked status. The benefit is obvious. Allows CAB forum responders to be compliant and allows OCSP to abstain from making judgments on their choice. With your proposal, at the minimum we'll need to update OCSP text to provide = guidance on how this affects other fields and also on the security implications. Plus, it would be restrictive if tomorrow we find that there is another = use case where it makes sense for the responder to make a negative assertion about the certificate. BTW, I bet if you do a straw poll asking what the responder should = return for a certificate that cannot be trusted, you will still find that = majority will vote for revoked. >=20 > You may have noticed how every new detail stirs up huge discussions :) >=20 [Piyush] I think only the ones where opinions are divided lead to huge discussions. Discussions die if everyone is in agreement :).=20 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From pkix@inbox.lv Tue Nov 13 01:29:12 2012 Return-Path: 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 D456221F8653 for ; Tue, 13 Nov 2012 01:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1] 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 dbNQ--gkk2SB for ; Tue, 13 Nov 2012 01:29:12 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6221F861D for ; Tue, 13 Nov 2012 01:29:11 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id 30E077009; Tue, 13 Nov 2012 11:29:07 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id 0BE157006; Tue, 13 Nov 2012 11:29:07 +0200 (EET) Received: from localhost ([10.0.1.11]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id JD27ghrPovJ9; Tue, 13 Nov 2012 11:29:06 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Tue, 13 Nov 2012 11:29:06 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w1.inbox.lv, l=en, compose=HTML X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19 Message-ID: <1352798946.50a212e2ba7d4@mail.inbox.lv> Date: Tue, 13 Nov 2012 11:29:06 +0200 From: "Andris Berzins" To: mrex@sap.com User-Agent: Inbox.lv Webmail Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:29:12 -0000
While the original idea might have been that one= wanted to support
ambiguous AlgId parameters that would have needed = integrity protection,

Why would integrity of AlgId parame= ters matter?
If using arbitrary AlgId parameters would allow to forge = signature, then forger could just put AlgId he needs under the forged signa= ture.
 
From piyush@ditenity.com Tue Nov 13 07:56:50 2012 Return-Path: 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 8056C21F86E2 for ; Tue, 13 Nov 2012 07:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iLQkjkzxg3oh for ; Tue, 13 Nov 2012 07:56:49 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84BEE21F86D9 for ; Tue, 13 Nov 2012 07:56:49 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so12097841iec.31 for ; Tue, 13 Nov 2012 07:56:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=Nb7MDVCu9Bk6toLwmeI9+wYvQPCELSxvNuHm0ocKJgM=; b=mLB5O+hsk/K99WZz2iJ304TgSkwgJrx1COEa+SX8wKxH1huV9FfmreM35VtLxC2yYH T1Yxep9c0Yq8deTg/WLLVrcv9XxtOsUJyoGhUzFiWJLFRjS5Is8RhYZHkONMQLAARBz7 qWuDJnCtqjA3wTOwK04Cgb2kON4eXK2AX4aUvuTIVbLGuTo3awM1cRdOT796iqew3xHb Cp04EgVSl6WSvBHL9erYHQwDjWRZ+71HZ/gHupQYOQKb1U/eKmGHemVYr9dv5nKZr1jK b8FO26dxV07hB3WFcAdtlicacxE/bfWh40lz3h5tseGC4yFORsQt7R7IQYEl5usdriOm tkZA== Received: by 10.50.150.167 with SMTP id uj7mr11503878igb.33.1352822207442; Tue, 13 Nov 2012 07:56:47 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id vq4sm10878935igb.10.2012.11.13.07.56.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 07:56:46 -0800 (PST) From: "Piyush Jain" To: "'Peter Rybar'" , "'Stefan Santesson'" , , References: <017d01cdbeca$8d637870$a82a6950$@ditenity.com> <201211130853.qAD8rdld038656@mail.nbusr.sk> In-Reply-To: <201211130853.qAD8rdld038656@mail.nbusr.sk> Date: Tue, 13 Nov 2012 07:56:42 -0800 Message-ID: <04c501cdc1b7$7ade3010$709a9030$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvZ7CPRQMRadv1aEE1tpLN/AyQtJckmO4w Content-Language: en-us X-Gm-Message-State: ALoCoQnw68y71S6M4E4/97u4PXWwv3kmnqtEqNHjdSzV16utKZyic/PqbaUh4GntNNu33lbCViED Subject: Re: [pkix] What's the need to introduce fraudulently issuedcertificates in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:56:50 -0000 Peter- I'm in complete agreement with you. I think that the reason to propose returning revoked for fraudulently = issued certificates is that many in CAB forum believe that this is the = right way and current text in OCSP does not allow them to do so. If that = flexibility needs to be provided, the simplest way to do it is to allow = them to return revoked for any certificate that they think cannot be = trusted, without endorsing any method that they use to make that = determination. As you said, non-issued is ambiguous because it can refer to any of the = following 1) Not present in CA database (this may include expired certs, random = serials not signed by CA cert, fraudulently issued certificates) 2) Never signed using the CA certificate 3) Signed using CA certificate fraudulently If people interpret it to be 1), it actually affects most of the = responders operated by public CAs because it essentially precludes = pre-signing. Two biggest public CAs in the U.S. use pre-signed OCSP = responses to meet the operational requirements of their infrastructure. For 2) , the best response is unsigned UNAUTHORIZED. At least one large = public CA vendor returns unsigned TRY_LATER for these cases. If CAs can differentiate between 2) and 3), they can simply mark = fraudulently issued certificates as revoked (even though that is not a = secure way to deal with the problem). > -----Original Message----- > From: Peter Rybar [mailto:rybar@nbusr.sk] > Sent: Tuesday, November 13, 2012 12:54 AM > To: 'Piyush Jain'; 'Stefan Santesson'; i-barreira@izenpe.net; = pkix@ietf.org > Subject: RE: [pkix] What's the need to introduce fraudulently > issuedcertificates in OCSP >=20 > Only when CA is/was compromised then "non-issued" certificates = can/could > be created by such CA and only that case is the important one which = must be > detected. > Randomly created serial numbers in OCSP request must be ignored as > unauthorized (quick unsigned response when all issued certificates are > known for OCSP responder) or unknown (general signed response). >=20 > When the serial number of a "non-issued" certificate is a serial = number > reused from correctly issued certificate (one of the cases described = by Stefan > in points 2) or 3)) then only positive statement single extension as a = hash > value of certificate whose status OCSP response provides is a solution = for > detection of such attacks/problems. > Relying parties can provide such detection to accreditation = organization or to > the issuer of compromised CA certificate to make corrections. >=20 > It is a wrong expectation that compromised CA will be able to provide = the > correct data for the OCSP responder and OCSP responder will be able to > revoke such certificate as the "non-issued" certificate. >=20 > Once CA is compromised then it is unclear what else was also = compromised > under CA key. >=20 > [Stefan] > I can't possibly come up with more than 3 states of a randomly = selected cert > serial number: > It is either: > 1) Never issued (never included in any issued certificates by this = CA). > 2) Has been issued and is revoked. > 3) Has been issued but is not revoked >=20 > Peter Rybar >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > Piyush Jain > Sent: Friday, November 09, 2012 11:35 PM > To: 'Stefan Santesson'; i-barreira@izenpe.net; pkix@ietf.org > Subject: Re: [pkix] What's the need to introduce fraudulently > issuedcertificates in OCSP >=20 > > > > Piyush, > > > > We are walking on a mine field because we have to respect a huge > > deployed base that needs to work and be in compliance also after the > update. > [Piyush] Agree with that assessment. Every change that is proposed = here > should be evaluated based on its impact of the whole base, not just on = a > single requirement > > > > I get scared of using a such broad term such as "bad" as reason for > > responding revoked of reasons in my previous mail. > > If it leads to responders responding revoked because the certificate > > has expired, then we could create some serious problems. > [Piyush] Stefan - we are still discussing the impact of introducing = non-issued > on how other deployments which use revocation reason, revocation date, > CRLs as backup revocation check mechanism are affected. > My proposed change just moves those discussions out of this WG puts = the > onus on implementers who decide to deploy their responder this way. >=20 >=20 > > At, least I'm not sure that it is safe. > [Piyush] I think you are pretty comfortable with the notion that only > responders who decided to respond this way are affected and that none = of > the clients are affected by this. This was your reasoning all along = and that > reasoning still applies to the alternative text. > > > > That is why I don't like your generic approach. > > To go down that path would require us to take a huge step back in = the > > process and explore the consequences thoroughly. > > I'm reluctant to do that at this stage. > [Piyush] Again - what consequences? It only affects the responders who > want to use revoked this way and it does not require changes in any of = the > clients. > The new text also communicates the change precisely and concisely. > Revoked, now implies any negative assertion about the certificate, not = just a > revoked status. >=20 > The benefit is obvious. Allows CAB forum responders to be compliant = and > allows OCSP to abstain from making judgments on their choice. With = your > proposal, at the minimum we'll need to update OCSP text to provide > guidance on how this affects other fields and also on the security > implications. > Plus, it would be restrictive if tomorrow we find that there is = another use > case where it makes sense for the responder to make a negative = assertion > about the certificate. >=20 > BTW, I bet if you do a straw poll asking what the responder should = return for > a certificate that cannot be trusted, you will still find that = majority will vote > for revoked. >=20 > > > > You may have noticed how every new detail stirs up huge discussions = :) > > > [Piyush] I think only the ones where opinions are divided lead to huge > discussions. Discussions die if everyone is in agreement :). >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Tue Nov 13 14:59:04 2012 Return-Path: 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 7B5CD21F86D3 for ; Tue, 13 Nov 2012 14:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 DykY4szn+dR8 for ; Tue, 13 Nov 2012 14:59:04 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C21D721F868C for ; Tue, 13 Nov 2012 14:59:03 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qADMx2cb018764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2012 23:59:02 +0100 (MET) In-Reply-To: <1352798946.50a212e2ba7d4@mail.inbox.lv> To: Andris Berzins Date: Tue, 13 Nov 2012 23:59:02 +0100 (CET) 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: <20121113225902.673731A36F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 22:59:04 -0000 Andris Berzins wrote: > >> While the original idea might have been that one wanted to support >> ambiguous AlgId parameters that would have needed integrity protection, > > Why would integrity of AlgId parameters matter? I honestly don't know. I was just plain guessing at what might have been the original motivation behind the addition of this useless baggage to TBSCertificate. As I wrote, I believe that MUST in section 4.1.2.3 of rfc3280, and its successor rfc5280 is silly. > > If using arbitrary AlgId parameters would allow to forge signature, > then forger could just put AlgId he needs under the forged signature. Probably. -Martin From DPKemp@missi.ncsc.mil Tue Nov 13 15:18:44 2012 Return-Path: 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 CDD3A21F8795 for ; Tue, 13 Nov 2012 15:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XAbOY+mGxNbX for ; Tue, 13 Nov 2012 15:18:44 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4F521F878F for ; Tue, 13 Nov 2012 15:18:44 -0800 (PST) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id qADNIgFh051146 for ; Tue, 13 Nov 2012 18:18:43 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.101]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0421.002; Tue, 13 Nov 2012 18:18:42 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: AQHNwfKA+/nyr9bpO06oOKLGS8Gp+ZfoZIUg Date: Tue, 13 Nov 2012 23:18:41 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC845052F75@clavin.missi.ncsc.mil> References: <1352798946.50a212e2ba7d4@mail.inbox.lv> <20121113225902.673731A36F@ld9781.wdf.sap.corp> In-Reply-To: <20121113225902.673731A36F@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:18:44 -0000 See RFC 6211 -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Tuesday, November 13, 2012 5:59 PM To: Andris Berzins Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates Andris Berzins wrote: > >> While the original idea might have been that one wanted to support=20 >> ambiguous AlgId parameters that would have needed integrity=20 >> protection, > > Why would integrity of AlgId parameters matter? I honestly don't know. I was just plain guessing at what might have been t= he original motivation behind the addition of this useless baggage to TBSCe= rtificate. As I wrote, I believe that MUST in section 4.1.2.3 of rfc3280, = and its successor rfc5280 is silly. > > If using arbitrary AlgId parameters would allow to forge signature,=20 > then forger could just put AlgId he needs under the forged signature. =20 Probably. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From pkix@inbox.lv Wed Nov 14 00:58:52 2012 Return-Path: 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 C0E9C21F856C for ; Wed, 14 Nov 2012 00:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 girGaRs+Wa5S for ; Wed, 14 Nov 2012 00:58:52 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id 972D021F8554 for ; Wed, 14 Nov 2012 00:58:51 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id 8ABA87089; Wed, 14 Nov 2012 10:58:46 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id 63EC67068 for ; Wed, 14 Nov 2012 10:58:46 +0200 (EET) Received: from localhost ([10.0.1.15]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id njDf9yGccJd3 for ; Wed, 14 Nov 2012 10:58:45 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Wed, 14 Nov 2012 10:58:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w5.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19 Message-ID: <1352883525.50a35d4552f19@mail.inbox.lv> Date: Wed, 14 Nov 2012 10:58:45 +0200 From: "Andris Berzins" To: pkix@ietf.org User-Agent: Inbox.lv Webmail Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 08:58:52 -0000 Quoting "Kemp, David P." : > See RFC 6211 "In an algorithm substitution attack, the attacker looks for a different al= gorithm that produces the same result as the=20 algorithm used by the signer. As an example, if the creator of the message= used SHA-1 as the digest algorithm to=20 hash the message content, then the attacker looks for a different hash algo= rithm that produces a result that is of the=20 same length, but with which it is easier to find collisions." Again, if the attacker can find colliding tbsCertificate content, he can as= well substitute AlgID in his colliding=20 tbsCertificate. Placing AlgID in content that will be hashed and then signe= d does not seem to help against algorithm=20 substitution attack. Placing AlgID directly under the signature as it is do= ne in PKCS#1 v.15 signature does actually=20 help against digest substitution attack. Tell me what I am missing here. >=20 >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of M= art >in Rex > Sent: Tuesday, November 13, 2012 5:59 PM > To: Andris Berzins > Cc: pkix@ietf.org > Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates >=20 > Andris Berzins wrote: >>=20 >>> While the original idea might have been that one wanted to support >>> ambiguous AlgId parameters that would have needed integrity >>> protection, >>=20 >> Why would integrity of AlgId parameters matter? >=20 > I honestly don't know. I was just plain guessing at what might have been= th >e original motivation behind the addition of this useless baggage to TBSCe= rt >ificate. As I wrote, I believe that MUST in section 4.1.2.3 of rfc3280, a= nd > its successor rfc5280 is silly. >=20 >=20 >>=20 >> If using arbitrary AlgId parameters would allow to forge signature, >> then forger could just put AlgId he needs under the forged signature. >=20 > Probably. >=20 >=20 > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Wed Nov 14 01:04:12 2012 Return-Path: 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 EA0EC21F8570 for ; Wed, 14 Nov 2012 01:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.774 X-Spam-Level: X-Spam-Status: No, score=-101.774 tagged_above=-999 required=5 tests=[AWL=0.475, 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 PeTpZWpXL3v8 for ; Wed, 14 Nov 2012 01:04:12 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 46AD821F84FB for ; Wed, 14 Nov 2012 01:04:11 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 588565B020 for ; Wed, 14 Nov 2012 10:04:08 +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 KNz78gQ3uz-D for ; Wed, 14 Nov 2012 10:04:08 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 195A95C22B for ; Wed, 14 Nov 2012 10:04:08 +0100 (CET) Received: (qmail 29517 invoked from network); 14 Nov 2012 09:04:07 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.109]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Nov 2012 09:04:07 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 14 Nov 2012 10:04:06 +0100 From: Stefan Santesson To: , Andris Berzins Message-ID: Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates In-Reply-To: <20121113225902.673731A36F@ld9781.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:04:13 -0000 Martin, Let's separate this. On 11/13/12 11:59 PM, "Martin Rex" wrote: >As I wrote, I believe that MUST in >section 4.1.2.3 of rfc3280, and its successor rfc5280 is silly. Yes, the original design to include the AlgID twice is kind of silly. Clearly an early redundant design. However, this is what it is now and it does not really hurt that much either. But the MUST in 5280 is NOT silly, because we don't know what we might break if we don't put it in there. /Stefan From stephen.farrell@cs.tcd.ie Wed Nov 14 01:30:01 2012 Return-Path: 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 CFBA721F8586 for ; Wed, 14 Nov 2012 01:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 Pof5n5hZoZ7x for ; Wed, 14 Nov 2012 01:30:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BD34E21F8581 for ; Wed, 14 Nov 2012 01:29:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32F2EBE38; Wed, 14 Nov 2012 09:29:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89hyyNOhnMeM; Wed, 14 Nov 2012 09:29:35 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.46.20.232]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7F051BE49; Wed, 14 Nov 2012 09:29:35 +0000 (GMT) Message-ID: <50A3647F.8050807@cs.tcd.ie> Date: Wed, 14 Nov 2012 09:29:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:30:02 -0000 On 11/14/2012 09:04 AM, Stefan Santesson wrote: > Yes, the original design to include the AlgID twice is kind of silly. > Clearly an early redundant design. I forget the details and so may be wrong, but early versions of X.509 (1988 maybe) were based on X.400's ASN.1 macro named "SIGNED" which adds the outer alg id along with the signature. At some point someone noticed that some hash-alg attacks might be allowed by that and the inner alg id was added. S. From d.w.chadwick@kent.ac.uk Wed Nov 14 01:43:32 2012 Return-Path: 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 DE2DA21F8581 for ; Wed, 14 Nov 2012 01:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BDXx9KfoMxUs for ; Wed, 14 Nov 2012 01:43:32 -0800 (PST) Received: from mx2.kent.ac.uk (mx2.kent.ac.uk [129.12.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 595A521F8555 for ; Wed, 14 Nov 2012 01:43:32 -0800 (PST) Received: from dhcp29b3.kent.ac.uk ([129.12.41.179]) by mx2.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1TYZVJ-0007fW-5o; Wed, 14 Nov 2012 09:43:29 +0000 Message-ID: <50A367C3.30708@kent.ac.uk> Date: Wed, 14 Nov 2012 09:43:31 +0000 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <50A3647F.8050807@cs.tcd.ie> In-Reply-To: <50A3647F.8050807@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:43:33 -0000 I thought it was the opposite. That no-one noticed that the Signed macro added the alg id as well as the signature, and thought it only added the signature, therefore put the alg id within the package to be signed. David On 14/11/2012 09:29, Stephen Farrell wrote: > > > On 11/14/2012 09:04 AM, Stefan Santesson wrote: >> Yes, the original design to include the AlgID twice is kind of silly. >> Clearly an early redundant design. > > I forget the details and so may be wrong, but early versions > of X.509 (1988 maybe) were based on X.400's ASN.1 macro named > "SIGNED" which adds the outer alg id along with the signature. > At some point someone noticed that some hash-alg attacks might > be allowed by that and the inner alg id was added. > > S. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From pgut001@cs.auckland.ac.nz Wed Nov 14 01:47:20 2012 Return-Path: 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 1FABD21F84A1 for ; Wed, 14 Nov 2012 01:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 m7fWVXJ9eElB for ; Wed, 14 Nov 2012 01:47:19 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 219C821F860D for ; Wed, 14 Nov 2012 01:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1352886437; x=1384422437; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=SlukfXqNMn7rX8O9MrKArkVLSNiSpGopcbPOmse5NlM=; b=PccrzVzRqkrWrFKdvenXnSHKwQvU3ylYeQODVkQ5FPWYZMwiwD1OO55P Wre6nLAcdryVxh98Nh1nPdM6lYtXgWApz29uRII4Wfqx4FlwNLj6URWGX Nl5BFzb8Te3fR22qrDEZL1WIyd86tHEHjWdu2wYXa7LahOCsDYzWNhb2d o=; X-IronPort-AV: E=Sophos;i="4.83,249,1352026800"; d="scan'208";a="156818831" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Nov 2012 22:47:16 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.145]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 22:47:15 +1300 From: Peter Gutmann To: "pkix@ietf.org" Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3CTQbC+RywSXa0Q2yWPG0h6awt7w== Date: Wed, 14 Nov 2012 09:47:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7331C5416E@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:47:20 -0000 Martin Rex writes:=0A= =0A= >I was just plain guessing at what might have been the original motivation= =0A= >behind the addition of this useless baggage to TBSCertificate.=0A= =0A= As others have pointed out it was added to prevent an OID-swapping attack= =0A= that's rendered irrelevant by PKCS #1 padding but is theoretically possible= if=0A= you use a sufficiently broken signature-formatting mechanism, e.g. raw RSA.= My=0A= code reads it and checks that it's a signing-capable PKC algorithm, but=0A= doesn't do any more than that. Since (apparently) no-one ever checks this = and=0A= so implementations that put the wrong OID in there have been deployed, this= is=0A= probably the safest thing to do.=0A= =0A= Given all the other useless baggage in X.509 in general, I don't see its=0A= presence as a big deal. If we wanted to remove all the stuff that isn't=0A= baggage there'd be very little left: A DNS name or email address, a link to= =0A= the signing cert for verification purposes, a key usage flag, some sort of= =0A= advertising field for the CA, and a signature.=0A= =0A= Peter.= From Johannes.Merkle@secunet.com Wed Nov 14 01:49:49 2012 Return-Path: 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 05C8F21F862D for ; Wed, 14 Nov 2012 01:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 OKH+YRgLMYni for ; Wed, 14 Nov 2012 01:49:48 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC221F860D for ; Wed, 14 Nov 2012 01:49:48 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 969EB1A0080 for ; Wed, 14 Nov 2012 10:49:46 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 1F46D1A0066 for ; Wed, 14 Nov 2012 10:49:38 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Nov 2012 10:49:37 +0100 Message-ID: <50A36930.1040605@secunet.com> Date: Wed, 14 Nov 2012 10:49:36 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <50A3647F.8050807@cs.tcd.ie> In-Reply-To: <50A3647F.8050807@cs.tcd.ie> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2012 09:49:38.0017 (UTC) FILETIME=[5C48FD10:01CDC24D] Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:49:49 -0000 > > I forget the details and so may be wrong, but early versions > of X.509 (1988 maybe) were based on X.400's ASN.1 macro named > "SIGNED" which adds the outer alg id along with the signature. > At some point someone noticed that some hash-alg attacks might > be allowed by that and the inner alg id was added. While I doubt the usefulness of the inner AlgID, the outer one can be needed when signature algorithms with message recovery are used. Although these are not common (among other reasons, due to IPR), but that might not have been anticipated in the early X.509 day. -- Johannes From stephen.farrell@cs.tcd.ie Wed Nov 14 01:54:26 2012 Return-Path: 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 1A50B21F8678 for ; Wed, 14 Nov 2012 01:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YiiMfVRXWlNT for ; Wed, 14 Nov 2012 01:54:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 088DE21F862C for ; Wed, 14 Nov 2012 01:54:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6454ABE38; Wed, 14 Nov 2012 09:54:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv7G+6OMlo7k; Wed, 14 Nov 2012 09:54:02 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.46.20.232]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A7EDBBE32; Wed, 14 Nov 2012 09:54:02 +0000 (GMT) Message-ID: <50A36A3A.6020603@cs.tcd.ie> Date: Wed, 14 Nov 2012 09:54:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Johannes Merkle References: <50A3647F.8050807@cs.tcd.ie> <50A36930.1040605@secunet.com> In-Reply-To: <50A36930.1040605@secunet.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:54:26 -0000 On 11/14/2012 09:49 AM, Johannes Merkle wrote: > >> >> I forget the details and so may be wrong, but early versions >> of X.509 (1988 maybe) were based on X.400's ASN.1 macro named >> "SIGNED" which adds the outer alg id along with the signature. >> At some point someone noticed that some hash-alg attacks might >> be allowed by that and the inner alg id was added. > > While I doubt the usefulness of the inner AlgID, Yep. > the outer one can be needed when signature algorithms with message > recovery are used. Although these are not common (among other reasons, due to IPR), but that might not have been > anticipated in the early X.509 day. You're right, but I don't recall that being raised then. I think it was literally just down to reusing the ASN.1 macro in the spec. (Prosaic variant wins, almost every time;-) S. From pgut001@cs.auckland.ac.nz Wed Nov 14 02:01:38 2012 Return-Path: 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 D4A3421F8556 for ; Wed, 14 Nov 2012 02:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IJTWjZkdlKxi for ; Wed, 14 Nov 2012 02:01:36 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4A421F8548 for ; Wed, 14 Nov 2012 02:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1352887296; x=1384423296; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=fcuNw8L5ABwQEl8OtbeiiRBj63FDJ4Jp9wQRPT9fRV0=; b=Y8x3+ymxmm6hN3WcTbAJFbrzDEbo22ZDi+VJ+Imx8myN9jeNnT5cDo/4 5+ZSBrOLsCvO5G+QUNiqOsT0OqH4Hp9bPIp0QUAqyjtTXNS1bVTh8MVSz M7EfUyAl5S6ddTGY1lli8tts+ibKAFX8+ghcDswiEDEmp5jkdLvVuVjpZ c=; X-IronPort-AV: E=Sophos;i="4.83,249,1352026800"; d="scan'208";a="156819423" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Nov 2012 23:01:35 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.145]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 23:01:34 +1300 From: Peter Gutmann To: "pkix@ietf.org" Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3CTwd4G0d52qEUQfinISrs9c9C0Q== Date: Wed, 14 Nov 2012 10:01:34 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7331C541AD@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:01:39 -0000 I wrote:=0A= =0A= >If we wanted to remove all the stuff that isn't baggage there'd be very=0A= >little left: A DNS name or email address, a link to the signing cert for= =0A= >verification purposes, a key usage flag, some sort of advertising field fo= r=0A= >the CA, and a signature.=0A= =0A= Sorry, hit ^D too quickly: We'd also need some sort of FUOU field for the D= oD=0A= crowd alongside the other bits.=0A= =0A= Peter.=0A= From prvs=76656ade0a=dbrown@certicom.com Wed Nov 14 07:34:12 2012 Return-Path: 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 7769621F85E2 for ; Wed, 14 Nov 2012 07:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 eeXlA0EzR95f for ; Wed, 14 Nov 2012 07:34:11 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B321F85DB for ; Wed, 14 Nov 2012 07:34:11 -0800 (PST) X-AuditID: 0a41282f-b7fad6d000001f25-c0-50a3b9e5b46f Received: from XCT103CNC.rim.net (xct103cnc.rim.net [10.65.161.203]) by mhs060cnc.rim.net (SBG) with SMTP id A1.09.07973.5E9B3A05; Wed, 14 Nov 2012 09:33:57 -0600 (CST) Received: from XCT116CNC.rim.net (10.65.161.216) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 14 Nov 2012 10:33:56 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT116CNC.rim.net ([::1]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 10:33:55 -0500 From: Dan Brown To: 'Andris Berzins' , "pkix@ietf.org" Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: AQHNwPoE6fKbaDOH0U6ldZ0jAVBTt5fpeBiA Date: Wed, 14 Nov 2012 15:33:55 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF50E5F8E@XMB111CNC.rim.net> References: <1352740712.50a12f6872fee@mail.inbox.lv> In-Reply-To: <1352740712.50a12f6872fee@mail.inbox.lv> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXC5bjwtO7TnYsDDL5fEbG4eLDIYsLFo4wO TB5Llvxk8vi28zZTAFNUA6NNUmJJWXBmep6+nU1iXl5+SWJJqkJKanGyrZJPanpijkJAUWZZ YnKlgktmcXJOYmZuapGSQmaKrZKJkkJBTmJyam5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1L zk/JzEu3VfIM9te1sDC11DVUstNN6OTJOL59EWvBB86KA1POMjcwLuPoYuTkkBAwkTg7+QYT hC0mceHeerYuRi4OIYFVjBKbzv1mhnBWMkos/bGKCcKZwyhx9e93ZpAWNgFViftHz4HZIgKu EidbN4KNEhZwl9hyYTVLFyMHUNxD4ttcdogSI4mO7T9YQGwWoNaWrWvB4rwCbhLv9m4Bs4WA Ljq+qYUZpJVTwFTi4mJZkDCjgKzE7rPXwaYzC4hL3HoyH+poAYkle84zQ9iiEi8f/2OFsBUl Vr+6xQZRryOxYPcnKFtbYtnC18wQawUlTs58wgKxVkHiyvV9LBMYxWchWTELSfssJO2zkLQv YGRZxSiYm1FsYGaQnJesV5SZq5eXWrKJEZw8NPR3ML59b3GIUYCDUYmHd1H34gAh1sSy4src Q4wSHMxKIryX1gOFeFMSK6tSi/Lji0pzUosPMboCA2gisxR3cj4wseWVxBsbGODmKInzXhWd EyAkkA5MVtmpqQWpRTBzmDg4QfZwSYkUA1NOalFiaUlGPCgxxhcDU6NUA2N6Yf73rXOsBcQS vv5YOmXGqp2v/lqle7kmlUbzJqStbryU93/frD3uFf/3pXXX5umtWLvPqC1AZtOyIB73qaY7 Grs9fS54rW7R66yLq7Ey1umo+3VPa1VTyba00s73vvfVE894/v7Ytl+Psf8ap//W776pD4vy 8vd92zT3d8SHlerPPtRJKCmxFGckGmoxFxUnAgDPKeLqXwMAAA== Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:34:12 -0000 Hi Andris, Burt Kaliski prepared some slides explain the security motivation, and the i= nefficacy, of "hash firewalls": http://www.rsa.com/rsalabs/staff/bios/bkaliski/publications/hash-firewalls/k= aliski-hash-firewalls-ct-rsa-2002.ppt I suspect that the inner signature-alg-id in the TBSCertificate is similarly= ineffective, but I am not totally sure. Best regards, Daniel Brown Research In Motion Limited > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Andris Berzins > Sent: Monday, November 12, 2012 12:19 PM > To: pkix@ietf.org > Subject: [pkix] redundant AlgorithmIdentifier in X.509 certificates > > From RFC 3280: > "The signatureAlgorithm field contains the identifier for the > cryptographic algorithm used by the CA to sign this certificate." > "This field MUST contain the same algorithm identifier as the signature > field in the sequence tbsCertificate (section 4.1.2.3)." > > If "signatureAlgorithm" and "signature" field has the same meaning, > then why the spec has been designed to include it twice? > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From era@x500.eu Wed Nov 14 09:01:20 2012 Return-Path: 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 2C6E521F8680 for ; Wed, 14 Nov 2012 09:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 maSKWeXmQ51c for ; Wed, 14 Nov 2012 09:01:19 -0800 (PST) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7021F85DA for ; Wed, 14 Nov 2012 09:01:19 -0800 (PST) Received: from ([62.44.135.123]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id YCP13415; Wed, 14 Nov 2012 18:01:15 +0100 From: "Erik Andersen" To: "'Peter Gutmann'" , References: <9A043F3CF02CD34C8E74AC1594475C7331C5416E@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7331C5416E@uxcn10-2.UoA.auckland.ac.nz> Date: Wed, 14 Nov 2012 18:01:12 +0100 Message-ID: <000601cdc289$a8f55190$fadff4b0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3CTQbC+RywSXa0Q2yWPG0h6awt7wAPGCTA Content-Language: da Subject: [pkix] useless bagage in X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:01:20 -0000 Hi Peter, It would be nice to get some examples of useless baggage in X.509. Erik Andersen -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Peter Gutmann Sendt: 14. november 2012 10:47 Til: pkix@ietf.org Emne: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates Martin Rex writes: >I was just plain guessing at what might have been the original=20 >motivation behind the addition of this useless baggage to = TBSCertificate. As others have pointed out it was added to prevent an OID-swapping = attack that's rendered irrelevant by PKCS #1 padding but is theoretically = possible if you use a sufficiently broken signature-formatting mechanism, e.g. = raw RSA. My code reads it and checks that it's a signing-capable PKC = algorithm, but doesn't do any more than that. Since (apparently) no-one ever = checks this and so implementations that put the wrong OID in there have been deployed, this is probably the safest thing to do. Given all the other useless baggage in X.509 in general, I don't see its presence as a big deal. If we wanted to remove all the stuff that isn't baggage there'd be very little left: A DNS name or email address, a link = to the signing cert for verification purposes, a key usage flag, some sort = of advertising field for the CA, and a signature. Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From era@x500.eu Wed Nov 14 09:07:09 2012 Return-Path: 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 CC11E21F86A5 for ; Wed, 14 Nov 2012 09:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 YzEi6T34FaPn for ; Wed, 14 Nov 2012 09:07:09 -0800 (PST) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 76B5021F8689 for ; Wed, 14 Nov 2012 09:07:08 -0800 (PST) Received: from ([62.44.135.123]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id YCU16357 for ; Wed, 14 Nov 2012 18:06:57 +0100 From: "Erik Andersen" To: "PKIX" References: <50A3647F.8050807@cs.tcd.ie> <50A367C3.30708@kent.ac.uk> In-Reply-To: <50A367C3.30708@kent.ac.uk> Date: Wed, 14 Nov 2012 18:06:55 +0100 Message-ID: <001201cdc28a$74e2fa00$5ea8ee00$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3CTInexHRiSWktRWKnllt2UrXnlwAPVuUg Content-Language: da Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:07:09 -0000 For your information, the 2012 edition of X.509 has updated the = signature field to: The signature field contains the algorithm identifier for the algorithm = and hash function used by the CA in signing the certificate (e.g., md5WithRSAEncryption, sha-1WithRSAEncryption, id-dsa-with-sha1, etc.). = It shall be the same value as used in the algorithmIdentifier component of = the SIGNATURE data type when signing the public-key certificate. NOTE 2 =96 This field is redundant except possibly for its participation = in matching certificates (see 11.3.2). -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = David Chadwick Sendt: 14. november 2012 10:44 Til: Stephen Farrell Cc: Stefan Santesson; pkix@ietf.org Emne: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates I thought it was the opposite. That no-one noticed that the Signed macro added the alg id as well as the signature, and thought it only added the signature, therefore put the alg id within the package to be signed. David On 14/11/2012 09:29, Stephen Farrell wrote: > > > On 11/14/2012 09:04 AM, Stefan Santesson wrote: >> Yes, the original design to include the AlgID twice is kind of silly. >> Clearly an early redundant design. > > I forget the details and so may be wrong, but early versions of X.509=20 > (1988 maybe) were based on X.400's ASN.1 macro named "SIGNED" which=20 > adds the outer alg id along with the signature. > At some point someone noticed that some hash-alg attacks might be=20 > allowed by that and the inner alg id was added. > > S. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Wed Nov 14 09:22:23 2012 Return-Path: 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 E724621F8660 for ; Wed, 14 Nov 2012 09:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 XM14PWxjN2Hu for ; Wed, 14 Nov 2012 09:22:23 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BE50121F85A5 for ; Wed, 14 Nov 2012 09:22:12 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qAEHMANd002529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Nov 2012 18:22:11 +0100 (MET) In-Reply-To: <001201cdc28a$74e2fa00$5ea8ee00$@eu> To: Erik Andersen Date: Wed, 14 Nov 2012 18:22:10 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20121114172210.9CDEF1A377@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: PKIX Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:22:24 -0000 Erik Andersen wrote: > For your information, the 2012 edition of X.509 has updated the signature > field to: >=20 > The signature field contains the algorithm identifier for the algorithm a= nd > hash function used by the CA in signing the certificate (e.g., > md5WithRSAEncryption, sha-1WithRSAEncryption, id-dsa-with-sha1, etc.). It > shall be the same value as used in the algorithmIdentifier component of t= he > SIGNATURE data type when signing the public-key certificate. > NOTE 2 =96 This field is redundant except possibly for its participation = in > matching certificates (see 11.3.2). One thing that I do not like about some of the requirements in PKIX (rfc5280 and predecessors) and X.509, is the lack of distinction at which party a requirement is directed. My rule of thumb: if it is not explicitly listed as a seperate item in the basic path validation, then it is directed at conforming CAs, not RPs doing certificate path validation. Requiring that the signatureAlgorithm field within TBSCertificate and on the outer signature element are the same is perfectly valid for conforming CAs upon issuing certs. But I consider it silly with respect to RPs to consciously compare the values of these fields during certificate path validation. (as indicated by the note, such a comparision may be implicit by comparison of a certificate hash or certificate blob). -Martin From pgut001@cs.auckland.ac.nz Wed Nov 14 14:42:33 2012 Return-Path: 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 1301F21F8877 for ; Wed, 14 Nov 2012 14:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PGWMs9Atk8yV for ; Wed, 14 Nov 2012 14:42:32 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02C9B21F884D for ; Wed, 14 Nov 2012 14:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1352932952; x=1384468952; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ZrWWfc0omGdHix0pdS6yhEZVX54hSOnELaFCDmlRsK4=; b=YHxFO4qd91KzFKJG82SPbE7xX0PAzurxBVqGY3ME6MruXJDdLAjJRBa+ gsLfboaLe9rVd6vp0Ta7vbJBZgv5DaXTX81Dn8DUWFRVwGgFoJ7t3kXs5 Nn/juS6C6xu5K9NwMSdYlrr9YuIVRkWBSqRD5hUmuPLi62jPLvawVMrYh Y=; X-IronPort-AV: E=Sophos;i="4.83,253,1352026800"; d="scan'208";a="156922288" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Nov 2012 11:42:30 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 15 Nov 2012 11:42:30 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.145]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 11:42:29 +1300 From: Peter Gutmann To: Dan Brown Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3CuVPB1pGlhWMURRqGBi5KYJb3qw== Date: Wed, 14 Nov 2012 22:42:29 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7331C54659@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:42:33 -0000 Dan Brown writes:=0A= =0A= >Burt Kaliski prepared some slides explain the security motivation, and the= =0A= >inefficacy, of "hash firewalls":=0A= >=0A= >http://www.rsa.com/rsalabs/staff/bios/bkaliski/publications/hash-firewalls= /kaliski-hash-firewalls-ct-rsa-2002.ppt=0A= =0A= None of those applied to PKCS #1, or any newer replacements like PSS. They= =0A= only worked for 9796 (which is insecure enough anyway without this extra=0A= problem), DSA if you allow something other than SHA-1 (or DSA-2 and SHA-2),= =0A= and some other signature scheme that no-one ever uses. So while it can be = an=0A= issue, the simple solution is "don't do that, then". Or, for current=0A= implementations, "don't change what you're currently doing".=0A= =0A= Peter.=0A= From hallam@gmail.com Wed Nov 14 18:27:10 2012 Return-Path: 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 7E66D21E8039 for ; Wed, 14 Nov 2012 18:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.289 X-Spam-Level: X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Cqg7zsHa77zs for ; Wed, 14 Nov 2012 18:27:09 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEE5921E8034 for ; Wed, 14 Nov 2012 18:27:09 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1255251oag.31 for ; Wed, 14 Nov 2012 18:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WnNgt569j/4n6RdsLdqR8dByjmTjvoWgoBDLbJ7+ea8=; b=MBGrxVTKzbHLNpa3vH5ULuXJAcMpytrxrQo5bJkF6l5sBJBm5sUqc/3gyVjoKNQfO3 /c/ryQ7AORNxA6RwNNdJPJD6okgj2N4MFtDO1inYKqPZnUQbsXoQnKJMuL0GbwxYgnpl Vq3dVpmiCx6Lxys9DEqNvtK8pHGB8/j5CLhwHpIgVJ+u9osuzYg+X/MBlueYbbu2SVH8 rpiijHeq0tDa/xgOUEQY5qh+Cj2+W7CxzNlJT2e8I7xxBWVXoXVxUzmdcEkvGDqwwBM/ oxTazp5qQcW4YlVHOJo5/MslQ3H9LeQ4p0oxVar+9+2AgNd+KXk/O1gljIfk9XVwrLg0 L7Bw== MIME-Version: 1.0 Received: by 10.182.54.103 with SMTP id i7mr22474317obp.62.1352946429260; Wed, 14 Nov 2012 18:27:09 -0800 (PST) Received: by 10.76.27.103 with HTTP; Wed, 14 Nov 2012 18:27:08 -0800 (PST) Date: Wed, 14 Nov 2012 21:27:08 -0500 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: multipart/alternative; boundary=14dae93a113d50f2e904ce7f6372 Subject: [pkix] Update to OCSP Must Staple draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 02:27:10 -0000 --14dae93a113d50f2e904ce7f6372 Content-Type: text/plain; charset=ISO-8859-1 Following conversations at IETF I have removed the minimum version attribute from the Must Staple draft. Basically Ryan Sleevi explained the pool of woe and misery that is TLS version numbering and so I dropped it. The updated version of the draft is http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-03.txt This is not a WG item of course but is of interest to folk here. The main outstanding issue is whether the OID should be cut from the IETF PKIX arc or some other arc (e.g. CABForum). After discussion with Russ (the secretary) and Stephan (as WG chair) it seems that the best approach would be to put it on the PKIX arc so that people know where to look to find the description (i.e. an RFC). This might raise an issue that the WG may need to consider before it closes, namely what the ongoing registration policy is going to be for PKIX OIDs when the registration function reverts to IANA. -- Website: http://hallambaker.com/ --14dae93a113d50f2e904ce7f6372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Following conversations at IETF I have removed the minimum version attribut= e from the Must Staple draft. Basically Ryan Sleevi explained the pool of w= oe and misery that is TLS version numbering and so I dropped it.

The updated version of the draft is



This is not a WG item of course but is o= f interest to folk here.

The main outstanding issu= e is whether the OID should be cut from the IETF PKIX arc or some other arc= (e.g. CABForum). After discussion with Russ (the secretary) and Stephan (a= s WG chair) it seems that the best approach would be to put it on the PKIX = arc so that people know where to look to find the description (i.e. an RFC)= .

This might raise an issue that the WG may need to consi= der before it closes, namely what the ongoing registration policy is going = to be for PKIX OIDs when the registration function reverts to IANA.

--
Website: http://h= allambaker.com/

--14dae93a113d50f2e904ce7f6372-- From mrex@sap.com Wed Nov 14 18:34:52 2012 Return-Path: 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 AD52A21F8203 for ; Wed, 14 Nov 2012 18:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.141 X-Spam-Level: X-Spam-Status: No, score=-10.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 FXBtOKE7hNPS for ; Wed, 14 Nov 2012 18:34:52 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E94E121F8487 for ; Wed, 14 Nov 2012 18:34:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qAF2Yo7L012809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 03:34:50 +0100 (MET) In-Reply-To: <1352883525.50a35d4552f19@mail.inbox.lv> To: Andris Berzins Date: Thu, 15 Nov 2012 03:34:50 +0100 (CET) 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: <20121115023450.0F4201A377@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 02:34:52 -0000 Andris Berzins wrote: > "Kemp, David P." : >> >> See RFC 6211 > > "In an algorithm substitution attack, the attacker looks for a different > algorithm that produces the same result as the algorithm used by the > signer. As an example, if the creator of the message used SHA-1 > as the digest algorithm to hash the message content, then the attacker > looks for a different hash algorithm that produces a result that is of the > same length, but with which it is easier to find collisions." > > Again, if the attacker can find colliding tbsCertificate content, > he can as well substitute AlgID in his colliding tbsCertificate. > Placing AlgID in content that will be hashed and then signed does > not seem to help against algorithm substitution attack. Placing AlgID > directly under the signature as it is done in PKCS#1 v.15 signature > does actually help against digest substitution attack. > > Tell me what I am missing here. I believe your observation is correct. If you look at the MD5 collision attack to produce the rogue SSL CA cert, it would have exactly ZERO impact for the attackers if they would have to modify the signatureAlgorithm parameter within TBSCertificate (along with all the other stuff that they modify inside the cert). What did/does provide mitigation is the Hash-OID inside PKCS#1 v1.5, and the randomizing of the serial number that was adopted by the CABforum Baseline Requirements as a result of this proof-of-concept rogue SSL CA cert creation. -Martin PS: I haven't reviewed or evaluated rfc6211, but I would not be surprised if it turns out to not provide any additional security. From era@x500.eu Thu Nov 15 07:28:09 2012 Return-Path: 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 1DA5A21F8938 for ; Thu, 15 Nov 2012 07:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 6JjeaY3Il39a for ; Thu, 15 Nov 2012 07:28:08 -0800 (PST) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 33CD121F8937 for ; Thu, 15 Nov 2012 07:28:08 -0800 (PST) Received: from ([62.44.135.195]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id ZAR75905 for ; Thu, 15 Nov 2012 16:28:05 +0100 From: "Erik Andersen" To: "PKIX" References: <1352740712.50a12f6872fee@mail.inbox.lv> <20121113031913.5DD3E1A368@ld9781.wdf.sap.corp> In-Reply-To: <20121113031913.5DD3E1A368@ld9781.wdf.sap.corp> Date: Thu, 15 Nov 2012 16:28:03 +0100 Message-ID: <001b01cdc345$d0028c00$7007a400$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3BTedAD01xRlCrQaC5fOxUtLtKdgB9tHww Content-Language: da Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 15:28:09 -0000 Hi Martin, A CRL has a signature field in X.509 and so has attribute certificate, = so X.509 is consistent. Erik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Martin Rex Sendt: 13. november 2012 04:19 Til: Andris Berzins Cc: pkix@ietf.org Emne: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates Andris Berzins wrote: > >From RFC 3280: > "The signatureAlgorithm field contains the identifier for the =20 > cryptographic algorithm used by the CA to sign this certificate." > "This field MUST contain the same algorithm identifier as the =20 > signature field in the sequence tbsCertificate (section 4.1.2.3)." >=20 > If "signatureAlgorithm" and "signature" field has the same meaning,=20 > then why the spec has been designed to include it twice? That looks like a historic artifact (=3Duseless baggage) from an early = X.509 design. In practice, many implementations completely ignore the signatureAlgorithm field inside the Certificate ToBeSigned and use the = outer (unsigned) AlgId, i.e. ignoring that silly MUST in rfc3280 section = 4.1.2.3. While the original idea might have been that one wanted to support = ambiguous AlgId parameters that would have needed integrity protection, this = option was killed by Certificate being the only signed object that contains a signatureAlgorithm property within the signed data. There is no such protection for the signatureAlgorithm AlgId in X.509 = CRLs, nor in OCSP, nor in PKCS#7 / CMS. So it would probably amount to = shooting oneself in the foot when creating AlgId parameters that need to be protected, because none such protection exists in other essential = protocol PDUs that are typically used with X.509 certs. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From prvs=3666cd2b18=dbrown@certicom.com Thu Nov 15 09:42:47 2012 Return-Path: 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 C449C21F88D5 for ; Thu, 15 Nov 2012 09:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 dFFqsFkvOz1P for ; Thu, 15 Nov 2012 09:42:47 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id AB41821F89FC for ; Thu, 15 Nov 2012 09:42:46 -0800 (PST) X-AuditID: 0a41282f-b7fad6d000001f25-2c-50a5298b38fe Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) by mhs060cnc.rim.net (SBG) with SMTP id 17.7F.07973.B8925A05; Thu, 15 Nov 2012 11:42:36 -0600 (CST) Received: from XCT112CNC.rim.net (10.65.161.212) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 15 Nov 2012 12:42:35 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT112CNC.rim.net ([::1]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 12:42:34 -0500 From: Dan Brown To: 'Peter Gutmann' Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3CuVPB6fKbaDOH0U6ldZ0jAVBTtwAkG/Bw Date: Thu, 15 Nov 2012 17:42:34 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF50E656B@XMB111CNC.rim.net> References: <9A043F3CF02CD34C8E74AC1594475C7331C54659@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7331C54659@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIKsWRmVeSWpSXmKPExsXC5bjwrG6P5tIAg51T2SxevnvOanHxYJHF hItHGR2YPS42HmDyWLLkJ5PHt523mQKYoxoYbZISS8qCM9Pz9O1sEvPy8ksSS1IVUlKLk22V fFLTE3MUAooyyxKTKxVcMouTcxIzc1OLlBQyU2yVTJQUCnISk1NzU/NKbJUSCwpS81KU7LgU MIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWuoZKdbkInT8aqExPYChrFK86+LWtgvC7UxcjJ ISFgIvG48TkThC0mceHeerYuRi4OIYFVjBLdfw8zQjgrGSUmNS1lhXDmMEosPD6bDaSFTUBV 4v7Rc8wgtoiAvsTEL0/B4swCrhLzprwAs4UF3CW2XFjN0sXIAVTjIfFtLjtEuZHE1lNbwcIs QGPezjEDCfMKuEl0fn/LCmILCQRJrJj5jgXE5hQIltiy4T3YREYBWYndZ68zQWwSl7j1ZD7U AwISS/acZ4awRSVePv7HCmErSqx+dQvqMh2JBbs/QdnaEssWvmaG2CsocXLmExaIvQoSV67v Y5nAKDELyYpZSNpnIWmfhaR9ASPLKkbB3IxiAzOD5LxkvaLMXL281JJNjOA0o6G/g/Hte4tD jAIcjEo8vJ8klwYIsSaWFVfmHmKU4GBWEuH1lAMK8aYkVlalFuXHF5XmpBYfYnQFBtBEZinu 5HxgCswriTc2MMDNURLnvSo6J0BIIB2YwrJTUwtSi2DmMHFwguzhkhIpBiai1KLE0pKMeFC6 jC8GJkypBkbrJvu/2x5U37L24j4/k+mckHWj5cVV/EbF5xrM3Q5vLa27tdDSacnPk3m8Hjxd hfdffXn7TVIk1HGq1jmZUI4TzP8WVe+3vfu2NdnmfePxzngx+1/N5fe/1PPy21XX+DutLTIp 2hPa1ewgPFPufqJeS+JJ9wcyEQrKS+/MCp24/rT0JPf/LkosxRmJhlrMRcWJADB8BAd0AwAA Cc: "pkix@ietf.org" Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:42:47 -0000 Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] writes: > Dan Brown writes: > > >Burt Kaliski prepared some slides: > > > >http://www.rsa.com/rsalabs/staff/bios/bkaliski/publications/hash-firewall= s/kaliski-hash-firewalls-ct-rsa-2002.ppt > > None of those applied to PKCS #1, or any newer replacements like PSS. Slides 24--29 address PKCS #1 version 1.5, which uses a hash OID as a "hash= firewall". Slide 27 describes an attack that involves "registering" a mali= cious OID for a strong hash. (Aside: this is similar in nature to Vaudenay'= s domain parameter attack on DSA, in that some parameters of the signature a= lgorithm are malicious.) It seems that X.509/PKIX additional "signature fir= ewall" would prevent the strong hash attack on Slide 27, but not the weak ha= sh attack on Slide 26. Regarding Slide 26, I'm not sure if "weak hash attac= k" is a sensible phrase. Replacing "weak" by "attackable" makes it sound li= ke a tautology. > and some other signature scheme that no-one ever uses. So while it can > be an > issue, the simple solution is "don't do that, then". Or, for current Don't do what? Use "some other signatures schemes"? Bother with checking t= he signed signature algorithm? > implementations, "don't change what you're currently doing". > It was a fair question to ask if any attacks are prevented by signing the si= gnature algorithm. If yes, then the verifier/RP really should ensure that s= ignature algorithm used for verification is the signed algorithm identifier.= If no, then it is harmless for the verifier to ignore the inner signature= algorithm, because it is safely tucked inside some signed data (assuming th= e signature verifies). RFC 5280 in Section 4.1.2.3 seems to specify a MUST that the RP checks inner= =3D=3Douter. The question about redundancy of the OIDs can be rephrased as f= ollows. Is it possible for an attacker to forge a certificate that is valid= except that inner and outer signature algorithm identifiers do not match. = To be precise, it would be valid in the sense that the signature verifies u= nder the algorithm specified by the outer identifier. The way I see it, such a mismatch-forgery would mean the outer-identified si= gnature algorithm is "forgeable", under any reasonable definition of forgeab= le. As long the verifier uses a secure signature algorithm, then she can re= ly on the outer signature alone. Therefore, the inner identifier is redunda= nt. The Slide 27 attack can create this type of mismatching forged certificate.= Even so, the conclusion above about the insecurity of the outer signature= still holds, because the outer signature would be PKCS #1 v. 1.5 with a pad= ding that includes a long malicious OID and it would be unreasonable to deem= such a malicious signature algorithm as secure. Best regards, Dan --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From DPKemp@missi.ncsc.mil Thu Nov 15 12:24:08 2012 Return-Path: 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 E63CF21F85FC for ; Thu, 15 Nov 2012 12:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FjtwiJDpGPXR for ; Thu, 15 Nov 2012 12:24:07 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9494721F85FA for ; Thu, 15 Nov 2012 12:24:06 -0800 (PST) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id qAFKO4ls085256 for ; Thu, 15 Nov 2012 15:24:05 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.101]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0421.002; Thu, 15 Nov 2012 15:24:04 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3CuVPB+/nyr9bpO06oOKLGS8Gp+QAkG/BwAAjG9pA= Date: Thu, 15 Nov 2012 20:24:03 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8450580EF@clavin.missi.ncsc.mil> References: <9A043F3CF02CD34C8E74AC1594475C7331C54659@uxcn10-2.UoA.auckland.ac.nz> <810C31990B57ED40B2062BA10D43FBF50E656B@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF50E656B@XMB111CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:24:08 -0000 -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Dan= Brown > The way I see it, such a mismatch-forgery would mean the outer-identified > signature algorithm is "forgeable", under any reasonable definition of > forgeable. As long the verifier uses a secure signature algorithm, then > she can rely on the outer signature alone. Therefore, the inner identifi= er is redundant. =20 Does there exist a signature algorithm (e.g., MD4withRSA) that is known or = suspected to be forgeable (using Dobbertin or other attacks)? If so, does PKIX maintain a whitelist of unforgeable signature algorithms s= uch that if verifiers support only whitelisted algorithms, the inner identi= fier is redundant? If there is a nonempty set of forgeable algorithms supported by any verifie= r application claiming to be X.509 or PKIX conformant, then either the algo= rithm whitelist must exist and be included in X.509 conformance, or the inn= er/outer MUST requirement is justified. From pkix@inbox.lv Thu Nov 15 12:32:04 2012 Return-Path: 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 A1F8F21F85CD for ; Thu, 15 Nov 2012 12:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_27=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1] 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 NyeG2OtCbueu for ; Thu, 15 Nov 2012 12:32:04 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF621F8552 for ; Thu, 15 Nov 2012 12:32:03 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id E7FA26CDE; Thu, 15 Nov 2012 22:31:59 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id BED566CCD for ; Thu, 15 Nov 2012 22:31:59 +0200 (EET) Received: from localhost ([10.0.1.11]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id AJT33UGAd_0G for ; Thu, 15 Nov 2012 22:31:56 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 15 Nov 2012 22:31:56 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w1.inbox.lv, l=lv, compose=HTML X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19 Message-ID: <1353011516.50a5513c05af5@mail.inbox.lv> Date: Thu, 15 Nov 2012 22:31:56 +0200 From: "Andris Berzins" To: pkix@ietf.org User-Agent: Inbox.lv Webmail Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:32:04 -0000
Does there exist a signature algorithm (e.g., MD= 4withRSA) that is known or suspected to be forgeable (using Dobbertin or ot= her attacks)?

If so, does PKIX maintain a whitelist of unforge= able signature algorithms such that if verifiers support only whitelisted a= lgorithms, the inner identifier is redundant?

As we curre= ntly have discussed, inner identifier will not help you in case of forgeabl= e MD4withRSA. What helps is PKCS#1 v.15 signature that contains identifier= =2E






If t= here is a nonempty set of forgeable algorithms supported by any verifier ap= plication claiming to be X.509 or PKIX conformant, then either the algorith= m whitelist must exist and be included in X.509 conformance, or the inner/o= uter MUST requirement is justified.
_________________________________= ______________
pkix mailing list
pkix@ietf.org
https://ww= w.ietf.org/mailman/listinfo/pkix


 
From prvs=5666767ed4=dbrown@certicom.com Thu Nov 15 13:56:38 2012 Return-Path: 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 ABD3521F8A00 for ; Thu, 15 Nov 2012 13:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 BEyr8pnBk089 for ; Thu, 15 Nov 2012 13:56:38 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id AB2EE21F87A7 for ; Thu, 15 Nov 2012 13:56:36 -0800 (PST) X-AuditID: 0a412830-b7f296d0000048ed-03-50a561853f89 Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 12.58.18669.68165A05; Thu, 15 Nov 2012 15:41:26 -0600 (CST) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 16:41:25 -0500 From: Dan Brown To: "'Kemp, David P.'" , "pkix@ietf.org" Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3CuVPB6fKbaDOH0U6ldZ0jAVBTtwAkG/BwABPTIYAACffskA== Date: Thu, 15 Nov 2012 21:41:25 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF50E6655@XMB111CNC.rim.net> References: <9A043F3CF02CD34C8E74AC1594475C7331C54659@uxcn10-2.UoA.auckland.ac.nz> <810C31990B57ED40B2062BA10D43FBF50E656B@XMB111CNC.rim.net> <5B1D7E570380A64989D4C069F7D14BC8450580EF@clavin.missi.ncsc.mil> In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8450580EF@clavin.missi.ncsc.mil> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXC5bjwgm5b4tIAg4aV/BYt/xcxWlw8WOTA 5LFkyU8mj/Mr5rIFMEU1MNokJZaUBWem5+nb2STm5eWXJJakKqSkFifbKvmkpifmKAQUZZYl JlcquGQWJ+ckZuamFikpZKbYKpkoKRTkJCan5qbmldgqJRYUpOalKNlxKWAAG6CyzDyF1Lzk /JTMvHRbJc9gf10LC1NLXUMlO92ETp6MY//+sxc8E6mYs28WawNjp2AXIyeHhICJxM/bj9kh bDGJC/fWs3UxcnEICbQzSazef44FwtnKKHF94g1GkCo2AVWJ+0fPMYPYIgKBEp9mz2MCsYUF 3CW2XFgN1MABFPeQ+DaXHaLESeLA91Vg5SxArT9XXwAbwyvgJrFg+nJWiPmXGCU2zjgO1sAp 4CuxdeoXsCJGAVmJ3Wevg81nFhCXuPVkPhPEpQISS/acZ4awRSVePv7HCmErSqx+dYsNol5H YsHuT1C2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYBXMzig3MDJPzkvWK MnP18lJLNjGC04GGwQ7G9+8tDjEKcDAq8fAeklkaIMSaWFZcmXuIUYKDWUmE11MOKMSbklhZ lVqUH19UmpNafIjRFRgsE5mluJPzgakqryTe2MAAN0dJnPeq6JwAIYF0YPrJTk0tSC2CmcPE wQmyh0tKpBiYRFKLEktLMuJBqS6+GJjspBoYC8PurfpSlvnQqZz7a++M8777pbqY788/zb3W d/e0L4ZrVto2ubOzLok5OnOdCtvnlyUfk1Yr8mlz31D1nH33wLK2jP2r/Y+tYBfqOLlJNCH3 +E+N6jLJq4J3vhpet/PvSgp4fd8p+3/ktTkdM8MW6XKK79Ayesvx30Dppmxe+aLQvAdXKjpm K7EUZyQaajEXFScCAJbqsghIAwAA Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:56:38 -0000 > -----Original Message----- > From: Kemp, David P. > Sent: Thursday, November 15, 2012 3:24 PM > > Does there exist a signature algorithm (e.g., MD4withRSA) that is known > or suspected to be forgeable (using Dobbertin or other attacks)? > > If so, does PKIX maintain a whitelist of unforgeable signature > algorithms such that if verifiers support only whitelisted algorithms, > the inner identifier is redundant? Well, I now see that RFC 5280 does not require "any particular cryptographic= algorithms", so it technically allows forgeable algorithm (although I think= most would read it as tacitly disallowing known-to-be-insecure algorithms).= Despite this general and open wording, I think most implementers would act= ually construe RFCs 3279, 4055, 4491, 5480, and 5758 as a de facto list of a= cceptable signature algorithms. Taking the more open position raises the question of what qualifies as a "si= gnature algorithm" or "cryptographic algorithm"? Presumably, the commonly-u= sed empty-string-digital-signature-algorithm does not qualify, because nobod= y claims it is secure. Some algorithms are so rarely-used (e.g. NTRUSign, G= Q signatures, raw RSA or raw ElGamal) that they may be irrelevant to PKIX. Or, am I misinterpreting the point of PKIX? Does PKIX only really specify a= format only, leaving security totally to the implementers? Aside: do you say "unforgeable" ironically in the sense that nobody, not eve= n PKIX, can make such a promise of unforgeability? Well, even if you didn'= t mean that, I'd have to respond and say that the best any crypto standard c= an do is to specify the state of art, implying not-yet-known-to-be-too-broke= n algorithms, but even still crypto implementations have to watch out for ne= w developments which the standards cannot anticipate. > > If there is a nonempty set of forgeable algorithms supported by any > verifier application claiming to be X.509 or PKIX conformant, then > either the algorithm whitelist must exist and be included in X.509 > conformance, or the inner/outer MUST requirement is justified. Yes, if security is a PKIX goal. More generally, would it be justified to a= llow such a verifier application to claim to be PKIX conformant even if it e= nforced outer=3D=3Dinner? If it uses sufficiently insecure signature verifi= cation algorithm, then a forger could send it forged certificates. In other= words, you said "either A or B [or both]", and I'm saying "A". > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pgut001@cs.auckland.ac.nz Thu Nov 15 17:32:36 2012 Return-Path: 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 6608421E8051 for ; Thu, 15 Nov 2012 17:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4PRoDdafF26g for ; Thu, 15 Nov 2012 17:32:35 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE17821E8043 for ; Thu, 15 Nov 2012 17:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1353029555; x=1384565555; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=c/Nl/+7QuFOVgCDrAUatA6KymEgLJpoUeedIfwbYbuE=; b=XIMZeWLu3crTbOQekEkGtpMGza/IE6e9b9ogDZNef7f3yq/24t1ZSSs4 4dfWKgKp1TObP/3077SU0px0qCSPGj7BqtD8q+NOnCacYZIak/9D/fFCX g2+N1jwxS3qVDLWKSNX3l9wgk/msCmtYT3+E5xtIQD/OOPIxHetP1SLmp s=; X-IronPort-AV: E=Sophos;i="4.83,260,1352026800"; d="scan'208";a="157168122" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Nov 2012 14:32:31 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.145]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 14:32:30 +1300 From: Peter Gutmann To: "pkix@ietf.org" Thread-Topic: [pkix] redundant AlgorithmIdentifier in X.509 certificates Thread-Index: Ac3Dmj4BhCcNwMvmQbuMxIXd0hXY0g== Date: Fri, 16 Nov 2012 01:32:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7331C54EF2@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:32:36 -0000 Dan Brown writes:=0A= >Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] writes:=0A= >> Dan Brown writes:=0A= >>=0A= >> >Burt Kaliski prepared some slides:=0A= >>=0A= >> >http://www.rsa.com/rsalabs/staff/bios/bkaliski/publications/hash-firewa= lls/kaliski-hash-firewalls-ct-rsa-2002.ppt=0A= >>=0A= >> None of those applied to PKCS #1, or any newer replacements like PSS.=0A= =0A= >Slide 27 describes an attack that involves "registering" a malicious OID f= or=0A= >a strong hash.=0A= =0A= While that's a theoretical weakness, the chances of registering a really od= d-=0A= looking OID for a signature algorithm and then persuading Microsoft, Mozill= a,=0A= and Google to adopt it is roughly, oh, zero. This could make it the Mongol= ian=0A= Stupidity Test of crypto (the original Mongolian Stupidity Test was "Can I= =0A= borrow your sword?").=0A= =0A= >Don't do what? Use "some other signatures schemes"?=0A= =0A= Yeah. If you're currently using PKCS #1 then don't suddenly switch to ISO= =0A= 9796 with its track record of problems (and non-use in pretty much any=0A= Internet standard, although it is used by banks in Europe), or GQ, or=0A= something else.=0A= =0A= >The question about redundancy of the OIDs can be rephrased as follows. Is= it=0A= >possible for an attacker to forge a certificate that is valid except that= =0A= >inner and outer signature algorithm identifiers do not match.=0A= =0A= We need to distinguish between "is it possible" and "is it practical". If = you=0A= set up the conditions just right then yes, it's possible. Mind you it's al= so=0A= possible to forge any signature of any kind, you just need a lot of time.= =0A= However in terms of asking "is it practical", against currently-deployed=0A= mechanisms, no, and future ones will be even more resistant to this since w= e=0A= know a lot more about signature mechanism design now than we did =0A= twenty years ago.=0A= =0A= Peter.= From mrex@sap.com Fri Nov 16 04:22:37 2012 Return-Path: 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 660A021F8521 for ; Fri, 16 Nov 2012 04:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 e6GmBnZ1cazt for ; Fri, 16 Nov 2012 04:22:37 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A743821F851F for ; Fri, 16 Nov 2012 04:22:36 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qAGCMYcg018171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2012 13:22:35 +0100 (MET) In-Reply-To: <001b01cdc345$d0028c00$7007a400$@eu> To: Erik Andersen Date: Fri, 16 Nov 2012 13:22:33 +0100 (CET) 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: <20121116122233.EFE721A381@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: PKIX Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 12:22:37 -0000 Erik Andersen wrote: > > A CRL has a signature field in X.509 and so has attribute certificate, so > X.509 is consistent. Ooops, you're correct. I'm sorry. I don't know why I failed to see it the last time I checked that. http://tools.ietf.org/html/rfc5280#section-5.1.1.2 But still, I don't see any security value in that structure member and consider it useless bloat. However, since one doesn't know which particular AlgId the implementation used by RPs will be looking at, the CAs must ensure that the use the exact same value in both places when issuing certs and CRLs. Finding a different AlgId with special parameters that will verify the exact same sequence of octets may be academically interesting, but security-wise is entirely irrelevant. What would be relevant security-wise, is a good signature under a **different** sequence of octets. The assumption that an attacker could "easily change other parts to his liking, but would have difficulties to also change the inner signature algorithm parameters seems awkward to me, and would IMHO indicate a general design flaw in the signature scheme (ore more likely the hash used by that scheme). -Martin From bergtau@gmail.com Mon Nov 19 12:24:21 2012 Return-Path: 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 5CC8021F85C2 for ; Mon, 19 Nov 2012 12:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TF5L4w+oInlr for ; Mon, 19 Nov 2012 12:24:12 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEB121F858A for ; Mon, 19 Nov 2012 12:24:11 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6032020vbb.31 for ; Mon, 19 Nov 2012 12:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=uZDrIvr6E0i6C2/tbSyP+wwLDUC/R+5xk3jjx6WI77Y=; b=bo71iS1GzkADGmb+MUUKZxki4s4mjI3f6iWdWJ+f1x+iq3T92dgaVXv+Mg7mpYEOz6 uYkpR+5MbWYc/dc2dspEIYtPiI5TxzKhyJ4cYRwmAbg2mII2wWmL+RAyNyPrr/TjGf8P YPZinVx6tL2HOt0JZZL4R7YlXvmfQImEwfF6STJ5qnmsaEwH60bhOEb+fmniDm7U+LNE n0DYKcFoJ/BuHM3npag0gZNMcvQ/XxFpzlW9JU+RRQeS/8aHG0LGQq03eZQNntD4nlYc D4/u0bbm5FIkX01ZyiSNO/xeIhePvcCiZKG8RfDrZnb2h6n7pj3QvfH028ghvmLINeog zi7w== Received: by 10.220.154.2 with SMTP id m2mr20817020vcw.18.1353356651388; Mon, 19 Nov 2012 12:24:11 -0800 (PST) Received: from [192.168.1.2] (pool-71-163-119-184.washdc.fios.verizon.net. [71.163.119.184]) by mx.google.com with ESMTPS id cz16sm6256340vdb.15.2012.11.19.12.24.10 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 12:24:10 -0800 (PST) Message-ID: <50AA956B.10000@gmail.com> Date: Mon, 19 Nov 2012 15:24:11 -0500 From: M Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org, pritikin@cisco.com, dharkins@lounge.org, peter@akalya.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] EST trust anchor definition X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:24:21 -0000 I think that the current EST draft is weak when it comes to talking about trust anchors. Many of the right ideas are there, but a bit scattered about. Figure (Table) 3 has a lot of this information, but there's some fuzz in it, and it's not very explicit about how crucial TA initialization is to the security of the protocol. A specific concern is a perception that *any* trust anchor that happens to be in a trust anchor store might be used to terminate a certificate validation chain. The use of the phrase "third party Trust Anchor Database" is worrisome. Who cares if the TA comes from any (acceptable) third party - if you can't ensure that your validation chain is going to terminate in that TA in the first place? The present state of TA store management doesn't inherently provide this selectability. I think that explicit text is needed here. I would suggest that table in Figure 3 be replaced with something like the following: Trust Anchors +--------------------------------------------------------------+ | NOTE: EST Servers and Clients must be initialized to know | | which specific public keys in their trust anchor | | stores correspond to which function from this table. | +---------------+----------------------------------------------+ | CA Root | * End of validation path of all CA certs | | public key | * End of validation path of Device Cert | | | * May be identical to EST Server TA | | | * May be identical to EST Client TA | | * Obtainable by /CACerts command | +---------------+----------------------------------------------+ | EST Server TA | * End of validation path of EST Server cert | | | * Must be securely installed to EST Client | | | * Must be obtained securely, out-of-band | +---------------+----------------------------------------------+ | EST Client TA | * End of valid. path of EST Client init cert | | | * Must be securely installed to EST Server | | | * Must be obtained securely, out-of-band | +---------------+----------------------------------------------+ Certificates +---------------+----------------------------------------------+ | CA Signing | * Crsp. private key signs Device Cert | | Certificate | * Intermediate CA certs may exist in path | | | * Obtainable by /CACerts command | | | * Must be validated against CA Root +---------------+----------------------------------------------+ | EST Server | * Used by EST Client during TLS handshake | | Certificate | * Must be validated against EST Server TA | +---------------+----------------------------------------------+ | EST Client | * Used by EST Server during initial enroll | | Init Cert | (if certificate TLS auth used) | | | * Must be validated against EST Client TA +---------------+----------------------------------------------+ | Device Cert | * Any certificate returned as a result of | | | /simpleEnroll, /simpleReEnroll, /fullCMC, | | | or /serverKeyGen | | | * May be used for subsequent EST sessions | +---------------+----------------------------------------------+ | NOTE: The CA, EST Server, EST Client, and other servers may | | have other certificates for other purposes, including | | inter-server communication during EST sessions. | +--------------------------------------------------------------+ Mike From bergtau@gmail.com Mon Nov 19 12:27:31 2012 Return-Path: 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 926BF21F869F for ; Mon, 19 Nov 2012 12:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7cfhc13t2ImG for ; Mon, 19 Nov 2012 12:27:30 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9580921F859D for ; Mon, 19 Nov 2012 12:27:30 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3361686vcb.31 for ; Mon, 19 Nov 2012 12:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=xycgx7yxvcx3huzbut8hYCXUCp3wGvVALMJssPXIYcs=; b=wFtQrWOcEY0iRiCdIKNcc4zGYftricFUGESEvgdttSkrHaty4lih6JIk6J+HKr6mYG TYbq2/+EZVybn073QvZCtTAe6yv9MUUDaz/zCfT/ih8sOJsCABHjiPhQsOrzmzwLOGS4 m29mO6/8x7lEQBvPYtxZr5PVz9OaWjtqZ2UQU0N71MAX8WHcCVW3pku9ZcoF+CwA39Fw 1OEI7vsHbYYFbwL9CzwMsy4Ex1GSi05Yksz3uq/5K3pq3t6POHAld0JkB0/VEws2dUmu //lsFwvnYKBOBGmp+HxasaYJyQV1q1XUQNGMV0dJmZC89nBREcTypdO4CabhmAWH6HWw Hnmw== Received: by 10.220.220.5 with SMTP id hw5mr20324086vcb.53.1353356848989; Mon, 19 Nov 2012 12:27:28 -0800 (PST) Received: from [192.168.1.2] (pool-71-163-119-184.washdc.fios.verizon.net. [71.163.119.184]) by mx.google.com with ESMTPS id h4sm6254744vdv.17.2012.11.19.12.27.27 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 12:27:28 -0800 (PST) Message-ID: <50AA9631.2000204@gmail.com> Date: Mon, 19 Nov 2012 15:27:29 -0500 From: M Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org, pritikin@cisco.com, dharkins@lounge.org, peter@akayla.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] EST server key generation question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:27:31 -0000 It would be helpful to know what the use case for server-side key generation is in the EST draft. Are these requests from devices that can't generate their own keys, or keys that need to be escrowed, or both and more? It makes kind of a big difference in what the client and server know about each other. Since it is the client that requests that a key be generated (/serverKeyGen), it makes sense that the client should be able to tell the server how it would like the generated key to be protected during distribution. One way to do this would be to include a RecipientInfo style extension in the dummy PKCS #10 that accompanies the /serverKeyGen command, that contains a public key or shared secret with which the generated key would be protected. (The dummy PKCS #10 would probably have to be signed with the public key included in the RecipientInfo and the request would need to include the tls-unique from Section 3.5.) The RecipientInfo can be communicated to the key generator by the EST Server. There might be other, simpler ways to do this, but I can't think of any that don't violate good key usage hygiene or bend CSR field semantics, and that do provide as general a solution. Also, this mechanism should be mandatory to implement, to ensure interoperability of the most general solution (interoperability here meaning that any client should be able to invoke this from any server). In addition, the mandatory to implement mechanism for distributing the generated key should be EnvelopedData, rather than bare PKCS #8 or EncryptedData. EncryptedData might be simpler to describe in the document, but would push so much key management out-of-scope that it might not be efficient to perform the function through EST in the first place. Mike From pritikin@cisco.com Mon Nov 19 12:56:57 2012 Return-Path: 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 A9E4C21F8754 for ; Mon, 19 Nov 2012 12:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 m-d+M1cuxeFT for ; Mon, 19 Nov 2012 12:56:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F181F21F8750 for ; Mon, 19 Nov 2012 12:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29626; q=dns/txt; s=iport; t=1353358616; x=1354568216; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7cH2KuwURcscy3DOSSlPtzL76VM1gh3IxnNat5XZUmk=; b=WzexlLBt6FdnPAqEmT0L409YIhuyLjypN9krRSBX9I97p7fuJPmDtLCV 9Vyxgm+XwY5JLN5o2Rwn0ajCjp02vsjyUNzQHUUOmErhluVeY9U51lQ/6 Q5i6wYOJwJ/3z1AJxo11g5vgsThsJUmbUIxFlacqw5E6nJ45L6gZy4Ulm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ2bqlCtJXG8/2dsb2JhbABFwlGBCIIfAQEEEgFZDRACAQgiFgcHIREUEQIEDgUIGodZAw+gIpYsDYlUi0tphCxhA4gljAKNB4MmgWuCb4FdBxcGGA X-IronPort-AV: E=McAfee;i="5400,1158,6901"; a="144087332" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 19 Nov 2012 20:56:55 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAJKutl5012883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Nov 2012 20:56:55 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.18]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Mon, 19 Nov 2012 14:56:55 -0600 From: "Max Pritikin (pritikin)" To: M Jenkins Thread-Topic: EST trust anchor definition Thread-Index: AQHNxpPc6GwWl6LMpkqCCG9K56Si9pfyCDwA Date: Mon, 19 Nov 2012 20:56:54 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> References: <50AA956B.10000@gmail.com> In-Reply-To: <50AA956B.10000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.217] Content-Type: multipart/alternative; boundary="_000_53EA47528D6ACF4486AA152F92C2B6982E9D7Exmbrcdx03ciscocom_" MIME-Version: 1.0 Cc: "" , "" Subject: Re: [pkix] EST trust anchor definition X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:56:57 -0000 --_000_53EA47528D6ACF4486AA152F92C2B6982E9D7Exmbrcdx03ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for all the feedback. We've already updated the table similar to wha= t you recommend below so its good to see we're on the same page. Below is the current table in our working copy. I'll read through your sugg= estions carefully to see if additional clarity can be gained. Similarly I'll go through you other email of specific feedback and merge th= em to the revisions we've made since the ietf85 meeting. - max Current table in our working revision (best viewed in monospaced font): Certificates and their corresponding uses: +--------------+--------------------+-------------------------------+ | Certificate | Issuer | Use and section references | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | EST server | The CA served by | Presented by the EST server | | certificate | the EST server | during the TLS handshake | | | | | | | | Section 3.3.1.1 | +--------------+--------------------+-------------------------------+ | EST server | A CA | Presented by the EST server | | certificate | authenticatable by | during the TLS handshake | | | a third-party TA | | | | | Section 3.3.1.1, and | | | | Security Considerations | +--------------+--------------------+-------------------------------+ | EST client | A CA | Presented by the EST client | | certificate | authenticatable by | to the EST server by clients | | | a third-party TA | that have not yet enrolled | | | e.g., a device | | | | manufacturer | Section 3.3.1.2 | +--------------+--------------------+-------------------------------+ | EST client | The CA served by | Presented by the EST client | | certificate | the EST server | to PKI End Entities. | | | | Including to the EST server | | | | during future EST operations | | | | | | | | Section 3.3.1.2 | +--------------+--------------------+-------------------------------+ | EST client | The CA served by | Presented by the EST client | | certificate | the EST server | to PKI End Entities. | | | | Clients can obtain certs | | | | that can not be used for EST | | | | client authentication | | | | | | | | Section 4.4.1 | +--------------+--------------------+-------------------------------+ Figure 3 Pritikin, et al. Expires May 21, 2013 [Page 12] Internet-Draft EST November 2012 Trust Anchor databases and their corresponding uses: +--------------+----------------------------------------------------+ | TA database | Use and section references | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | EST server | EST servers use this TA database to authenticate | | TA database | certificates issued by the CA, including EST | | | client certificates during enroll/re-enroll | | | operations | | | | | | Section 3.3.1.2 | +--------------+----------------------------------------------------+ | EST server | EST servers use this TA database to authenticate | | Third-Party | certificates issued by third-party TAs. | | TA database | e.g., EST client certificates issued by a device | | | manufacturer | | | | | | Section 3.3.1.2 | +--------------+----------------------------------------------------+ | EST client | EST clients use this TA database to authenticate | | EST CA | certificates issued by the EST CA, including EST | | TA database | server certificates. | | | | | | Section 3.3.1.1 and | | | Section 4.3 | +--------------+----------------------------------------------------+ | EST client | EST clients use this trust anchor database to | | Third-Party | authenticate an EST server that uses an externally | | TA database | issued certificate. | | | | | | | | | Section 3.3.1.1 and | | | Security Considerations | +--------------+----------------------------------------------------+ Figure 4 On Nov 19, 2012, at 1:24 PM, M Jenkins > wrote: I think that the current EST draft is weak when it comes to talking about t= rust anchors. Many of the right ideas are there, but a bit scattered about.= Figure (Table) 3 has a lot of this information, but there's some fuzz in i= t, and it's not very explicit about how crucial TA initialization is to the= security of the protocol. A specific concern is a perception that *any* trust anchor that happens to = be in a trust anchor store might be used to terminate a certificate validat= ion chain. The use of the phrase "third party Trust Anchor Database" is wor= risome. Who cares if the TA comes from any (acceptable) third party - if yo= u can't ensure that your validation chain is going to terminate in that TA = in the first place? The present state of TA store management doesn't inhere= ntly provide this selectability. I think that explicit text is needed here. I would suggest that table in Figure 3 be replaced with something like the = following: Trust Anchors +--------------------------------------------------------------+ | NOTE: EST Servers and Clients must be initialized to know | | which specific public keys in their trust anchor | | stores correspond to which function from this table. | +---------------+----------------------------------------------+ | CA Root | * End of validation path of all CA certs | | public key | * End of validation path of Device Cert | | | * May be identical to EST Server TA | | | * May be identical to EST Client TA | | * Obtainable by /CACerts command | +---------------+----------------------------------------------+ | EST Server TA | * End of validation path of EST Server cert | | | * Must be securely installed to EST Client | | | * Must be obtained securely, out-of-band | +---------------+----------------------------------------------+ | EST Client TA | * End of valid. path of EST Client init cert | | | * Must be securely installed to EST Server | | | * Must be obtained securely, out-of-band | +---------------+----------------------------------------------+ Certificates +---------------+----------------------------------------------+ | CA Signing | * Crsp. private key signs Device Cert | | Certificate | * Intermediate CA certs may exist in path | | | * Obtainable by /CACerts command | | | * Must be validated against CA Root +---------------+----------------------------------------------+ | EST Server | * Used by EST Client during TLS handshake | | Certificate | * Must be validated against EST Server TA | +---------------+----------------------------------------------+ | EST Client | * Used by EST Server during initial enroll | | Init Cert | (if certificate TLS auth used) | | | * Must be validated against EST Client TA +---------------+----------------------------------------------+ | Device Cert | * Any certificate returned as a result of | | | /simpleEnroll, /simpleReEnroll, /fullCMC, | | | or /serverKeyGen | | | * May be used for subsequent EST sessions | +---------------+----------------------------------------------+ | NOTE: The CA, EST Server, EST Client, and other servers may | | have other certificates for other purposes, including | | inter-server communication during EST sessions. | +--------------------------------------------------------------+ Mike --_000_53EA47528D6ACF4486AA152F92C2B6982E9D7Exmbrcdx03ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7665BBDEE6E4304D97C283087EDA1360@cisco.com> Content-Transfer-Encoding: quoted-printable Thanks for all the feedback. We've already updated the table similar to wha= t you recommend below so its good to see we're on the same page. 

Below is the current table in our working copy. I'll read through your= suggestions carefully to see if additional clarity can be gained. 

Similarly I'll go through you other email of specific feedback and mer= ge them to the revisions we've made since the ietf85 meeting. 

- max

Current table in our working revision (best viewed in monospaced font)= :

   Certificates and their corresponding= uses:
   +--------------+--------------------+-------------= ------------------+
   | Certificate  | Issuer          = ;   | Use and section references    |
   +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +
   | EST server   | The CA served by   | Presented by t= he EST server   |
   | certificate  | the EST server     | during th= e TLS handshake      |
   |              |   &nb= sp;                |     =                      = ;     |
   |              |   &nb= sp;                | Section 3.3.1.= 1               |
   +--------------+--------------------+-------------= ------------------+
   | EST server   | A CA           =     | Presented by the EST server   |
   | certificate  | authenticatable by | during the TLS hand= shake      |
   |              | a third-pa= rty TA   |                 &nb= sp;             |
   |              |   &nb= sp;                | Section 3.3.1.= 1, and          |
   |              |   &nb= sp;                | Security Consi= derations       |
   +--------------+--------------------+-------------= ------------------+
   | EST client   | A CA           =     | Presented by the EST client   |
   | certificate  | authenticatable by | to the EST server b= y clients  |
   |              | a third-pa= rty TA   | that have not yet enrolled    |
   |              | e.g., a de= vice     |                = ;               |
   |              | manufactur= er       | Section 3.3.1.2          = ;     |
   +--------------+--------------------+-------------= ------------------+
   | EST client   | The CA served by   | Presented by t= he EST client   |
   | certificate  | the EST server     | to PKI En= d Entities.          |
   |              |   &nb= sp;                | Including to t= he EST server   |
   |              |   &nb= sp;                | during future = EST operations  |
   |              |   &nb= sp;                |     =                      = ;     |
   |              |   &nb= sp;                | Section 3.3.1.= 2               |
   +--------------+--------------------+-------------= ------------------+
   | EST client   | The CA served by   | Presented by t= he EST client   |
   | certificate  | the EST server     | to PKI En= d Entities.          |
   |              |   &nb= sp;                | Clients can ob= tain certs      |
   |              |   &nb= sp;                | that can not b= e used for EST  |
   |              |   &nb= sp;                | client authent= ication         |
   |              |   &nb= sp;                |     =                      = ;     |
   |              |   &nb= sp;                | Section 4.4.1 =                 |
   +--------------+--------------------+-------------= ------------------+


                     = ;            Figure 3












Pritikin, et al.          Expires May 21, 2013 &nb= sp;               [Page 12]
Internet-Draft                 &nbs= p;   EST                  = ;   November 2012


   Trust Anchor databases and their corresponding uses:
   +--------------+--------------------------------------= --------------+
   | TA database  | Use and section references    =                     |    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= 3;
   | EST server   | EST servers use this TA database to auth= enticate   |
   | TA database  | certificates issued by the CA, including= EST       |
   |              | client cer= tificates during enroll/re-enroll        |
   |              | operations=                     &nbs= p;                   |
   |              |   &nb= sp;                     &= nbsp;                    =      |
   |              | Section 3.= 3.1.2                    =                |
   +--------------+--------------------------------------= --------------+
   | EST server   | EST servers use this TA database to auth= enticate   |
   | Third-Party  | certificates issued by third-party TAs. =            |
   | TA database  | e.g., EST client certificates issued by = a device   |
   |              | manufactur= er                     &n= bsp;                 |
   |              |   &nb= sp;                     &= nbsp;                    =      |
   |              | Section 3.= 3.1.2                    =                |
   +--------------+--------------------------------------= --------------+
   | EST client   | EST clients use this TA database to auth= enticate   |
   | EST CA       | certificates issued by the EST= CA, including EST   |
   | TA database  | server certificates.      = ;                     &nb= sp;   |
   |              |   &nb= sp;                     &= nbsp;                    =      |
   |              | Section 3.= 3.1.1 and                   &n= bsp;            |
   |              | Section 4.= 3                     &nb= sp;                  |
   +--------------+--------------------------------------= --------------+
   | EST client   | EST clients use this trust anchor databa= se to      |
   | Third-Party  | authenticate an EST server that uses an = externally |
   | TA database  | issued certificate.      =                     &nbs= p;    |
   |              |   &nb= sp;                     &= nbsp;                    =      |
   |              |   &nb= sp;                     &= nbsp;                    =      |
   |              | Section 3.= 3.1.1 and                   &n= bsp;            |
   |              | Security C= onsiderations                  = ;          |
   +--------------+--------------------------------------= --------------+


                     = ;            Figure 4

On Nov 19, 2012, at 1:24 PM, M Jenkins <bergtau@gmail.com>
 wrote:

I think that the current EST draft is weak when i= t comes to talking about trust anchors. Many of the right ideas are there, = but a bit scattered about. Figure (Table) 3 has a lot of this information, = but there's some fuzz in it, and it's not very explicit about how crucial TA initialization is to the security o= f the protocol.

A specific concern is a perception that *any* trust anchor that happens to = be in a trust anchor store might be used to terminate a certificate validat= ion chain. The use of the phrase "third party Trust Anchor Database&qu= ot; is worrisome. Who cares if the TA comes from any (acceptable) third party - if you can't ensure that your validati= on chain is going to terminate in that TA in the first place? The present s= tate of TA store management doesn't inherently provide this selectability. = I think that explicit text is needed here.

I would suggest that table in Figure 3 be replaced with something like the = following:

Trust Anchors
+--------------------------------------------------------------+ | NOTE: EST Servers and Clients must be initialized to know   &nb= sp;|
|       which specific public keys in their t= rust anchor       |
|       stores correspond to which function f= rom this table.   |
+---------------+----------------------------------------------+= ;
| CA Root       | * End of validation path of= all CA certs     |
|  public key   | * End of validation path of Device Cert &n= bsp;    |
|             &= nbsp; | * May be identical to EST Server TA     &n= bsp;    |
|             &= nbsp; | * May be identical to EST Client TA
|             &= nbsp; | * Obtainable by /CACerts command      = ;       |
+---------------+----------------------------------------------+= ;
| EST Server TA | * End of validation path of EST Server cert  |
|             &= nbsp; | * Must be securely installed to EST Client   |
|             &= nbsp; | * Must be obtained securely, out-of-band    &nb= sp;|
+---------------+----------------------------------------------+= ;
| EST Client TA | * End of valid. path of EST Client init cert |
|             &= nbsp; | * Must be securely installed to EST Server   |
|             &= nbsp; | * Must be obtained securely, out-of-band    &nb= sp;|
+---------------+----------------------------------------------+= ;

Certificates
+---------------+----------------------------------------------+= ;
| CA Signing    | * Crsp. private key signs Device Cert &nbs= p;      |
|  Certificate  | * Intermediate CA certs may exist in path  = ;  |
|             &= nbsp; | * Obtainable by /CACerts command      = ;       |
|             &= nbsp; | * Must be validated against CA Root
+---------------+----------------------------------------------+= ;
| EST Server    | * Used by EST Client during TLS handshake =    |
|  Certificate  | * Must be validated against EST Server TA  = ;  |
+---------------+----------------------------------------------+= ;
| EST Client    | * Used by EST Server during initial enroll=   |
|  Init Cert    |    (if certificate TLS= auth used)           &nb= sp;|
|             &= nbsp; | * Must be validated against EST Client TA
+---------------+----------------------------------------------+= ;
| Device Cert   | * Any certificate returned as a result of  = ;  |
|             &= nbsp; |    /simpleEnroll, /simpleReEnroll, /fullCMC, |<= br> |             &= nbsp; |    or /serverKeyGen     &nb= sp;            =         |
|             &= nbsp; | * May be used for subsequent EST sessions    |<= br> +---------------+----------------------------------------------+= ;
| NOTE: The CA, EST Server, EST Client, and other servers may  |
|       have other certificates for other pur= poses, including  |
|       inter-server communication during EST= sessions.        |
+--------------------------------------------------------------+
Mike

--_000_53EA47528D6ACF4486AA152F92C2B6982E9D7Exmbrcdx03ciscocom_-- From pgut001@cs.auckland.ac.nz Tue Nov 20 04:27:29 2012 Return-Path: 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 778B721F86B5 for ; Tue, 20 Nov 2012 04:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Zu9IZCvJlueX for ; Tue, 20 Nov 2012 04:27:28 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F64321F86B0 for ; Tue, 20 Nov 2012 04:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1353414448; x=1384950448; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qRkyxC9/mAzx7a4Iay7j3enNMUj85yDldTtLiHpl21E=; b=ta4Sf7DlDoE1yxqym3rjHf+FQjS6MKR130/0lD4/hHS+UfJ/Fsw4gUFk ptSgiSY34bdU84GDKeHnCbF2xB6hJggpQCLJuRW4Y8W5UB6A06zq0SO4N nZWtL4cRGgrQz8gCR3c2AMwFvnCTxS0fBCie+t1sAyDvxGnl8/TsbQEQs 8=; X-IronPort-AV: E=Sophos;i="4.83,286,1352026800"; d="scan'208";a="157817096" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Nov 2012 01:27:27 +1300 Received: from UXCN10-4.UoA.auckland.ac.nz ([169.254.4.99]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 01:27:26 +1300 From: Peter Gutmann To: "pkix@ietf.org" , "era@x500.eu" Thread-Topic: useless bagage in X.509 Thread-Index: Ac3HGmZ3snO/IZoUSHOhbQ+Os+qn0w== Date: Tue, 20 Nov 2012 12:27:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7331C652EB@uxcn10-4.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] useless bagage in X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 12:27:29 -0000 Erik Andersen writes:=0A= =0A= >It would be nice to get some examples of useless baggage in X.509.=0A= =0A= Sure. To see what's needed and what isn't, you just have to look at how ce= rts=0A= are being used on the Internet (remembering that PKIX was chartered to defi= ne=0A= how certs were used in the Internet, although in practice it really exists = to=0A= profile them for DoD use). So for Internet use you need:=0A= =0A= - A public key (SEQUENCE ...)=0A= - Owner info (or -s), consisting of a machine-readable name ("www.amazon.co= m",=0A= "era@x500.eu") paired with a friendly name ("Amazon", "Erik Andersen")=0A= (SEQUENCE OF { UTF8String, UTF8String OPTIONAL }).=0A= - Issuer info: A pointer to the issuing cert/CA for verification, pointers = to=0A= other info the CA may consider useful such as a CRL location, and CA=0A= advertising (logo, T&C, and so on) (SEQUENCE OF { type, UTF8String }).=0A= - An indication of the cert's usage along the lines of keyUsage (BIT STRING= ).=0A= - The FOUO field for the DoD.=0A= - A signature.=0A= =0A= If I'm using the cert with a web server I need the server URL/FQDN (owner= =0A= info), the key, and some information to verify the cert; if I'm using the c= ert=0A= for email I need the email address (owner info), usage indicator (encrypt,= =0A= sign, ...) the key, and some information to ... . If I'm using the cert fo= r=0A= EAP I need... well, you get the idea. Everything else in the cert is then= =0A= useless baggage.=0A= =0A= Peter.= From DPKemp@missi.ncsc.mil Tue Nov 20 06:57:16 2012 Return-Path: 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 1332A21F8722 for ; Tue, 20 Nov 2012 06:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2dQahwiIv+f6 for ; Tue, 20 Nov 2012 06:57:15 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5945C21F8711 for ; Tue, 20 Nov 2012 06:57:15 -0800 (PST) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id qAKEvDC2011294 for ; Tue, 20 Nov 2012 09:57:13 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.101]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0421.002; Tue, 20 Nov 2012 09:57:13 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: useless bagage in X.509 Thread-Index: Ac3HGmZ3snO/IZoUSHOhbQ+Os+qn0wAEt2fg Date: Tue, 20 Nov 2012 14:57:12 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8450592AD@clavin.missi.ncsc.mil> References: <9A043F3CF02CD34C8E74AC1594475C7331C652EB@uxcn10-4.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7331C652EB@uxcn10-4.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] useless bagage in X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 14:57:16 -0000 It's interesting that you view the world as divided into "U.S. DoD" and "In= ternet" - I'm sure we're flattered, but there are governments and industry = groups (banking, health/pharma, aerospace, education - at least on this sid= e of the pond, ...) that have use for things like interoperable differentia= ted assurance (certificate policies) and worry about things like transitive= trust (basic constraints) and trust itself (name constraints) that you cla= ssify as useless baggage. There was a time when the Internet itself was useless baggage to everyone b= ut the DoD. But welcome aboard anyway. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pet= er Gutmann Sent: Tuesday, November 20, 2012 7:27 AM To: pkix@ietf.org; era@x500.eu Subject: Re: [pkix] useless bagage in X.509 Erik Andersen writes: >It would be nice to get some examples of useless baggage in X.509. Sure. To see what's needed and what isn't, you just have to look at how ce= rts are being used on the Internet (remembering that PKIX was chartered to = define how certs were used in the Internet, although in practice it really = exists to profile them for DoD use). So for Internet use you need: - A public key (SEQUENCE ...) - Owner info (or -s), consisting of a machine-readable name ("www.amazon.co= m", "era@x500.eu") paired with a friendly name ("Amazon", "Erik Andersen") (SEQUENCE OF { UTF8String, UTF8String OPTIONAL }). - Issuer info: A pointer to the issuing cert/CA for verification, pointers = to other info the CA may consider useful such as a CRL location, and CA advertising (logo, T&C, and so on) (SEQUENCE OF { type, UTF8String }). - An indication of the cert's usage along the lines of keyUsage (BIT STRING= ). - The FOUO field for the DoD. - A signature. If I'm using the cert with a web server I need the server URL/FQDN (owner i= nfo), the key, and some information to verify the cert; if I'm using the ce= rt for email I need the email address (owner info), usage indicator (encryp= t, sign, ...) the key, and some information to ... . If I'm using the cert= for EAP I need... well, you get the idea. Everything else in the cert is = then useless baggage. Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From hotz@jpl.nasa.gov Tue Nov 20 12:20:45 2012 Return-Path: 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 DDF3821F8531 for ; Tue, 20 Nov 2012 12:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vhYjqKQDLqCj for ; Tue, 20 Nov 2012 12:20:44 -0800 (PST) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3C58221F8525 for ; Tue, 20 Nov 2012 12:20:44 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAKKKfYT003880 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 20 Nov 2012 12:20:43 -0800 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8450592AD@clavin.missi.ncsc.mil> Date: Tue, 20 Nov 2012 12:20:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <36E4B9B3-B3BF-4AAD-AC91-1CF7F92E73C6@jpl.nasa.gov> References: <9A043F3CF02CD34C8E74AC1594475C7331C652EB@uxcn10-4.UoA.auckland.ac.nz> <5B1D7E570380A64989D4C069F7D14BC8450592AD@clavin.missi.ncsc.mil> To: "Kemp, David P." X-Mailer: Apple Mail (2.1085) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" Subject: Re: [pkix] useless bagage in X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:20:46 -0000 Until name constraints is properly implemented in a majority of = implementations, it would appear to be useless baggage for a majority of = PKIX users, wouldn't it? Don't get me wrong, I'd like the capability. On Nov 20, 2012, at 6:57 AM, Kemp, David P. wrote: > It's interesting that you view the world as divided into "U.S. DoD" = and "Internet" - I'm sure we're flattered, but there are governments and = industry groups (banking, health/pharma, aerospace, education - at least = on this side of the pond, ...) that have use for things like = interoperable differentiated assurance (certificate policies) and worry = about things like transitive trust (basic constraints) and trust itself = (name constraints) that you classify as useless baggage. >=20 > There was a time when the Internet itself was useless baggage to = everyone but the DoD. But welcome aboard anyway. >=20 > Dave >=20 >=20 >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Peter Gutmann > Sent: Tuesday, November 20, 2012 7:27 AM > To: pkix@ietf.org; era@x500.eu > Subject: Re: [pkix] useless bagage in X.509 >=20 > Erik Andersen writes: >=20 >> It would be nice to get some examples of useless baggage in X.509. >=20 > Sure. To see what's needed and what isn't, you just have to look at = how certs are being used on the Internet (remembering that PKIX was = chartered to define how certs were used in the Internet, although in = practice it really exists to profile them for DoD use). So for Internet = use you need: >=20 > - A public key (SEQUENCE ...) > - Owner info (or -s), consisting of a machine-readable name = ("www.amazon.com", > "era@x500.eu") paired with a friendly name ("Amazon", "Erik = Andersen") > (SEQUENCE OF { UTF8String, UTF8String OPTIONAL }). > - Issuer info: A pointer to the issuing cert/CA for verification, = pointers to > other info the CA may consider useful such as a CRL location, and CA > advertising (logo, T&C, and so on) (SEQUENCE OF { type, UTF8String = }). > - An indication of the cert's usage along the lines of keyUsage (BIT = STRING). > - The FOUO field for the DoD. > - A signature. >=20 > If I'm using the cert with a web server I need the server URL/FQDN = (owner info), the key, and some information to verify the cert; if I'm = using the cert for email I need the email address (owner info), usage = indicator (encrypt, sign, ...) the key, and some information to ... . = If I'm using the cert for EAP I need... well, you get the idea. = Everything else in the cert is then useless baggage. >=20 > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From swilson@lockstep.com.au Tue Nov 20 12:45:05 2012 Return-Path: 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 BE6B221F8675 for ; Tue, 20 Nov 2012 12:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] 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 Hk+wQ-8WmJmG for ; Tue, 20 Nov 2012 12:45:04 -0800 (PST) Received: from smtp138.ord.emailsrvr.com (smtp138.ord.emailsrvr.com [173.203.6.138]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD1121F847F for ; Tue, 20 Nov 2012 12:45:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id B14D4370198 for ; Tue, 20 Nov 2012 15:45:03 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.ord1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPSA id 1F6663700B1 for ; Tue, 20 Nov 2012 15:45:02 -0500 (EST) Message-ID: <50ABEB94.3010605@lockstep.com.au> Date: Wed, 21 Nov 2012 07:44:04 +1100 From: Stephen Wilson Organization: Lockstep User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C7331C5416E@uxcn10-2.UoA.auckland.ac.nz> <000601cdc289$a8f55190$fadff4b0$@eu> In-Reply-To: <000601cdc289$a8f55190$fadff4b0$@eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] useless bagage in X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:45:05 -0000 It's only small but it has a staggering signal-to-noise ratio ... I nominate the NR bit as the most useless baggage in X.509. Cheers, Steve Wilson Lockstep http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy. Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. On 15/11/2012 4:01 AM, Erik Andersen wrote: > Hi Peter, > > It would be nice to get some examples of useless baggage in X.509. > > Erik Andersen > > -----Oprindelig meddelelse----- > Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] På vegne af Peter > Gutmann > Sendt: 14. november 2012 10:47 > Til: pkix@ietf.org > Emne: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates > > Martin Rex writes: > >> I was just plain guessing at what might have been the original >> motivation behind the addition of this useless baggage to TBSCertificate. > As others have pointed out it was added to prevent an OID-swapping attack > that's rendered irrelevant by PKCS #1 padding but is theoretically possible > if you use a sufficiently broken signature-formatting mechanism, e.g. raw > RSA. My code reads it and checks that it's a signing-capable PKC algorithm, > but doesn't do any more than that. Since (apparently) no-one ever checks > this and so implementations that put the wrong OID in there have been > deployed, this is probably the safest thing to do. > > Given all the other useless baggage in X.509 in general, I don't see its > presence as a big deal. If we wanted to remove all the stuff that isn't > baggage there'd be very little left: A DNS name or email address, a link to > the signing cert for verification purposes, a key usage flag, some sort of > advertising field for the CA, and a signature. > > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From wwwrun@rfc-editor.org Mon Nov 26 05:20:06 2012 Return-Path: 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 66BC221F8521 for ; Mon, 26 Nov 2012 05:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ndaXqKq6UtAj for ; Mon, 26 Nov 2012 05:20:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E3C5221F855F for ; Mon, 26 Nov 2012 05:20:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8B7C372E039; Mon, 26 Nov 2012 05:12:23 -0800 (PST) To: mmyers@verisign.com, rankney@erols.com, ambarish@valicert.com, galperin@mycfo.com, cadams@entrust.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20121126131223.8B7C372E039@rfc-editor.org> Date: Mon, 26 Nov 2012 05:12:23 -0800 (PST) X-Mailman-Approved-At: Mon, 26 Nov 2012 05:31:01 -0800 Cc: pkix@ietf.org, rfc-editor@rfc-editor.org, soltes@avaya.com Subject: [pkix] [Technical Errata Reported] RFC2560 (3417) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 13:20:06 -0000 The following errata report has been submitted for RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3417 -------------------------------------- Type: Technical Reported by: John Soltes Section: 4.2.2.2 Original Text ------------- ...OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that issued the certificate in question. id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above...They MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria: ... 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question." Corrected Text -------------- ...OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that issued the certificate in question. id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-kp-OCSPSigning value as described above...They MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria: ... 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question. Notes ----- The first paragraph specifies that an "id-kp-OCSPSigning" value be included, and it then defines that value as "id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed alternative specify the use of an "id-ad-ocspSigning" value, which is not defined. I assume that "id-kp-OCSPSigning" should be used throughout? Also, the double quote mark at the end of the third listed alternative should be removed. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2560 (draft-ietf-pkix-ocsp-07) -------------------------------------- Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Publication Date : June 1999 Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From stefan@aaa-sec.com Mon Nov 26 06:05:55 2012 Return-Path: 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 6A67321F8443 for ; Mon, 26 Nov 2012 06:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 MQNTlwXDVF0a for ; Mon, 26 Nov 2012 06:05:54 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id DA3BB21F8203 for ; Mon, 26 Nov 2012 06:05:53 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 8358AAEE67 for ; Mon, 26 Nov 2012 15:05:42 +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 dy8hYcYzAn2h for ; Mon, 26 Nov 2012 15:05:40 +0100 (CET) Received: from s414.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E2E56AFE29 for ; Mon, 26 Nov 2012 14:59:02 +0100 (CET) Received: (qmail 47506 invoked from network); 26 Nov 2012 13:59:02 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.5]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s414.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Nov 2012 13:59:02 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 26 Nov 2012 14:59:00 +0100 From: Stefan Santesson To: RFC Errata System , , , Message-ID: Thread-Topic: [pkix] [Technical Errata Reported] RFC2560 (3417) In-Reply-To: <20121126131223.8B7C372E039@rfc-editor.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org, soltes@avaya.com Subject: Re: [pkix] [Technical Errata Reported] RFC2560 (3417) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:05:55 -0000 Good catch in this errata. It's almost amazing that this has gone unnoticed for all these years :) I have updated this in the coming draft 2560bis /Stefan On 11/26/12 2:12 PM, "RFC Errata System" wrote: > >The following errata report has been submitted for RFC2560, >"X.509 Internet Public Key Infrastructure Online Certificate Status >Protocol - OCSP". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3417 > >-------------------------------------- >Type: Technical >Reported by: John Soltes > >Section: 4.2.2.2 > >Original Text >------------- >...OCSP signing delegation SHALL be designated by the > inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate > extension included in the OCSP response signer's certificate. This > certificate MUST be issued directly by the CA that issued the > certificate in question. > > id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} > > Systems or applications that rely on OCSP responses MUST be capable > of detecting and enforcing use of the id-ad-ocspSigning value as > described above...They MUST reject the > response if the certificate required to validate the signature on the > response fails to meet at least one of the following criteria: > > ... > > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage > extension and is issued by the CA that issued the certificate in > question." > >Corrected Text >-------------- >...OCSP signing delegation SHALL be designated by the > inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate > extension included in the OCSP response signer's certificate. This > certificate MUST be issued directly by the CA that issued the > certificate in question. > > id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} > > Systems or applications that rely on OCSP responses MUST be capable > of detecting and enforcing use of the id-kp-OCSPSigning value as > described above...They MUST reject the > response if the certificate required to validate the signature on the > response fails to meet at least one of the following criteria: > > ... > > 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage > extension and is issued by the CA that issued the certificate in > question. > >Notes >----- >The first paragraph specifies that an "id-kp-OCSPSigning" value be >included, and it then defines that value as "id-kp-OCSPSigning OBJECT >IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed >alternative specify the use of an "id-ad-ocspSigning" value, which is not >defined. I assume that "id-kp-OCSPSigning" should be used throughout? >Also, the double quote mark at the end of the third listed alternative >should be removed. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC2560 (draft-ietf-pkix-ocsp-07) >-------------------------------------- >Title : X.509 Internet Public Key Infrastructure Online >Certificate Status Protocol - OCSP >Publication Date : June 1999 >Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >Adams >Category : PROPOSED STANDARD >Source : Public-Key Infrastructure (X.509) >Area : Security >Stream : IETF >Verifying Party : IESG >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From david.cooper@nist.gov Mon Nov 26 08:04:01 2012 Return-Path: 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 D871321F86B7 for ; Mon, 26 Nov 2012 08:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ApGePXYeoli7 for ; Mon, 26 Nov 2012 08:04:01 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id C76B721F86B3 for ; Mon, 26 Nov 2012 08:04:00 -0800 (PST) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 26 Nov 2012 11:03:26 -0500 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.2.318.4; Mon, 26 Nov 2012 11:01:30 -0500 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id qAQG3aP2001744; Mon, 26 Nov 2012 11:03:37 -0500 Message-ID: <50B392D8.4010300@nist.gov> Date: Mon, 26 Nov 2012 11:03:36 -0500 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120829 Thunderbird/15.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] [Technical Errata Reported] RFC2560 (3417) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 16:04:02 -0000 It was actually noticed and corrected more than ten years ago (see Appendix D in http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-00). The error just got reintroduced in draft -05 of 2560bis. On 11/26/2012 08:59 AM, Stefan Santesson wrote: > Good catch in this errata. > > It's almost amazing that this has gone unnoticed for all these years :) > I have updated this in the coming draft 2560bis > > /Stefan > > > On 11/26/12 2:12 PM, "RFC Errata System" wrote: > >> The following errata report has been submitted for RFC2560, >> "X.509 Internet Public Key Infrastructure Online Certificate Status >> Protocol - OCSP". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3417 >> >> -------------------------------------- >> Type: Technical >> Reported by: John Soltes >> >> Section: 4.2.2.2 >> >> Original Text >> ------------- >> ...OCSP signing delegation SHALL be designated by the >> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >> extension included in the OCSP response signer's certificate. This >> certificate MUST be issued directly by the CA that issued the >> certificate in question. >> >> id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} >> >> Systems or applications that rely on OCSP responses MUST be capable >> of detecting and enforcing use of the id-ad-ocspSigning value as >> described above...They MUST reject the >> response if the certificate required to validate the signature on the >> response fails to meet at least one of the following criteria: >> >> ... >> >> 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage >> extension and is issued by the CA that issued the certificate in >> question." >> >> Corrected Text >> -------------- >> ...OCSP signing delegation SHALL be designated by the >> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >> extension included in the OCSP response signer's certificate. This >> certificate MUST be issued directly by the CA that issued the >> certificate in question. >> >> id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} >> >> Systems or applications that rely on OCSP responses MUST be capable >> of detecting and enforcing use of the id-kp-OCSPSigning value as >> described above...They MUST reject the >> response if the certificate required to validate the signature on the >> response fails to meet at least one of the following criteria: >> >> ... >> >> 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage >> extension and is issued by the CA that issued the certificate in >> question. >> >> Notes >> ----- >> The first paragraph specifies that an "id-kp-OCSPSigning" value be >> included, and it then defines that value as "id-kp-OCSPSigning OBJECT >> IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed >> alternative specify the use of an "id-ad-ocspSigning" value, which is not >> defined. I assume that "id-kp-OCSPSigning" should be used throughout? >> Also, the double quote mark at the end of the third listed alternative >> should be removed. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC2560 (draft-ietf-pkix-ocsp-07) >> -------------------------------------- >> Title : X.509 Internet Public Key Infrastructure Online >> Certificate Status Protocol - OCSP >> Publication Date : June 1999 >> Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >> Adams >> Category : PROPOSED STANDARD >> Source : Public-Key Infrastructure (X.509) >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > . > From turners@ieca.com Mon Nov 26 12:56:30 2012 Return-Path: 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 B231921F86EC for ; Mon, 26 Nov 2012 12:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 LlrvsEYxzRwC for ; Mon, 26 Nov 2012 12:56:30 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.56.148.24]) by ietfa.amsl.com (Postfix) with ESMTP id 030DB21F85DA for ; Mon, 26 Nov 2012 12:56:30 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 94128BB23F260; Mon, 26 Nov 2012 14:56:29 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 890BDBB23F23D for ; Mon, 26 Nov 2012 14:56:29 -0600 (CST) Received: from [108.45.19.185] (port=58972 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Td5jB-0002Zn-9q; Mon, 26 Nov 2012 14:56:29 -0600 Message-ID: <50B3D77C.90804@ieca.com> Date: Mon, 26 Nov 2012 15:56:28 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "pkix@ietf.org" References: <50B392D8.4010300@nist.gov> In-Reply-To: <50B392D8.4010300@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:58972 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Stefan Santesson , soltes@avaya.com Subject: Re: [pkix] [Technical Errata Reported] RFC2560 (3417) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:56:30 -0000 I was thinking along the same lines as David. I'm going to accept this errata, but I'm going to: 1. Change it to editorial. This just seems to me like a typo. 2. Edit it down a bit: OLD: Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above. NEW: Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-kp-OCSPSigning value as described above. 3. and put the bit about the " in the notes. spt On 11/26/12 11:03 AM, David A. Cooper wrote: > It was actually noticed and corrected more than ten years ago (see > Appendix D in > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-00). The error > just got reintroduced in draft -05 of 2560bis. > > On 11/26/2012 08:59 AM, Stefan Santesson wrote: >> Good catch in this errata. >> >> It's almost amazing that this has gone unnoticed for all these years :) >> I have updated this in the coming draft 2560bis >> >> /Stefan >> >> >> On 11/26/12 2:12 PM, "RFC Errata System" >> wrote: >> >>> The following errata report has been submitted for RFC2560, >>> "X.509 Internet Public Key Infrastructure Online Certificate Status >>> Protocol - OCSP". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3417 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: John Soltes >>> >>> Section: 4.2.2.2 >>> >>> Original Text >>> ------------- >>> ...OCSP signing delegation SHALL be designated by the >>> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >>> extension included in the OCSP response signer's certificate. This >>> certificate MUST be issued directly by the CA that issued the >>> certificate in question. >>> >>> id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} >>> >>> Systems or applications that rely on OCSP responses MUST be capable >>> of detecting and enforcing use of the id-ad-ocspSigning value as >>> described above...They MUST reject the >>> response if the certificate required to validate the signature on the >>> response fails to meet at least one of the following criteria: >>> >>> ... >>> >>> 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage >>> extension and is issued by the CA that issued the certificate in >>> question." >>> >>> Corrected Text >>> -------------- >>> ...OCSP signing delegation SHALL be designated by the >>> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >>> extension included in the OCSP response signer's certificate. This >>> certificate MUST be issued directly by the CA that issued the >>> certificate in question. >>> >>> id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} >>> >>> Systems or applications that rely on OCSP responses MUST be capable >>> of detecting and enforcing use of the id-kp-OCSPSigning value as >>> described above...They MUST reject the >>> response if the certificate required to validate the signature on the >>> response fails to meet at least one of the following criteria: >>> >>> ... >>> >>> 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage >>> extension and is issued by the CA that issued the certificate in >>> question. >>> >>> Notes >>> ----- >>> The first paragraph specifies that an "id-kp-OCSPSigning" value be >>> included, and it then defines that value as "id-kp-OCSPSigning OBJECT >>> IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed >>> alternative specify the use of an "id-ad-ocspSigning" value, which is >>> not >>> defined. I assume that "id-kp-OCSPSigning" should be used throughout? >>> Also, the double quote mark at the end of the third listed alternative >>> should be removed. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC2560 (draft-ietf-pkix-ocsp-07) >>> -------------------------------------- >>> Title : X.509 Internet Public Key Infrastructure Online >>> Certificate Status Protocol - OCSP >>> Publication Date : June 1999 >>> Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >>> Adams >>> Category : PROPOSED STANDARD >>> Source : Public-Key Infrastructure (X.509) >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> . >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From iesg-secretary@ietf.org Mon Nov 26 13:36:09 2012 Return-Path: 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 3084B21F8518; Mon, 26 Nov 2012 13:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cfjkA1YTiBVL; Mon, 26 Nov 2012 13:36:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADB721F8611; Mon, 26 Nov 2012 13:36:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126213608.17569.30919.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 13:36:08 -0800 Cc: pkix mailing list , pkix chair , RFC Editor Subject: [pkix] Protocol Action: 'DNS Certification Authority Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf-pkix-caa-15.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 21:36:09 -0000 The IESG has approved the following document: - 'DNS Certification Authority Authorization (CAA) Resource Record' (draft-ietf-pkix-caa-15.txt) as Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ Technical Summary The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. Working Group Summary This document might have been pursued in other WGs, specifically DNSEXT, since it specifies a new DNS record type. It also might have been pursued in DANE, but the focus of DANE is sufficiently different that it is probably not a good fit there. Because the document specifies a DNS record type, for use with PKI technology, PKIX was reasonable choice for the authors. There was some controversy initially, but that went away over time. Document Quality I am not aware of any existing implementations of the protocol, but both authors work for a company that is represented by a trust anchor in browsers and operating systems, and thus it is likely that their organization will support this proposal via an implementation. Personnel Steve Kent is the Document Shepherd. Sean Turner the Responsible Area Director. From turners@ieca.com Mon Nov 26 16:02:36 2012 Return-Path: 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 76ECB21F84E6 for ; Mon, 26 Nov 2012 16:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 jKfW9+pfTSqf for ; Mon, 26 Nov 2012 16:02:35 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.150.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7EED021F84E0 for ; Mon, 26 Nov 2012 16:02:35 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 3AAF57E6C340F; Mon, 26 Nov 2012 18:02:24 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 2BA567E6C33D6 for ; Mon, 26 Nov 2012 18:02:24 -0600 (CST) Received: from [108.45.19.185] (port=65244 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Td8dG-0008Ne-4L; Mon, 26 Nov 2012 18:02:34 -0600 Message-ID: <50B40319.3040406@ieca.com> Date: Mon, 26 Nov 2012 19:02:33 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Soltes, John W (John)" References: <50B392D8.4010300@nist.gov> <50B3D77C.90804@ieca.com> <630003DF15884B4884983E0EFEA6A28D03E1A3@AZ-US1EXMB05.global.avaya.com> In-Reply-To: <630003DF15884B4884983E0EFEA6A28D03E1A3@AZ-US1EXMB05.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:65244 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "pkix@ietf.org" , Stefan Santesson Subject: Re: [pkix] [Technical Errata Reported] RFC2560 (3417) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 00:02:36 -0000 Thanks I'll get that fixed. spt On 11/26/12 4:01 PM, Soltes, John W (John) wrote: > Your change missed one of the typos. > You also need to make the following change: > > OLD: > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage... > > NEW: > 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage... > > John > > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Monday, November 26, 2012 3:56 PM > To: pkix@ietf.org > Cc: Stefan Santesson; Soltes, John W (John) > Subject: Re: [pkix] [Technical Errata Reported] RFC2560 (3417) > > I was thinking along the same lines as David. I'm going to accept this > errata, but I'm going to: > > 1. Change it to editorial. This just seems to me like a typo. > > 2. Edit it down a bit: > > OLD: > > Systems or applications that rely on OCSP responses MUST be capable > of detecting and enforcing use of the id-ad-ocspSigning value as > described above. > > NEW: > > Systems or applications that rely on OCSP responses MUST be capable > of detecting and enforcing use of the id-kp-OCSPSigning value as > described above. > > 3. and put the bit about the " in the notes. > > spt > > On 11/26/12 11:03 AM, David A. Cooper wrote: >> It was actually noticed and corrected more than ten years ago (see >> Appendix D in >> http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-00). The error >> just got reintroduced in draft -05 of 2560bis. >> >> On 11/26/2012 08:59 AM, Stefan Santesson wrote: >>> Good catch in this errata. >>> >>> It's almost amazing that this has gone unnoticed for all these years :) >>> I have updated this in the coming draft 2560bis >>> >>> /Stefan >>> >>> >>> On 11/26/12 2:12 PM, "RFC Errata System" >>> wrote: >>> >>>> The following errata report has been submitted for RFC2560, >>>> "X.509 Internet Public Key Infrastructure Online Certificate Status >>>> Protocol - OCSP". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3417 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: John Soltes >>>> >>>> Section: 4.2.2.2 >>>> >>>> Original Text >>>> ------------- >>>> ...OCSP signing delegation SHALL be designated by the >>>> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >>>> extension included in the OCSP response signer's certificate. This >>>> certificate MUST be issued directly by the CA that issued the >>>> certificate in question. >>>> >>>> id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} >>>> >>>> Systems or applications that rely on OCSP responses MUST be capable >>>> of detecting and enforcing use of the id-ad-ocspSigning value as >>>> described above...They MUST reject the >>>> response if the certificate required to validate the signature on the >>>> response fails to meet at least one of the following criteria: >>>> >>>> ... >>>> >>>> 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage >>>> extension and is issued by the CA that issued the certificate in >>>> question." >>>> >>>> Corrected Text >>>> -------------- >>>> ...OCSP signing delegation SHALL be designated by the >>>> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >>>> extension included in the OCSP response signer's certificate. This >>>> certificate MUST be issued directly by the CA that issued the >>>> certificate in question. >>>> >>>> id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} >>>> >>>> Systems or applications that rely on OCSP responses MUST be capable >>>> of detecting and enforcing use of the id-kp-OCSPSigning value as >>>> described above...They MUST reject the >>>> response if the certificate required to validate the signature on the >>>> response fails to meet at least one of the following criteria: >>>> >>>> ... >>>> >>>> 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage >>>> extension and is issued by the CA that issued the certificate in >>>> question. >>>> >>>> Notes >>>> ----- >>>> The first paragraph specifies that an "id-kp-OCSPSigning" value be >>>> included, and it then defines that value as "id-kp-OCSPSigning OBJECT >>>> IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed >>>> alternative specify the use of an "id-ad-ocspSigning" value, which is >>>> not >>>> defined. I assume that "id-kp-OCSPSigning" should be used throughout? >>>> Also, the double quote mark at the end of the third listed alternative >>>> should be removed. >>>> >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC2560 (draft-ietf-pkix-ocsp-07) >>>> -------------------------------------- >>>> Title : X.509 Internet Public Key Infrastructure Online >>>> Certificate Status Protocol - OCSP >>>> Publication Date : June 1999 >>>> Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >>>> Adams >>>> Category : PROPOSED STANDARD >>>> Source : Public-Key Infrastructure (X.509) >>>> Area : Security >>>> Stream : IETF >>>> Verifying Party : IESG >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> . >>> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > From James.H.Manger@team.telstra.com Tue Nov 27 03:51:13 2012 Return-Path: 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 7B11421F84F9 for ; Tue, 27 Nov 2012 03:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 n05oZSfbY0GH for ; Tue, 27 Nov 2012 03:51:12 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id EC92621F84E0 for ; Tue, 27 Nov 2012 03:51:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,328,1352034000"; d="scan'208";a="106630930" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 27 Nov 2012 22:51:10 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="144559690" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcavi.tcif.telstra.com.au with ESMTP; 27 Nov 2012 22:51:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Tue, 27 Nov 2012 22:51:09 +1100 From: "Manger, James H" To: pkix mailing list , pkix chair , Phillip Hallam-Baker Date: Tue, 27 Nov 2012 22:51:07 +1100 Thread-Topic: [pkix] Protocol Action: 'DNS Certification Authority Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf-pkix-caa-15.txt) Thread-Index: Ac3MHhIoNqThfw5eRMWTTE+EUglZ6QAdaHqQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1150252B6F3@WSMSG3153V.srv.dir.telstra.com> References: <20121126213608.17569.30919.idtracker@ietfa.amsl.com> In-Reply-To: <20121126213608.17569.30919.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [pkix] Protocol Action: 'DNS Certification Authority Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf-pkix-caa-15.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 11:51:13 -0000 ZHJhZnQtaWV0Zi1wa2l4LWNhYS0xNSAod2hpY2ggc2VlbXMgdG8gaGF2ZSBqdXN0IGJlZW4gYXBw cm92ZWQpIHN0aWxsIGhhcyBhbiB1bmZpeGVkIHRlY2huaWNhbCB0eXBvOg0KDQpTZWN0aW9uIDMg IlRoZSBDQUEgUlIgdHlwZSIgbGlzdHMgdGhlIDMgcHJvcGVydHkgdGFncyB0aGF0IGFyZSBkZWZp bmVkLiBUaGUgc2Vjb25kIHNob3VsZCBiZSAiaXNzdWV3aWxkIiwgYnV0IGlzIGxpc3RlZCBhcyAi aXNzdWUiLg0KDQpXUk9ORw0KICAgaXNzdWUgPElzc3VlciBEb21haW4gTmFtZT4gWzsgPHRhZz12 YWx1ZT4gXSogOiAgVGhlIGlzc3VlIHByb3BlcnR5DQogICAgICBlbnRyeSBhdXRob3JpemVzIHRo ZSBob2xkZXIgb2YgdGhlIGRvbWFpbiBuYW1lIDxJc3N1ZXIgRG9tYWluDQogICAgICBOYW1lPiBv ciBhIHBhcnR5IGFjdGluZyB1bmRlciB0aGUgZXhwbGljaXQgYXV0aG9yaXR5IG9mIHRoZSBob2xk ZXINCiAgICAgIG9mIHRoYXQgZG9tYWluIG5hbWUgdG8gaXNzdWUgd2lsZGNhcmQgY2VydGlmaWNh dGVzIGZvciB0aGUgZG9tYWluDQogICAgICBpbiB3aGljaCB0aGUgcHJvcGVydHkgaXMgcHVibGlz aGVkLg0KDQpSSUdIVA0KICAgaXNzdWV3aWxkIDxJc3N1ZXIgRG9tYWluIE5hbWU+IFs7IDx0YWc9 dmFsdWU+IF0qIDogIFRoZSBpc3N1ZXdpbGQgcHJvcGVydHkNCiAgICAgIGVudHJ5IGF1dGhvcml6 ZXMgdGhlIGhvbGRlciBvZiB0aGUgZG9tYWluIG5hbWUgPElzc3VlciBEb21haW4NCiAgICAgIE5h bWU+IG9yIGEgcGFydHkgYWN0aW5nIHVuZGVyIHRoZSBleHBsaWNpdCBhdXRob3JpdHkgb2YgdGhl IGhvbGRlcg0KICAgICAgb2YgdGhhdCBkb21haW4gbmFtZSB0byBpc3N1ZSB3aWxkY2FyZCBjZXJ0 aWZpY2F0ZXMgZm9yIHRoZSBkb21haW4NCiAgICAgIGluIHdoaWNoIHRoZSBwcm9wZXJ0eSBpcyBw dWJsaXNoZWQuDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IHBraXgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBraXgtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFRoZSBJRVNHDQo+IFNlbnQ6IFR1ZXNkYXksIDI3 IE5vdmVtYmVyIDIwMTIgODozNiBBTQ0KPiBUbzogSUVURi1Bbm5vdW5jZQ0KPiBDYzogcGtpeCBt YWlsaW5nIGxpc3Q7IHBraXggY2hhaXI7IFJGQyBFZGl0b3INCj4gU3ViamVjdDogW3BraXhdIFBy b3RvY29sIEFjdGlvbjogJ0ROUyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQ0KPiBBdXRob3JpemF0 aW9uIChDQUEpIFJlc291cmNlIFJlY29yZCcgdG8gUHJvcG9zZWQgU3RhbmRhcmQgKGRyYWZ0LWll dGYtDQo+IHBraXgtY2FhLTE1LnR4dCkNCj4gDQo+IFRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUg Zm9sbG93aW5nIGRvY3VtZW50Og0KPiAtICdETlMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQXV0 aG9yaXphdGlvbiAoQ0FBKSBSZXNvdXJjZSBSZWNvcmQnDQo+ICAgKGRyYWZ0LWlldGYtcGtpeC1j YWEtMTUudHh0KSBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gVGhpcyBkb2N1bWVudCBpcyB0 aGUgcHJvZHVjdCBvZiB0aGUgUHVibGljLUtleSBJbmZyYXN0cnVjdHVyZSAoWC41MDkpDQo+IFdv cmtpbmcgR3JvdXAuDQo+IA0KPiBUaGUgSUVTRyBjb250YWN0IHBlcnNvbnMgYXJlIFNlYW4gVHVy bmVyIGFuZCBTdGVwaGVuIEZhcnJlbGwuDQo+IA0KPiBBIFVSTCBvZiB0aGlzIEludGVybmV0IERy YWZ0IGlzOg0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGtp eC1jYWEvDQo+IA0KPiANCj4gDQo+IA0KPiBUZWNobmljYWwgU3VtbWFyeQ0KPiANCj4gVGhlIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IEF1dGhvcml6YXRpb24gKENBQSkgRE5TIFJlc291cmNlIFJl Y29yZA0KPiBhbGxvd3MgYSBETlMgZG9tYWluIG5hbWUgaG9sZGVyIHRvIHNwZWNpZnkgb25lIG9y IG1vcmUgQ2VydGlmaWNhdGlvbg0KPiBBdXRob3JpdGllcyBhdXRob3JpemVkIHRvIGlzc3VlIGNl cnRpZmljYXRlcyBmb3IgdGhhdCBkb21haW4uIENBQQ0KPiByZXNvdXJjZSByZWNvcmRzIGFsbG93 IGEgcHVibGljIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IHRvIGltcGxlbWVudA0KPiBhZGRpdGlv bmFsIGNvbnRyb2xzIHRvIHJlZHVjZSB0aGUgcmlzayBvZiB1bmludGVuZGVkIGNlcnRpZmljYXRl IG1pcy0NCj4gaXNzdWUuDQo+IA0KPiBXb3JraW5nIEdyb3VwIFN1bW1hcnkNCj4gDQo+IFRoaXMg ZG9jdW1lbnQgbWlnaHQgaGF2ZSBiZWVuIHB1cnN1ZWQgaW4gb3RoZXIgV0dzLCBzcGVjaWZpY2Fs bHkNCj4gRE5TRVhULCBzaW5jZSBpdCBzcGVjaWZpZXMgYSBuZXcgRE5TIHJlY29yZCB0eXBlLiBJ dCBhbHNvIG1pZ2h0IGhhdmUNCj4gYmVlbiBwdXJzdWVkIGluIERBTkUsIGJ1dCB0aGUgZm9jdXMg b2YgREFORSBpcyBzdWZmaWNpZW50bHkgZGlmZmVyZW50DQo+IHRoYXQgaXQgaXMgcHJvYmFibHkg bm90IGEgZ29vZCBmaXQgdGhlcmUuIEJlY2F1c2UgdGhlIGRvY3VtZW50DQo+IHNwZWNpZmllcw0K PiBhIEROUyByZWNvcmQgdHlwZSwgZm9yIHVzZSB3aXRoIFBLSSB0ZWNobm9sb2d5LCBQS0lYIHdh cyByZWFzb25hYmxlDQo+IGNob2ljZSBmb3IgdGhlIGF1dGhvcnMuIFRoZXJlIHdhcyBzb21lIGNv bnRyb3ZlcnN5IGluaXRpYWxseSwgYnV0IHRoYXQNCj4gd2VudCBhd2F5IG92ZXIgdGltZS4NCj4g DQo+IERvY3VtZW50IFF1YWxpdHkNCj4gDQo+IEkgYW0gbm90IGF3YXJlIG9mIGFueSBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHByb3RvY29sLCBidXQNCj4gYm90aCBhdXRob3JzIHdv cmsgZm9yIGEgY29tcGFueSB0aGF0IGlzIHJlcHJlc2VudGVkIGJ5IGEgdHJ1c3QgYW5jaG9yDQo+ IGluDQo+IGJyb3dzZXJzIGFuZCBvcGVyYXRpbmcgc3lzdGVtcywgYW5kIHRodXMgaXQgaXMgbGlr ZWx5IHRoYXQgdGhlaXINCj4gb3JnYW5pemF0aW9uIHdpbGwgc3VwcG9ydCB0aGlzIHByb3Bvc2Fs IHZpYSBhbiBpbXBsZW1lbnRhdGlvbi4NCj4gDQo+IFBlcnNvbm5lbA0KPiANCj4gU3RldmUgS2Vu dCBpcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQuDQo+IFNlYW4gVHVybmVyIHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gcGtpeCBtYWlsaW5nIGxpc3QNCj4gcGtpeEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCg== From hallam@gmail.com Tue Nov 27 07:59:20 2012 Return-Path: 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 AFE8421F8651 for ; Tue, 27 Nov 2012 07:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.038 X-Spam-Level: X-Spam-Status: No, score=-4.038 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 M7Luo3RhIIsk for ; Tue, 27 Nov 2012 07:59:19 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A86E021F8519 for ; Tue, 27 Nov 2012 07:59:19 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id m14so1942657yen.31 for ; Tue, 27 Nov 2012 07:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w3vy81Jq3OumzjBf6w9GPqX5KwakMZGzMswVTUHprLs=; b=HZtxvJIHaht6OnCh3A4qbIUp5KO9F1VomXeozdTb+4HbuhSdy7Yb3f3QHzgLsureC6 OPv3Sq5EvsaKiPl1x0f/GYR7LQZsZX47O8szQaNw/UpUZQ98FrnO1Acz88YiuCrZtsua 6DugEu8nVV6lgLNMs6rp/m2y+qG4xEoVuDZDnFJ1A8InDEqOovLWZPWDAljnSQGvpWmK cxoBLtagNMLWC1QhzZzIHOscqIaJwNJYMWohog69CQQ4PzWXuXXpWMVAQuiSs9vGb1FA D9L201SeKQGK2j1ot2qU0Jl2wfIDhsKkUwGuZdjCeO/aahEhSYqkl7cp8/GMIIpYDngP yIDw== MIME-Version: 1.0 Received: by 10.58.39.42 with SMTP id m10mr25971162vek.21.1354031959175; Tue, 27 Nov 2012 07:59:19 -0800 (PST) Received: by 10.58.19.130 with HTTP; Tue, 27 Nov 2012 07:59:18 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150252B6F3@WSMSG3153V.srv.dir.telstra.com> References: <20121126213608.17569.30919.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E1150252B6F3@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 27 Nov 2012 10:59:18 -0500 Message-ID: From: Phillip Hallam-Baker To: "Manger, James H" Content-Type: multipart/alternative; boundary=089e0115e9d4f0f06d04cf7c216f Cc: pkix mailing list , pkix chair Subject: Re: [pkix] Protocol Action: 'DNS Certification Authority Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf-pkix-caa-15.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:59:20 -0000 --089e0115e9d4f0f06d04cf7c216f Content-Type: text/plain; charset=ISO-8859-1 Yes, I will fix this and a couple of other typos. On Tue, Nov 27, 2012 at 6:51 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > draft-ietf-pkix-caa-15 (which seems to have just been approved) still has > an unfixed technical typo: > > Section 3 "The CAA RR type" lists the 3 property tags that are defined. > The second should be "issuewild", but is listed as "issue". > > WRONG > issue [; ]* : The issue property > entry authorizes the holder of the domain name Name> or a party acting under the explicit authority of the holder > of that domain name to issue wildcard certificates for the domain > in which the property is published. > > RIGHT > issuewild [; ]* : The issuewild > property > entry authorizes the holder of the domain name Name> or a party acting under the explicit authority of the holder > of that domain name to issue wildcard certificates for the domain > in which the property is published. > > > -- > James Manger > > > -----Original Message----- > > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > > The IESG > > Sent: Tuesday, 27 November 2012 8:36 AM > > To: IETF-Announce > > Cc: pkix mailing list; pkix chair; RFC Editor > > Subject: [pkix] Protocol Action: 'DNS Certification Authority > > Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf- > > pkix-caa-15.txt) > > > > The IESG has approved the following document: > > - 'DNS Certification Authority Authorization (CAA) Resource Record' > > (draft-ietf-pkix-caa-15.txt) as Proposed Standard > > > > This document is the product of the Public-Key Infrastructure (X.509) > > Working Group. > > > > The IESG contact persons are Sean Turner and Stephen Farrell. > > > > A URL of this Internet Draft is: > > http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ > > > > > > > > > > Technical Summary > > > > The Certification Authority Authorization (CAA) DNS Resource Record > > allows a DNS domain name holder to specify one or more Certification > > Authorities authorized to issue certificates for that domain. CAA > > resource records allow a public Certification Authority to implement > > additional controls to reduce the risk of unintended certificate mis- > > issue. > > > > Working Group Summary > > > > This document might have been pursued in other WGs, specifically > > DNSEXT, since it specifies a new DNS record type. It also might have > > been pursued in DANE, but the focus of DANE is sufficiently different > > that it is probably not a good fit there. Because the document > > specifies > > a DNS record type, for use with PKI technology, PKIX was reasonable > > choice for the authors. There was some controversy initially, but that > > went away over time. > > > > Document Quality > > > > I am not aware of any existing implementations of the protocol, but > > both authors work for a company that is represented by a trust anchor > > in > > browsers and operating systems, and thus it is likely that their > > organization will support this proposal via an implementation. > > > > Personnel > > > > Steve Kent is the Document Shepherd. > > Sean Turner the Responsible Area Director. > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --089e0115e9d4f0f06d04cf7c216f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I will fix this and a couple of other typos.

On Tue, Nov 27, 2012 at 6:51 AM, Manger, James H <J= ames.H.Manger@team.telstra.com> wrote:
draft-ietf-pkix-caa-15 (which seems to have = just been approved) still has an unfixed technical typo:

Section 3 "The CAA RR type" lists the 3 property tags that are de= fined. The second should be "issuewild", but is listed as "i= ssue".

WRONG
=A0 =A0issue <Issuer Domain Name> [; <tag=3Dvalue> ]* : =A0The = issue property
=A0 =A0 =A0 entry authorizes the holder of the domain name <Issuer Domai= n
=A0 =A0 =A0 Name> or a party acting under the explicit authority of the = holder
=A0 =A0 =A0 of that domain name to issue wildcard certificates for the doma= in
=A0 =A0 =A0 in which the property is published.

RIGHT
=A0 =A0issuewild <Issuer Domain Name> [; <tag=3Dvalue> ]* : =A0= The issuewild property
=A0 =A0 =A0 entry authorizes the holder of the domain name <Issuer Domai= n
=A0 =A0 =A0 Name> or a party acting under the explicit authority of the = holder
=A0 =A0 =A0 of that domain name to issue wildcard certificates for the doma= in
=A0 =A0 =A0 in which the property is published.


--
James Manger

> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
> The IESG
> Sent: Tuesday, 27 November 2012 8:36 AM
> To: IETF-Announce
> Cc: pkix mailing list; pkix chair; RFC Editor
> Subject: [pkix] Protocol Action: 'DNS Certification Authority
> Authorization (CAA) Resource Record' to Proposed Standard (draft-i= etf-
> pkix-caa-15.txt)
>
> The IESG has approved the following document:
> - 'DNS Certification Authority Authorization (CAA) Resource Record= '
> =A0 (draft-ietf-pkix-caa-15.txt) as Proposed Standard
>
> This document is the product of the Public-Key Infrastructure (X.509)<= br> > Working Group.
>
> The IESG contact persons are Sean Turner and Stephen Farrell.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/
>
>
>
>
> Technical Summary
>
> The Certification Authority Authorization (CAA) DNS Resource Record > allows a DNS domain name holder to specify one or more Certification > Authorities authorized to issue certificates for that domain. CAA
> resource records allow a public Certification Authority to implement > additional controls to reduce the risk of unintended certificate mis-<= br> > issue.
>
> Working Group Summary
>
> This document might have been pursued in other WGs, specifically
> DNSEXT, since it specifies a new DNS record type. It also might have > been pursued in DANE, but the focus of DANE is sufficiently different<= br> > that it is probably not a good fit there. Because the document
> specifies
> a DNS record type, for use with PKI technology, PKIX was reasonable > choice for the authors. There was some controversy initially, but that=
> went away over time.
>
> Document Quality
>
> I am not aware of any existing implementations of the protocol, but > both authors work for a company that is represented by a trust anchor<= br> > in
> browsers and operating systems, and thus it is likely that their
> organization will support this proposal via an implementation.
>
> Personnel
>
> Steve Kent is the Document Shepherd.
> Sean Turner the Responsible Area Director.
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix



--
= Website: http://hallambaker.com/
--089e0115e9d4f0f06d04cf7c216f-- From soltes@avaya.com Mon Nov 26 13:02:05 2012 Return-Path: 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 D128621F8594 for ; Mon, 26 Nov 2012 13:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 au3bvcy+sGfW for ; Mon, 26 Nov 2012 13:02:05 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4221F8531 for ; Mon, 26 Nov 2012 13:02:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKUvoFCHCzI1/2dsb2JhbAAqGoJswGmBCIIeAQEBAQMBAQEPKDQLDAQCAQgNBAQBAQEKFAkHJwsUCQgCBAENBQgah2gBCi2deZwAjBWFaWEDlxiEcYo2gm9yax4GGA X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="333943738" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Nov 2012 15:56:38 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Nov 2012 15:38:19 -0500 Received: from AZ-US1EXHC02.global.avaya.com (135.11.85.13) by DC-US1HCEX2.global.avaya.com (135.11.52.37) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 26 Nov 2012 16:01:58 -0500 Received: from AZ-US1EXMB05.global.avaya.com ([fe80::d51e:20b6:bd25:82b7]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0318.004; Mon, 26 Nov 2012 16:01:57 -0500 From: "Soltes, John W (John)" To: Sean Turner , "pkix@ietf.org" Thread-Topic: [pkix] [Technical Errata Reported] RFC2560 (3417) Thread-Index: AQHNzBiBbZnwsGvj6Uin5iH2wOI2MZf8mVwQ Date: Mon, 26 Nov 2012 21:01:57 +0000 Message-ID: <630003DF15884B4884983E0EFEA6A28D03E1A3@AZ-US1EXMB05.global.avaya.com> References: <50B392D8.4010300@nist.gov> <50B3D77C.90804@ieca.com> In-Reply-To: <50B3D77C.90804@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 27 Nov 2012 09:49:55 -0800 Cc: Stefan Santesson Subject: Re: [pkix] [Technical Errata Reported] RFC2560 (3417) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 21:03:36 -0000 Your change missed one of the typos. You also need to make the following change: OLD: 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage... NEW: 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage... John -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Monday, November 26, 2012 3:56 PM To: pkix@ietf.org Cc: Stefan Santesson; Soltes, John W (John) Subject: Re: [pkix] [Technical Errata Reported] RFC2560 (3417) I was thinking along the same lines as David. I'm going to accept this=20 errata, but I'm going to: 1. Change it to editorial. This just seems to me like a typo. 2. Edit it down a bit: OLD: Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above. NEW: Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-kp-OCSPSigning value as described above. 3. and put the bit about the " in the notes. spt On 11/26/12 11:03 AM, David A. Cooper wrote: > It was actually noticed and corrected more than ten years ago (see > Appendix D in > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-00). The error > just got reintroduced in draft -05 of 2560bis. > > On 11/26/2012 08:59 AM, Stefan Santesson wrote: >> Good catch in this errata. >> >> It's almost amazing that this has gone unnoticed for all these years :) >> I have updated this in the coming draft 2560bis >> >> /Stefan >> >> >> On 11/26/12 2:12 PM, "RFC Errata System" >> wrote: >> >>> The following errata report has been submitted for RFC2560, >>> "X.509 Internet Public Key Infrastructure Online Certificate Status >>> Protocol - OCSP". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D2560&eid=3D3417 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: John Soltes >>> >>> Section: 4.2.2.2 >>> >>> Original Text >>> ------------- >>> ...OCSP signing delegation SHALL be designated by the >>> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >>> extension included in the OCSP response signer's certificate. This >>> certificate MUST be issued directly by the CA that issued the >>> certificate in question. >>> >>> id-kp-OCSPSigning OBJECT IDENTIFIER ::=3D {id-kp 9} >>> >>> Systems or applications that rely on OCSP responses MUST be capable >>> of detecting and enforcing use of the id-ad-ocspSigning value as >>> described above...They MUST reject the >>> response if the certificate required to validate the signature on th= e >>> response fails to meet at least one of the following criteria: >>> >>> ... >>> >>> 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage >>> extension and is issued by the CA that issued the certificate in >>> question." >>> >>> Corrected Text >>> -------------- >>> ...OCSP signing delegation SHALL be designated by the >>> inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate >>> extension included in the OCSP response signer's certificate. This >>> certificate MUST be issued directly by the CA that issued the >>> certificate in question. >>> >>> id-kp-OCSPSigning OBJECT IDENTIFIER ::=3D {id-kp 9} >>> >>> Systems or applications that rely on OCSP responses MUST be capable >>> of detecting and enforcing use of the id-kp-OCSPSigning value as >>> described above...They MUST reject the >>> response if the certificate required to validate the signature on th= e >>> response fails to meet at least one of the following criteria: >>> >>> ... >>> >>> 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage >>> extension and is issued by the CA that issued the certificate in >>> question. >>> >>> Notes >>> ----- >>> The first paragraph specifies that an "id-kp-OCSPSigning" value be >>> included, and it then defines that value as "id-kp-OCSPSigning OBJECT >>> IDENTIFIER ::=3D {id-kp 9}", yet the second paragraph and the third lis= ted >>> alternative specify the use of an "id-ad-ocspSigning" value, which is >>> not >>> defined. I assume that "id-kp-OCSPSigning" should be used throughout? >>> Also, the double quote mark at the end of the third listed alternative >>> should be removed. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC2560 (draft-ietf-pkix-ocsp-07) >>> -------------------------------------- >>> Title : X.509 Internet Public Key Infrastructure Online >>> Certificate Status Protocol - OCSP >>> Publication Date : June 1999 >>> Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >>> Adams >>> Category : PROPOSED STANDARD >>> Source : Public-Key Infrastructure (X.509) >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> . >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From turners@ieca.com Tue Nov 27 10:18:48 2012 Return-Path: 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 1994821F85AD for ; Tue, 27 Nov 2012 10:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 MS-Fn9fMHGAy for ; Tue, 27 Nov 2012 10:18:47 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.239.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA0F21F85F5 for ; Tue, 27 Nov 2012 10:18:44 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 449BC803B7A3E; Tue, 27 Nov 2012 12:15:57 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 31F90803B7439 for ; Tue, 27 Nov 2012 12:15:56 -0600 (CST) Received: from [108.45.19.185] (port=55966 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TdPhW-00039B-Aj; Tue, 27 Nov 2012 12:16:06 -0600 Message-ID: <50B50366.3030306@ieca.com> Date: Tue, 27 Nov 2012 13:16:06 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Manger, James H" References: <20121126213608.17569.30919.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E1150252B6F3@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150252B6F3@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:55966 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix mailing list , pkix chair Subject: Re: [pkix] Protocol Action: 'DNS Certification Authority Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf-pkix-caa-15.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:18:48 -0000 I got it updated to: http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3417 spt On 11/27/12 6:51 AM, Manger, James H wrote: > draft-ietf-pkix-caa-15 (which seems to have just been approved) still has an unfixed technical typo: > > Section 3 "The CAA RR type" lists the 3 property tags that are defined. The second should be "issuewild", but is listed as "issue". > > WRONG > issue [; ]* : The issue property > entry authorizes the holder of the domain name Name> or a party acting under the explicit authority of the holder > of that domain name to issue wildcard certificates for the domain > in which the property is published. > > RIGHT > issuewild [; ]* : The issuewild property > entry authorizes the holder of the domain name Name> or a party acting under the explicit authority of the holder > of that domain name to issue wildcard certificates for the domain > in which the property is published. > > > -- > James Manger > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> The IESG >> Sent: Tuesday, 27 November 2012 8:36 AM >> To: IETF-Announce >> Cc: pkix mailing list; pkix chair; RFC Editor >> Subject: [pkix] Protocol Action: 'DNS Certification Authority >> Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf- >> pkix-caa-15.txt) >> >> The IESG has approved the following document: >> - 'DNS Certification Authority Authorization (CAA) Resource Record' >> (draft-ietf-pkix-caa-15.txt) as Proposed Standard >> >> This document is the product of the Public-Key Infrastructure (X.509) >> Working Group. >> >> The IESG contact persons are Sean Turner and Stephen Farrell. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ >> >> >> >> >> Technical Summary >> >> The Certification Authority Authorization (CAA) DNS Resource Record >> allows a DNS domain name holder to specify one or more Certification >> Authorities authorized to issue certificates for that domain. CAA >> resource records allow a public Certification Authority to implement >> additional controls to reduce the risk of unintended certificate mis- >> issue. >> >> Working Group Summary >> >> This document might have been pursued in other WGs, specifically >> DNSEXT, since it specifies a new DNS record type. It also might have >> been pursued in DANE, but the focus of DANE is sufficiently different >> that it is probably not a good fit there. Because the document >> specifies >> a DNS record type, for use with PKI technology, PKIX was reasonable >> choice for the authors. There was some controversy initially, but that >> went away over time. >> >> Document Quality >> >> I am not aware of any existing implementations of the protocol, but >> both authors work for a company that is represented by a trust anchor >> in >> browsers and operating systems, and thus it is likely that their >> organization will support this proposal via an implementation. >> >> Personnel >> >> Steve Kent is the Document Shepherd. >> Sean Turner the Responsible Area Director. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >