Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt
Stefan Santesson <stefan@aaa-sec.com> Thu, 01 October 2009 11:28 UTC
Return-Path: <stefan@aaa-sec.com>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B4028C11B for <pkix@core3.amsl.com>; Thu, 1 Oct 2009 04:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thHEVOHnceGX for <pkix@core3.amsl.com>; Thu, 1 Oct 2009 04:28:33 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 453D93A686A for <pkix@ietf.org>; Thu, 1 Oct 2009 04:28:31 -0700 (PDT)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6D8DD28D617 for <pkix@ietf.org>; Thu, 1 Oct 2009 13:29:56 +0200 (CEST)
Received: (qmail 54350 invoked from network); 1 Oct 2009 11:29:51 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <Nick.Pope@thales-esecurity.com>; 1 Oct 2009 11:29:51 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 01 Oct 2009 13:29:50 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Pope, Nick" <Nick.Pope@thales-esecurity.com>, "'denis.pinkas@bull.net'" <denis.pinkas@bull.net>
Message-ID: <C6EA5F4E.4FA0%stefan@aaa-sec.com>
Thread-Topic: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt
Thread-Index: AcpCinzJ1VReLnA7D0+GsVWTKuuMxw==
In-Reply-To: <6FC9E49ED3472043A38619BFA97F37B5046783B3@ukcrn08.crn.thales-esecurity.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3337248591_16389989"
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2009 11:28:57 -0000
I had a conversation with Pasi (Security AD). His reflection was: ³The security considerations text should help implementors and deployers in deciding whether to stick with ESSCertID or move to ESSCertIDv2 when implementing/deploying TSP. Personally, I think "some theoretical scenarios involving a trusted malicious CA" is a bit vague -- perhaps a slightly more understandable description is needed (but probably couple of sentences would be enough -- a very long and detailed analysis probably wouldn't be that helpful to the readers either). ² Following Pasi¹s recommendation I would suggest the following modification of my original proposal: ESSCertID provide means based on the SHA-1 hash algorithm for identifying the certificate used to verify the signature on a time stamp. The use of ESSCerIDv2 aims to enable implementers to comply with policies that require phasing out all uses of the SHA-1 algorithm. Upgrading the hash function through ESSCertIDv2 address a theoretical scenario involving a trusted malicious CA issuing a false but trusted TSA certificate where the hash of the false certificate is identical to the hash of the original TSA certificate. However, trusting a malicious CA to issue TSA certificates enables a wide range of other threats that are not mitigated by ESSCertIDv2. Threats in general, caused by a trusted malicious CA, are therefore out of scope of this specification. Hopefully this gives everyone what they need. /Stefan On 09-10-01 11:45 AM, "Pope, Nick" <Nick.Pope@thales-esecurity.com> wrote: > Stefan, > > OK - I was not aware of the practice of scoping threats separate from scoping > the RFC. Clearly, MECHANISMS addressing the threat of malicious CA are > outside the scope of this RFC (they are more to do with CA trust management). > > Do you want to propose the text for security considerations. May I suggest > this includes text the lines > "Mechanisms addressing the threat of malicious CAs and ensuring CAs are > trustworthy are outside the scope of this RFC." > > Nick > > > > > > > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: 29 September 2009 20:58 > To: Pope, Nick; 'denis.pinkas@bull.net' > Cc: pkix > Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt > > Nick, > > BCP 72 specifies guidelines for writing security considerations sections. > > It states: > > Authors MUST describe > > 1. which attacks are out of scope (and why!) > 2. which attacks are in-scope > 2.1 and the protocol is susceptible to > 2.2 and the protocol protects against > > The PKI trust model, on which we base time stamping, assumes that we are able > to determine which authorities we trust and that the data they provide in the > form of certificates are trustworthy. > As such, it is generally out of scope for a PKI based protocol to actively > defend against a trusted malicious CA. > If you as relaying party have a problem in this area, you ought to fix how you > trust Cas, rather than trying to build protocols that is secure despite trust > in malicious CAs. > > The reason is simply because the battle is lost anyway. If you trust me as CA, > and I'm a bad guy, I can screw you over in so many ways that you can't ever > fix through protocol design. > > If we are to follow BCP 72, we need to consider threats related to > ESSCertIDv2. The only one we know of is one involving a trusted malicious CA. > Further following BCP 72 we need to decide whether the threat of a trusted > malicious CA is in scope, or out of scope. > > Until we do that, and express it in writing, we are in a dead-lock position > and can't proceed with this draft. > > Agreeing on a fuzzy writing that gets the document stalled in IESG is not a > responsible path IMO. Thus I prefer a straw-poll. > > /Stefan > > > > On 09-09-29 7:18 PM, "Pope, Nick" <Nick.Pope@thales-esecurity.com> wrote: > Stefan, > > I don't understand the use of scope in "security considerations." The scope > of the RFC is ESSCert2. The discussion of security threats looks at the wider > security environment. How can one say certain threats relating to ESSCertv2 > are out of scope? It is reasonable that the security considerations does not > turn into a detailed analysis. > > I do think we are so close on this area. Given other areas of fuzziness in > RFCs I can't see oneone getting uptight about scope relating to the security > considerations. > > Nick > > > > > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: 29 September 2009 17:40 > To: Pope, Nick; 'denis.pinkas@bull.net <denis.pinkas@bull.net> ' > Cc: pkix > Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt > > Unfortunately I don't think any of them will get past the IESG review. > The obvious discuss will be "What are the threats, and are they in scope?" > > /Stefan > > On 09-09-29 6:24 PM, "Pope, Nick" <Nick.Pope@thales-esecurity.com> wrote: > Either is OK for me too. > > > -----Original Message----- > From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net] > Sent: 29 September 2009 17:19 > To: Pope, Nick > Cc: 'denis.pinkas@bull.net <denis.pinkas@bull.net> <denis.pinkas@bull.net> '; > pkix > Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt > > > Nick, > > > > I see two ways to solve and close this issue. > > > > Solution A. > > > > "ESSCertID provide means based on the SHA-1 hash algorithm for > identifying the certificate used to verify the signature on a time > stamp. The use of ESSCerIDv2 aims to enable implementers to comply > with policies that require phasing out all uses of the SHA-1 > algorithm. Upgrading the hash function through ESSCertIDv2 address > some theoretical scenarios involving a trusted malicious CA". > > > > Solution B. > > > > "ESSCertID provide means based on the SHA-1 hash algorithm for > identifying the certificate used to verify the signature on a time > stamp. The use of ESSCerIDv2 aims to enable implementers to comply > with policies that require phasing out all uses of the SHA-1 > algorithm. Upgrading the hash function through ESSCertIDv2 address > some theoretical scenarios involving a trusted malicious CA. This section > does not go into a detailed analysis of the threats relating to trusted > malicious CAs". > I can live with any of them. > > Denis > > -----pkix-bounces@ietf.org wrote: ----- > > To: "'denis.pinkas@bull.net <denis.pinkas@bull.net> ' <denis.pinkas@bull.net> > " <denis.pinkas@bull.net>, pkix <pkix@ietf.org> > From: "Pope, Nick" <Nick.Pope@thales-esecurity.com> > Sent by: pkix-bounces@ietf.org > Date: 09/29/2009 05:47PM > Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt > > Denis, > > I think the point is that this SecurityConsideration is not the place to go > into the detailed analysis of the threatsaround malicious CAs. > > Perhaps a statement to this effect that "Thissection does not go into a > detailed analysis of the threats relating tomalicious CAs." could be used > instead. > > Nick > > > > > -----Original Message----- > From: pkix-bounces@ietf.org[mailto:pkix-bounces > <pkix-bounces@ietf.org%5bmailto:pkix-bounces> > <pkix-bounces@ietf.org%5bmailto:pkix-bounces> @ietf.org] On Behalf Of > denis.pinkas@bull.net > Sent: 29 September 2009 16:42 > To: pkix > Subject: Re: [pkix] I-DAction:draft-ietf-pkix-rfc3161-update-06.txt > > > Stefan, > > > > You said: > > > > " I have no problem with the dispositionchange. The problem is that .." > > > > If you have really no problem, that let us pick myproposed wording. > > > > However, it seems that you do have a problem, so if it isreally the case > please do not write "I have no problem with the disposition change". > > > > Nothing is out of scope in a security considerationssection. In particular, > a trusted malicious CA is within the scope. The CA is trusted because > itbelongs > to a trusted certification path, but happens to maliciously issue a > TSAcertificate. > > In such a case, the original certificate can bereplaced in a log file without > anybody noticing it. > > > > So I can't agree to have the following sentence: > > > > "Threats caused by a trusted malicious CA ishowever out of scope of this > specification". > > Denis > > > -----pkix-bounces@ietf.orgwrote: ----- > > To: Dino Esposito <alfredo.esposito@infocert.it>,"Pope, Nick" > <Nick.Pope@thales-esecurity.com> > From: Stefan Santesson <stefan@aaa-sec.com> > Sent by: pkix-bounces@ietf.org > Date: 09/29/2009 02:39PM > cc: pkix <pkix@ietf.org>, denis.pinkas@bull.net > Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt > > Dino, > > I agree to a certain point, but it is actually relevant in a security > considerations section to mention that a threat is out of scope. > > I would also prefer the first option, but could live with both. > > /Stefan > > On 09-09-29 1:10 PM, "Dino Esposito"<alfredo.esposito@infocert.it> wrote: > >> > Nick >> > I prefer the first option, so reduced >> > ESSCertID provide means based on the SHA-1 hash algorithm for >> > identifying the certificate used to verify the signature on a time >> > stamp. The use of ESSCerIDv2 aims to enable implementers to comply >> > with policies that require phasing out all uses of the SHA-1 >> > algorithm. >> > >> > If something is out of scope, why should you address it? >> > In fact, the reason to upgrade the RFC is just to enable people to >> > comply with some external policies, where the threat are supposed to be >> > dealt >> > >> > Dino Esposito >> > >> > Pope, Nick wrote: >>> >> >>> >> Stefan, >>> >> >>> >> >>> >> >>> >> I prefer the alternative as this makes it clearer to me what is the >>> >> threat. >>> >> >>> >> >>> >> >>> >> Nick >>> >> >>> >> >>> >> >>> >> -----Original Message----- >>> >> *From:* Stefan Santesson [mailto:stefan@aaa-sec.com] >>> >> *Sent:* 29 September 2009 10:28 >>> >> *To:* Pope, Nick; denis.pinkas@bull.net; pkix >>> >> *Subject:* Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt >>> >> >>> >> >>> >> >>> >> I'm sorry to say that I don't think we are doing progress. >>> >> Rather the text seems to be getting more and more confusing to an >>> >> outside reader. >>> >> >>> >> I think the following would be much more helpful to a reader. >>> >> >>> >> ESSCertID provide means based on the SHA-1 hash algorithm for >>> >> identifying the certificate used to verify the signature on a time >>> >> stamp. The use of ESSCerIDv2 aims to enable implementers to comply >>> >> with policies that require phasing out all uses of the SHA-1 >>> >> algorithm. Upgrading the hash function through ESSCertIDv2 address >>> >> some theoretical scenarios involving a trusted malicious CA. Threats >>> >> caused by a trusted malicious CA is however out of scope of this >>> >> specification. >>> >> >>> >> Alternatively this (more elaborate): >>> >> >>> >> ESSCertID provide means based on the SHA-1 hash algorithm for >>> >> identifying the certificate used to verify the signature on a time >>> >> stamp. The use of ESSCerIDv2 aims to enable implementers to comply >>> >> with policies that require phasing out all uses of the SHA-1 >>> >> algorithm. Upgrading the hash function through ESSCertIDv2 address a >>> >> theoretical scenario involving a trusted malicious CA issuing a false >>> >> but trusted TSA certificate where the hash of the false certificate >>> >> is identical to the hash of the original TSA certificate. Threats >>> >> caused by a trusted malicious CA is however out of scope of this >>> >> specification. >>> >> >>> >> >>> >> >>> >> Note that the trusted malicious CA have another signing key (unless it >>> >> has compromised the good CA), thus will produce a totally different >>> >> signature on the false TSA certificate. >>> >> We are thus talking about a CA succeeding in creating a SHA-1 >>> >> collision despite a totally different signature value in the end of >>> >> the certificate. And all this effort just to convince me that the TSA >>> >> certificate was issued under the wrong policy..... >>> >> >>> >> Seems like a really serious issue... >>> >> >>> >> /Stefan >>> >> >>> >> >>> >> On 09-09-29 10:20 AM, "Pope, Nick"<Nick.Pope@thales-esecurity.com> wrote: >>> >> >>> >> Stefan, Denis, >>> >> >>> >> I would prefer the following, as >>> >> a) I don't think bringing certificate policy helps clarify things here >>> >> b) The ESSCertV2 covers the collision threat. >>> >> >>> >> >>> >> The introduction of ESSCertID addressed the theoretical threat that >>> >> a relying party trusts a CA which might possibly malicious >>> >> generate another TSA certificate. The ESSCertIDV2 addressed the >>> >> additional theoretical threat that hash of the other TSA >>> >> certificate is identical to the hash of the original TSA >>> >> certificate. >>> >> >>> >> The use of ESSCerIDv2 aims to enable implementers to comply with >>> >> policies that require phasing out all uses of the SHA-1 algorithm. >>> >> In case SHA-1 might in the future exhibit hash collisions, the >>> >> introduction of ESSCertIDv2 allows the use of stronger hash >>> >> functions making the generation of such other certificates close >>> >> to impossible. >>> >> >>> >> >>> >> >>> >> >>> >> -----Original Message----- >>> >> *From:* Stefan Santesson [mailto:stefan@aaa-sec.com] >>> >> *Sent:* 29 September 2009 09:06 >>> >> *To:* denis.pinkas@bull.net; pkix; Pope, Nick >>> >> *Subject:* Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt >>> >> >>> >> Denis, >>> >> >>> >> I have no problem with the disposition change. >>> >> >>> >> The problem is that you insist on painting this in words making it >>> >> look like as a serious security issue. >>> >> The rest of us seems to agree that it isn't a realistic threat. >>> >> >>> >> To me, the picture you paint sounds very much like reinforcing the >>> >> door of a vault that has lost it's roof. >>> >> It does help if the thief tries to enter through the door, but does >>> >> not prevent anyone from climbing over the wall. >>> >> >>> >> Likewise, for the unlikely event that you will trust a malicious CA, >>> >> ESSCertIDv2 will probably not save you either. >>> >> That CA can simply fool you in so many other ways where ESSCertIDv2 >>> >> will not help. >>> >> >>> >> >>> >> I think we have to choices. Either we define trusted but malicious CA >>> >> as a threat that is either: >>> >> >>> >> 1) in scope; or >>> >> 2) out of scope, >>> >> >>> >> of threats that need to be addressed. >>> >> >>> >> If the trusted malicious CA is in scope, then we need to address all >>> >> things that a trusted malicious CA can do and come up with >>> >> recommendations for each one. >>> >> If the trusted malicious CA is out of scope, then we should say so and >>> >> not pretend that we fixed the bad CA scenario by mending one of the >>> >> holes in the broken barrel. >>> >> >>> >> I hope we can all agree that it would be infeasible to define the >>> >> trusted malicious CA scenario as an "in scope" threat. >>> >> >>> >> /Stefan >>> >> >>> >> >>> >> On 09-09-25 4:57 PM, "Denis Pinkas"<denis.pinkas@bull.net> wrote: >>> >> Stefan and Nick, >>> >> >>> >> I have problems with the second and third paragraphs from section 6. >>> >> >>> >> The text starts with : >>> >> >>> >> The introduction of ESSCertIDv2 addresses the theoretical threat . >>> >> >>> >> The threat already existed with ESSCertID which means that the >>> >> sentence is incorrect. >>> >> >>> >> I propose the following: >>> >> >>> >> The introduction of ESSCertID addressed the theoretical threat that >>> >> a relying party trusts a CA which might possibly malicious >>> >> generate another TSA certificate where the hash of the other TSA >>> >> certificate is identical to the hash of the original TSA >>> >> certificate. Since the TSA certificate indicates the >>> >> Certification Policy under which the TSA key pair has been >>> >> handled, it is important that the TSA can reliably indicate under >>> >> which Certification Policy the certificate has been obtained. >>> >> >>> >> The use of ESSCerIDv2 aims to enable implementers to comply with >>> >> policies that require phasing out all uses of the SHA-1 algorithm. >>> >> In case SHA-1 might in the future exhibit hash collisions, the >>> >> introduction of ESSCertIDv2 allows the use of stronger hash >>> >> functions making the generation of such other certificates close >>> >> to impossible. >>> >> >>> >> >>> >> Denis >>> >> >>> >> ---------- >>> >> >>> >> *De :* pkix-bounces <mailto :pkix-bounces@ietf.org> >>> >> >>> >> *À :* i-d-announce <mailto :i-d-announce@ietf.org> >>> >> >>> >> *Date :* 2009-09-19, 10:45:01 >>> >> >>> >> *Sujet :* [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> *_Pièce(s) Jointe(s) au message original : >>> >> _* >>> >> (1). draft-ietf-pkix-rfc3161-update-06.txt >>> >> >>> >> >>> >> >>> >> Title : ESSCertIDv2 update for RFC 3161 >>> >> Author(s) : S. Santesson, N. Pope >>> >> Filename : draft-ietf-pkix-rfc3161-update-06.txt >>> >> Pages : 8 >>> >> Date : 2009-09-19 >>> >> >>> >> This document updates RFC 3161 [RFC3161]. It allows the use of >>> >> ESSCertIDv2 defined in RFC 5035 [ESSV2] to specify the hash of a >>> >> signer certificate when the hash is calculated with a function other >>> >> than SHA-1 [SHA1]. >>> >> >>> >> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161-update-06.txt >>> <mailto:-----pkix-bounces@ietf.org> >>> >> >>> >> 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. >>> >> >>> >> >>> >> _____________________ next part ______________________ >>> >> >>> >> _______________________________________________ >>> >> pkix mailing list >>> >> pkix@ietf.org <mailto: 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 >>> >> >>> >> *_/Consider the environment before printing this mail./_* >>> >> >>> >> */"Thales e-Security Limited is incorporated in England and Waleswith> >>> >> company registration number 2518805. Its registered office is located >>> >> at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. >>> >> Weybridge, Surrey KT15 2NX./* >>> >> >>> >> */The information contained in this e-mail is confidential. It may >>> >> also be privileged. It is only intended for the stated addressee(s) >>> >> and access to it by any other person is unauthorised. If you are not >>> >> an addressee or the intended addressee, you must not disclose, copy, >>> >> circulate or in any other way use or rely on the information contained >>> >> in this e-mail. Such unauthorised use may be unlawful. If you have >>> >> received this e-mail in error please delete it (and all copies) from >>> >> your system, please also inform us immediately on +44 (0)1844 201800 >>> >> or email postmaster@thales-esecurity.com. Commercial matters detailed >>> >> or referred to in this e-mail are subject to a written contract signed >>> >> for and on behalf of Thales e-Security Limited"./* >>> >> >>> >>------------------------------------------------------------------------ >>> >> >>> >> _______________________________________________ >>> >> 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 > Consider the environment before printing this mail. > > "Thales e-Security Limited is incorporated in England and Wales with company > registration number 2518805. Its registered office is located at 2 Dashwood > Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 > 2NX. > > The information contained in this e-mail is confidential. It may also be > privileged. It is only intended for the stated addressee(s) and access to it > by any other person is unauthorised. If you are not an addressee or the > intended addressee, you must not disclose, copy, circulate or in any other way > use or rely on the information contained in this e-mail. Such unauthorised use > may be unlawful. If you have received this e-mail in error please delete it > (and all copies) from your system, please also inform us immediately on +44 > (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters > detailed or referred to in this e-mail are subject to a written contract > signed for and on behalf of Thales e-Security Limited". > _______________________________________________pkix mailing > listpkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix > <listpkix@ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> > <listpkix@ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> > Consider the environment before printing this mail. > > "Thales e-Security Limited is incorporated in England and Wales with company > registration number 2518805. Its registered office is located at 2 Dashwood > Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 > 2NX. > > The information contained in this e-mail is confidential. It may also be > privileged. It is only intended for the stated addressee(s) and access to it > by any other person is unauthorised. If you are not an addressee or the > intended addressee, you must not disclose, copy, circulate or in any other way > use or rely on the information contained in this e-mail. Such unauthorised use > may be unlawful. If you have received this e-mail in error please delete it > (and all copies) from your system, please also inform us immediately on +44 > (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters > detailed or referred to in this e-mail are subject to a written contract > signed for and on behalf of Thales e-Security Limited". > Consider the environment before printing this mail. > > "Thales e-Security Limited is incorporated in England and Wales with company > registration number 2518805. Its registered office is located at 2 Dashwood > Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 > 2NX. > > The information contained in this e-mail is confidential. It may also be > privileged. It is only intended for the stated addressee(s) and access to it > by any other person is unauthorised. If you are not an addressee or the > intended addressee, you must not disclose, copy, circulate or in any other way > use or rely on the information contained in this e-mail. Such unauthorised use > may be unlawful. If you have received this e-mail in error please delete it > (and all copies) from your system, please also inform us immediately on +44 > (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters > detailed or referred to in this e-mail are subject to a written contract > signed for and on behalf of Thales e-Security Limited". >
- [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-… Internet-Drafts
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Thomas Pornin
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Dino Esposito
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… denis.pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… denis.pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Dino Esposito
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Andrea Caccia
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Pope, Nick
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Sylvester
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Sylvester
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Sylvester
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Sylvester
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Sylvester
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Rybar
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Rybar
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Peter Lipp