Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

[Stefan Santesson <[e-mail]>]

Thanks,

I received them now.
There are just cosmetic changes but the text for next version will be:

   ESSCertID provides a means based on the SHA-1 hash algorithm for
   identifying the certificate used to verify the signature on a time
   stamp. The use of ESSCertIDv2 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 addresses
   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.

/Stefan


On 09-10-01 2:00 PM, "Pope, Nick" <[e-mail]> wrote:

> Stefan,
>  
> Should have looked more closely at the English before saying yes.
>  
>    ESSCertID provides a 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 addresses 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.
>  
> See highlighted text.
>  
> Nick
>  
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: 01 October 2009 12:47
> To: Pope, Nick
> Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt
>  
> OK,
> 
> I have updated and submitted a new draft.
> http://www.ietf.org/id/draft-ietf-pkix-rfc3161-update-07.txt
> 
> Hopefully this resolves the issue:
> 
> /Stefan
> 
> On 09-10-01 1:34 PM, "Pope, Nick" <[e-mail]> wrote:
> Fine by me
>  
> Nick
>  
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: 01 October 2009 12:30
> To: Pope, Nick; '[e-mail] <[e-mail]> '
> Cc: pkix
> Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt
> 
> 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" <[e-mail]> 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:[e-mail]]
> Sent: 29 September 2009 20:58
> To: Pope, Nick; '[e-mail] <[e-mail]>
> <[e-mail]> '
> 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" <[e-mail]> 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:[e-mail]]
> Sent: 29 September 2009 17:40
> To: Pope, Nick; '[e-mail] <[e-mail]>
> <[e-mail]>  <[e-mail]> '
> 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" <[e-mail]> wrote:
> Either is OK for me too.
>  
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 29 September 2009 17:19
> To: Pope, Nick
> Cc: '[e-mail] <[e-mail]> <[e-mail]>
> <[e-mail]> <[e-mail]> '; 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
> 
> [e-mail] wrote: -----
> 
> To: "'[e-mail] <[e-mail]> <[e-mail]>
> <[e-mail]> ' <[e-mail]> " <[e-mail]>,
> pkix <[e-mail]>
> From: "Pope, Nick" <[e-mail]>
> Sent by: [e-mail]
> 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: [e-mail][mailto:pkix-bounces
> <[e-mail]%5bmailto:pkix-bounces>
> <[e-mail]%5bmailto:pkix-bounces>
> <[e-mail]%5bmailto:pkix-bounces>
> <[e-mail]%5bmailto:pkix-bounces> @ietf.org] On Behalf Of
> [e-mail]
> 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
> 
> 
> [e-mail]: -----
> 
> To: Dino Esposito <[e-mail]>,"Pope, Nick"
> <[e-mail]>
> From: Stefan Santesson <[e-mail]>
> Sent by: [e-mail]
> Date: 09/29/2009 02:39PM
> cc: pkix <[e-mail]>, [e-mail]
> 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"<[e-mail]> 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:[e-mail]]
>>> >> *Sent:* 29 September 2009 10:28
>>> >> *To:* Pope, Nick; [e-mail]; 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"<[e-mail]> 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:[e-mail]]
>>> >> *Sent:* 29 September 2009 09:06
>>> >> *To:* [e-mail]; 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"<[e-mail]> 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 :[e-mail]>
>>> >> 
>>> >> *À :* i-d-announce <mailto :[e-mail]>
>>> >> 
>>> >> *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:[e-mail]>
>>> >> 
>>> >> 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
>>> >> [e-mail] <mailto: [e-mail]>
>>> >> https://www.ietf.org/mailman/listinfo/pkix
>>> >> 
>>> >> 
>>> >> ------------------------------------------------------------------------
>>> >> 
>>> >> 
>>> >> _______________________________________________
>>> >> pkix mailing list
>>> >> [e-mail]
>>> >> https://www.ietf.org/mailman/listinfo/pkix
>>> >> 
>>> >>------------------------------------------------------------------------
>>> >> 
>>> >> _______________________________________________
>>> >> pkix mailing list
>>> >> [e-mail]
>>> >> 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 [phone]
>>> >> or email [e-mail]. 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
>>> >> [e-mail]
>>> >> https://www.ietf.org/mailman/listinfo/pkix
>>> >> 
>> > _______________________________________________
>> > pkix mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/pkix
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> 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 [e-mail]. 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
> [e-mail]://www.ietf.org/mailman/listinfo/pkix
> <[e-mail]:/www.ietf.org/mailman/listinfo/pkix>
> <[e-mail]:/www.ietf.org/mailman/listinfo/pkix>
> <[e-mail]:/www.ietf.org/mailman/listinfo/pkix>
> <[e-mail]:/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 [e-mail]. 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 [e-mail]. 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 [e-mail]. 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 [e-mail]. 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix