Re: [pkix] Proposed resolution to non-issued certificates - 2560bis
Stefan Santesson <stefan@aaa-sec.com> Fri, 02 November 2012 15:17 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 0B6C71F0C42 for <pkix@ietfa.amsl.com>; 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 <pkix@ietfa.amsl.com>; 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 <pkix@ietf.org>; 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 <pkix@ietf.org>; 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 <pkix@ietf.org>; 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 <pkix@ietf.org>; 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 <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 15:14:12 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Fri, 02 Nov 2012 16:14:15 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Piyush Jain <piyush@ditenity.com>, pkix@ietf.org
Message-ID: <CCB9A0A3.52A49%stefan@aaa-sec.com>
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 <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 15:17:57 -0000
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