Re: [pkix] Proposed resolution to non-issued certificates - 2560bis
Stefan Santesson <stefan@aaa-sec.com> Fri, 02 November 2012 16:26 UTC
Return-Path: <stefan@aaa-sec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDA51F0C44 for <pkix@ietfa.amsl.com>; Fri, 2 Nov 2012 09:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.695
X-Spam-Level:
X-Spam-Status: No, score=-101.695 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gpjvvIcOhaJ for <pkix@ietfa.amsl.com>; Fri, 2 Nov 2012 09:25:59 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0C70121F8CF5 for <pkix@ietf.org>; Fri, 2 Nov 2012 09:25:58 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id A4163364C0 for <pkix@ietf.org>; Fri, 2 Nov 2012 17:24:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gQMeKE7AIK1x for <pkix@ietf.org>; Fri, 2 Nov 2012 17:24:47 +0100 (CET)
Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 93051364B3 for <pkix@ietf.org>; Fri, 2 Nov 2012 17:24:47 +0100 (CET)
Received: (qmail 18647 invoked from network); 2 Nov 2012 16:24:47 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.113]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender <stefan@aaa-sec.com>) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <piyush@ditenity.com>; 2 Nov 2012 16:24:47 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Fri, 02 Nov 2012 17:24:52 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Piyush Jain <piyush@ditenity.com>, pkix@ietf.org
Message-ID: <CCB9B1A1.52A72%stefan@aaa-sec.com>
Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis
In-Reply-To: <040701cdb910$5d7841f0$1868c5d0$@ditenity.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Nov 2012 16:26:00 -0000
Piyush and Dave I'm so sorry. To much stress today. I completely misread your post. Yes, you made a great point. Thanks for bringing it up. I agree, it makes perfect sense to not allow the CRL references extension when responding to non-issued certificates. /Stefan On 11/2/12 4:40 PM, "Piyush Jain" <piyush@ditenity.com> wrote: >Couple of points Stefan > >1) The responder is not broadcasting this to the whole world. Only to the >external person who is sending such a request. None of the pkix standards >say that if a revocation provider cites caCompromise as reason for >revocation for an issued certificated, all the certificates issued by that >CA should be considered revoked. On a side note, it might not be a bad >thing >if the RP can authoritatively determine if the CA was compromised. >However, >it does not apply in this case because it seems that any talk of responder >trust is taboo in the scope of this discussion. > >2) CRL References is a single response extension which is part of OCSP. I >can't imagine how this proposed change affects an extension define within >OCSP can be out of scope. > >> -----Original Message----- >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Friday, November 02, 2012 8:14 AM >> To: Piyush Jain; pkix@ietf.org >> Subject: Re: [pkix] Proposed resolution to non-issued certificates - >2560bis >> >> >> >> On 11/1/12 11:12 PM, "Piyush Jain" <piyush@ditenity.com> wrote: >> >> >So far we've outlined 3 scenarios in which this response makes sense >> >1) Buggy Client >> >2) Malicious client >> >3) CA compromise >> > >> >For 1 and 2, the content of the response does not matter. >> >That leaves us with 3 in which case caCompromise is right choice. And >> >your conclusion is right. Once the CA is compromised, no certificates >> >issued by that CA could be trusted. >> >> Right, so no external person should be able to cause the OCSP responder >>to >> claim that the CA is compromised, unless the CA is compromised. >> >> >> > >> >BTW, I hope that there will be guidance in the updated draft on what to >> >include in CRL References extension in such cases. >> >It might suffice to say that the responder MUST not include the CRL >> >References extension if it is issuing revoked for fraudulently-issued >> >certificates. >> >> >> No, that would be outside of the scope of the OCSP standard. This >>standard >> describes the OCSP protocol. It can't pose requirements on use of other >> services. >> >> /Stefan >> >> > >> >-Piyush >> > >> >> -----Original Message----- >> >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> >> Sent: Thursday, November 01, 2012 12:38 PM >> >> To: Piyush Jain; pkix@ietf.org >> >> Subject: Re: [pkix] Proposed resolution to non-issued certificates - >> >2560bis >> >> >> >> To clear a few things up. >> >> >> >> The current draft does not reflect the straw-poll. It will be updated >> >> to capture that which is/will be agreed. >> >> >> >> CA compromise is a worse choice since it could be interpreted that no >> >certs >> >> from that CA can be trusted. >> > >> > >> >> certificateHold only affects that serialNumber and only temporary, >> >>thus it >> >is >> >> more suitable from a practical standpoint. >> > >> > >> >> >> >> Yes, combined with the optional extension, "good" will be a positive >> >> statement of the existence of the cert. This is perfectly compliant >> >> with >> >the >> >> current "good" text saying "Response extensions may be used to convey >> >> additional information on assertions made by the responder regarding >> >> the status of the certificate such as positive statement about >> >> issuance, >> >validity, >> >> etc" >> >> >> >> /Stefan >> >> >> >> >> >> >> >> On 11/1/12 5:37 PM, "Piyush Jain" <piyush@ditenity.com> wrote: >> >> >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> >> >> Sent: Thursday, November 01, 2012 8:40 AM >> >> >> To: Piyush Jain; pkix@ietf.org >> >> >> Subject: Re: [pkix] Proposed resolution to non-issued certificates >> >> >> - >> >> >2560bis >> >> >> >> >> >> As a short reply. >> >> >> >> >> >> No, the good response is still true from a very practical >> >>perspective. >> >> >> It is exactly as written. >> >> >[Piyush] I'm sure you have your reasons. But the obvious question >> >> >that comes to my mind is that if a responder returns revoked for >> >> >non-issued, than why can't good be considered a proof of issuance. >> >> >The current text fails to capture this. >> >> >> >> >> >> Secondly, >> >> >> Even if the major reason for allowing revoked for non-ussued certs >> >> >> is to detect/react to compromised CA situations, >> >> >[Piyush] That is the reason that has been cited. The way I see it is >> >> >to allow CAs to continue operations even after the compromise. I >> >> >have not seen a single discussion on how CA would react if starts >> >> >getting such requests. >> >> >It does give the CAs the tool to advertise the security of their >> >> >systems to unsuspecting customers who do not understand the OCSP >> >> >trust model. >> >> > >> >> >>this does NOT mean that any >> >> >> request for a non-issued cert is caused by a compromised CA. >> >> > >> >> >[Piyush]Nor does it mean that certificate was issued and put on >> >> >hold, which is what certifcateOnHold implies. >> >> > >> >> >> >> >> >> It can simply be caused by a bug in the requesting client or a >> >> >>deliberate >> >> >false >> >> >> request. >> >> >[Piyush] In either of these cases, what the responder returns has no >> >> >value. >> >> >The best response in such cases is to return transport level error >> >> >(HTTP 422). >> >> >I hope that the expectation here is not that this response will help >> >> >RPs to recover from software bugs or that it will teach malicious >> >> >clients to play nice. >> >> > >> >> >> It's therefore wrong to reply that the CA is compromised, unless >> >> >>you know that the CA is compromised. >> >> >[Piyush] Only scenario that matters is the one in which CA is >> >compromised. >> >> >In every other scenario the content of the response is irrelevant. >> >> >> >> >> >> /Stefan >> >> >> >> >> >> >> >> >> On 11/1/12 4:23 PM, "Piyush Jain" <piyush@ditenity.com> wrote: >> >> >> >> >> >> > >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> >> >> >> Sent: Thursday, November 01, 2012 6:11 AM >> >> >> >> To: Piyush Jain; pkix@ietf.org >> >> >> >> Subject: Re: [pkix] Proposed resolution to non-issued >> >> >> >> certificates >> >> >> >> - >> >> >> >2560bis >> >> >> >> >> >> >> >> In-line; >> >> >> >> >> >> >> >> On 11/1/12 12:12 AM, "Piyush Jain" <piyush@ditenity.com> wrote: >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> >> -----Original Message----- >> >> >> >> >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] >> >> >> >> >> On Behalf Of Stefan Santesson >> >> >> >> >> Sent: Wednesday, October 31, 2012 11:47 AM >> >> >> >> >> To: pkix@ietf.org >> >> >> >> >> Subject: [pkix] Proposed resolution to non-issued >> >> >> >> >> certificates >> >> >> >> >> - 2560bis >> >> >> >> >> >> >> >> >> >> I didn't put up an end date for the straw-poll, but the >> >> >> >> >>trend seems clear. >> >> >> >> >> >> >> >> >> >> The results so far (if I counted right) >> >> >> >> >> >> >> >> >> >> Supporting #1: 22 >> >> >> >> >> Supporting #2: 0 >> >> >> >> >> Supporting #3 using "unknown": 6 Supporting #3 using >> >> >> >> >> "unauthorised: 2 >> >> >> >> >> >> >> >> >> >> 6 persons supporting #1 has expressed various levels of >> >> >> >> >>support/demand for an explicit declaration that the OCSP >> >> >> >> >>responder supports the enhanced definition of "revoked" to >> >> >> >> >>include "no >> >> >issued". >> >> >> >> >> >> >> >> >> >> 1 person responded off-line supporting #1. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> If the trend reflects the opinion of the WG. This is my >> >> >> >> >> proposed >> >> >> >> >> resolution: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 1) Extend the "revoked" response to also be allowed for >> >> >> >> >> non-issued certificates. Clearly stating that this is >> >> >> >> >> optional if and only if the >> >> >> >> >OCSP >> >> >> >> >> responder knows that the requested serial number has never >> >> >> >> >> been >> >> >> >> issued. >> >> >> >> >[Piyush] This requires changing the current text for 'good'. >> >> >> >> >Pasted for your reference >> >> >> >> > >> >> >> >> >The "good" state indicates a positive response to the status >> >> >>inquiry. >> >> >> >> > At a minimum, this positive response indicates that the >> >> >>certificate >> >> >> >> > is not revoked, but does not necessarily mean that the >> >> >>certificate >> >> >> >> > was ever issued or that the time at which the response was >> >> >>produced >> >> >> >> > is within the certificate's validity interval. Response >> >> >>extensions >> >> >> >> > may be used to convey additional information on assertions >> >> >> >> > made >> >> >>by >> >> >> >> > the responder regarding the status of the certificate such >>as >> >> >> >> > positive statement about issuance, validity, etc. >> >> >> >> >> >> >> >> This is still true. >> >> >> >[Piyush]It is tree in theoretical sense, but incomplete and >> >>confusing. >> >> >> >The meaning of 'good' changes, if the responder returns revoked >> >> >> >for 'fraudulently-issued' certificates. >> >> >> > In such cases, a positive proof implies that the certificate was >> >> >>issued. >> >> >> >Also, the last sentence in the above paragraph does not apply for >> >> >> >such responders. >> >> >> >> >> >> >> >> > >> >> >> >> >> 2) Specify that a "revoked" status for a non-issued >> >> >> >> >> certificate serial >> >> >> >> >number >> >> >> >> >> MUST have revocationTime set to Jan 1, 1970 and MUST set the >> >> >> >> >> revocationReason to certificateHold (6). >> >> >> >> >[Piyush] There were some objections on using certificateHold >> >> >> >> >as revocationReason for this purpose. CA compromise would be >> >> >> >> >more appropriate because the only scenario where this is >> >> >> >> >beneficial is when the CA is compromised. >> >> >> >> >> >> >> >> Absolutely not. The CA is not compromised just because I ask >> >> >> >>for a serial number that was never issued. >> >> >> > >> >> >> >[Piyush] All this time, the reason to propose this change has >> >> >> >been that it helps the situation where certificates are >> >> >> >fraudulently issued. If the RP is not doing signature checking >> >> >> >than this discussion is moot. If RP has verified that signature >> >> >> >is correct and CA thinks it is not issued, it is caCompromise. >> >> >> >CA may be compromised or not. But this response is telling the RP >> >> >> >that if he thinks that certificate is signed by the CA, then it >> >> >> >implies that CA is compromised. >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> 2) Define a new optional non-critical extension declaring >> >> >> >> >> that OCSP responder returns "revoked" for non-issued >> >> >> >> >> certificates according to the updated standard. This >> >> >> >> >> extension MUST be present in all responses where the >> >> >> >> >> "revoked" response is returned as a result of a status >> >> >> >> >> request for a >> >> >> >> >non- >> >> >> >> >> issued certificate. >> >> >> >> >[Piyush] Are you proposing that the specification of this >> >> >> >> >extension would be part of OCSP or it would be published as a >> >> >> >> >separate specification? >> >> >> >> >I think that it should not be part of main OCSP specification, >> >> >> >> >given that it is useful only in the exceptional scenario where >> >> >> >> >CA gets compromised. >> >> >> >> >> >> >> >> Proposing to include it in the base standard. It can also be >> >> >> >> used to >> >> >> >measure >> >> >> >> whether an OCSP responder adopts this response behaviour even >> >> >> >>if the CA is not compromised. >> >> >> >> >> >> >> >[Piyush] This is something new. So what are the benefits of this >> >> >> >if the CA is not compromised? What value does it add over >> >> >> >signature >> >> checking? >> >> >> >And I thought that in one of you previous emails you said that >> >> >> >there was a WG decision to limit changes to RFC 2560 to what is >> >> >> >necessary to resolve previous ambiguity. Don't know if that is >still the >> case. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Rationale: >> >> >> >> >> The certificateHold reason feels important for one >> >> >> >> >> particular >> >> >reason. >> >> >> >> >>If a >> >> >> >> >CA is >> >> >> >> >> issuing certificates with sequential serial numbers, then it >> >> >> >> >> could be >> >> >> >> >possible >> >> >> >> >> to obtain a revoked response for a certificate serial number >> >> >> >> >> that is not >> >> >> >> >yet >> >> >> >> >> issued, but soon will be issued. That the certificate serial >> >> >> >> >> number is >> >> >> >> >currently >> >> >> >> >> not issued, does not mean that it never will, thus the >> >> >> >> >> certificateHold >> >> >> >> >reason >> >> >> >> >> seems more appropriate. >> >> >> >> >> >> >> >> >> >[Piyush] Given that a fraudulent certificate has been issued >> >> >> >> >with a serial number, the CA would eventually revoke the >> >> >> >> >certificate with this serial number and would not issue any >> >> >> >> >newer certificate with the same >> >> >> >> serial. >> >> >> >> >I think the confusion arises from the fact that we've been >> >> >> >> >using 'not-issued' and 'fraudulently-issued' interchangeably. >> >> >> >> >All this time I'd been thinking that we are discussing the >> >> >> >> >latter. If that is indeed the case, caCompromise seems more >> appropriate. >> >> >> >> >> >> >> >> No, for reason above. >> >> >> >> >> >> >> >> > >> >> >> >> >> The date 1 Jan, 1970 is appropriate since it is common in >> >> >> >> >> programming languages to express time as milliseconds since >> >> >> >> >> jan 1, >> >> >> 1970. >> >> >> >> >> Selecting >> >> >> >> >this >> >> >> >> >> time avoids time expression as a negative integer. >> >> >> >> >> >> >> >> >> >> This date translates to (java): >> >> >> >> >> Date revocationTime = new Date(0); //Jan 1st, 1970 >> >> >> >> >> >> >> >> >> >> The extension would be a simple OID with no data structure >> >> >> >> >> and MUST not be set to critical. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Question: >> >> >> >> >> Would it make sense to require an OCSP responder that adopts >> >> >> >> >>the expanded use of "revoked" to always include the new >> >> extension? >> >> >> >> >> It would add the benefit that someone receiving "good" can >> >> >> >> >>know that the OCSP responder has checked that the >> >> >> >> >>certificate in fact has been issued by the CA. >> >> >> >> >> In such case it may be reasonable to add an optional data >> >> >> >> >>structure which MAY contain a hash of the cert. >> >> >> >> >> Such hash would make the positive confirmation even >> >> >> >> >>stronger, adding proof of existence of the certificate. >> >> >> >> >[Piyush] I hope that you realize that big enterprise PKI >> >> >> >> >deployments use OCSP and CRLs interchangeably. And with this >> >> >> >> >proposal OCSP becomes more authoritative than CRL. >> >> >> >> >So I guess the next step would be to change the basic path >> >> >> >> >validation algorithm to drop the use of CRLs in favor of OCSP >> >> >> >> >and also drop the signature verification (off course if the RP >> >> >> >> >knows that his OCSP responder issues stronger positive >> confirmations). >> >> >> >> >> >> >> >> It is not part of this work to update CRL processing or path >> >> >validation. >> >> >> >[Piyush] Are you saying that there is no need to evaluate how >> >> >> >this work affects other standards created by pkix. >> >> >> >> >> >> >> >> >> >> >> >> >> >> But perhaps this will bee too much to agree on :) >> >> >> >> >> >> >> >> >> >[Piyush] How about a thinner profile of SCVP that could >> >> >> >> >address everything you are trying to achieve in OCSP. >> >> >> >> >> >> >> >> It is neither part of this work to update SCVP. Just to update >> >>OCSP. >> >> >> >[Piyush] SCVP does not need to be updated. It already has >> >> >> >provisions for what you are trying to duplicate in OCSP. >> >> >> >> >> >> >> >> /Stefan >> >> >> >> >> >> >> > >> >> >> > >> >> >> >_______________________________________________ >> >> >> >pkix mailing list >> >> >> >pkix@ietf.org >> >> >> >https://www.ietf.org/mailman/listinfo/pkix >> >> >> >> >> > >> >> > >> >> >> > >> > >> > >
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter Rybar
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- [pkix] Straw-poll on OCSP responses for non-revok… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yngve Nysaeter Pettersen
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yoav Nir
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Miller, Timothy J.
- Re: [pkix] Straw-poll on OCSP responses for non-r… David Chadwick
- Re: [pkix] Straw-poll on OCSP responses for non-r… Art Allison
- Re: [pkix] Straw-poll on OCSP responses for non-r… Miller, Timothy J.
- Re: [pkix] Straw-poll on OCSP responses for non-r… Santosh Chokhani
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yoav Nir
- Re: [pkix] Straw-poll on OCSP responses for non-r… Peter Rybar
- Re: [pkix] Straw-poll on OCSP responses for non-r… Paul Hoffman
- Re: [pkix] Straw-poll on OCSP responses for non-r… Juan Gonzalez
- Re: [pkix] Straw-poll on OCSP responses for non-r… Max Pritikin (pritikin)
- Re: [pkix] Straw-poll on OCSP responses for non-r… Simon Tardell
- Re: [pkix] Straw-poll on OCSP responses for non-r… Carl Wallace
- Re: [pkix] Straw-poll on OCSP responses for non-r… Paul Hoffman
- Re: [pkix] Straw-poll on OCSP responses for non-r… Rick Robinson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Jeremy Rowley
- Re: [pkix] Straw-poll on OCSP responses for non-r… Melinda Shore
- Re: [pkix] Straw-poll on OCSP responses for non-r… Martin Rex
- Re: [pkix] Straw-poll on OCSP responses for non-r… Russ Housley
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Ritter
- Re: [pkix] Straw-poll on OCSP responses for non-r… Dr Stephen Henson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ryan Sleevi
- Re: [pkix] Straw-poll on OCSP responses for non-r… Johannes Merkle
- Re: [pkix] Straw-poll on OCSP responses for non-r… Denis Pinkas
- Re: [pkix] Straw-poll on OCSP responses for non-r… Art Allison
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ryan Hurst
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ben Wilson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] Straw-poll on OCSP responses fornon-re… Art Allison
- [pkix] Proposed resolution to non-issued certific… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Ritter
- Re: [pkix] Proposed resolution to non-issued cert… Tom Ritter
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter Gutmann
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Phillip Hallam-Baker
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Peter Rybar
- Re: [pkix] Proposed resolution to non-issued cert… Simon Tardell
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Peter Rybar
- Re: [pkix] Proposed resolution to non-issued cert… Simon Tardell
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Gindin
- Re: [pkix] Straw-poll on OCSP responses for non-r… Phillip Hallam-Baker