Pope, Nick | 1 Oct 11:45 2009

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

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 <at> aaa-sec.com]
Sent: 29 September 2009 20:58
To: Pope, Nick; 'denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
Sent: 29 September 2009 17:40
To: Pope, Nick; 'denis.pinkas <at> 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 <at> thales-esecurity.com> wrote:
Either is OK for me too.
 

-----Original Message-----
From: denis.pinkas <at> bull.net [mailto:denis.pinkas <at> bull.net]
Sent: 29 September 2009 17:19
To: Pope, Nick
Cc: 'denis.pinkas <at> bull.net <denis.pinkas <at> 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. T
his 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 <at> ietf.org wrote: -----

To: "'denis.pinkas <at> bull.net' <denis.pinkas <at> bull.net> " <denis.pinkas <at> bull.net>, pkix <pkix <at> ietf.org>
From: "Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
Sent by: pkix-bounces <at> 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 <at> ietf.org[mailto:pkix-bounces <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <at> ietf.org] On Behalf Of denis.pinkas <at> 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 <at> ietf.orgwrote: -----

To: Dino Esposito <alfredo.esposito <at> infocert.it>,"Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
From: Stefan Santesson <stefan <at> aaa-sec.com>
Sent by: pkix-bounces <at> ietf.org
Date: 09/29/2009 02:39PM
cc: pkix <pkix <at> ietf.org>, denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 10:28
>> *To:* Pope, Nick; denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 09:06
>> *To:* denis.pinkas <at> 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 <at> 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 <at> ietf.org>
>>
>> *À :* i-d-announce <mailto :i-d-announce <at> 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 <at> 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 <at> ietf.org <mailto: pkix <at> ietf.org>
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>------------------------------------------------------------------------
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> 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 <at> 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 <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
pkix mailing list
pkix <at> 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 <at> 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 <at> ietf.orghttps://www.ietf.org/mailman/listinfo/pkix <listpkix <at> 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 <at> 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 <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Stefan Santesson | 1 Oct 13:29 2009

Re: 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" <Nick.Pope <at> 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 <at> aaa-sec.com]
Sent: 29 September 2009 20:58
To: Pope, Nick; 'denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
Sent: 29 September 2009 17:40
To: Pope, Nick; 'denis.pinkas <at> bull.net <denis.pinkas <at> 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 <at> thales-esecurity.com> wrote:
Either is OK for me too.
 

-----Original Message-----
From: denis.pinkas <at> bull.net [mailto:denis.pinkas <at> bull.net]
Sent: 29 September 2009 17:19
To: Pope, Nick
Cc: 'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net> <denis.pinkas <at> 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. T
his 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 <at> ietf.org wrote: -----

To: "'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net> ' <denis.pinkas <at> bull.net> " <denis.pinkas <at> bull.net>, pkix <pkix <at> ietf.org>
From: "Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
Sent by: pkix-bounces <at> 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 <at> ietf.org[mailto:pkix-bounces <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <at> ietf.org] On Behalf Of denis.pinkas <at> 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 <at> ietf.orgwrote: -----

To: Dino Esposito <alfredo.esposito <at> infocert.it>,"Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
From: Stefan Santesson <stefan <at> aaa-sec.com>
Sent by: pkix-bounces <at> ietf.org
Date: 09/29/2009 02:39PM
cc: pkix <pkix <at> ietf.org>, denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 10:28
>> *To:* Pope, Nick; denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 09:06
>> *To:* denis.pinkas <at> 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 <at> 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 <at> ietf.org>
>>
>> *À :* i-d-announce <mailto :i-d-announce <at> 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 <at> 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 <at> ietf.org <mailto: pkix <at> ietf.org>
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>------------------------------------------------------------------------
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> 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 <at> 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 <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
pkix mailing list
pkix <at> 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 <at> 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 <at> ietf.orghttps://www.ietf.org/mailman/listinfo/pkix <listpkix <at> ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> <listpkix <at> 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 <at> 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 <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Internet-Drafts | 1 Oct 13:45 2009
Picon

I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : ESSCertIDv2 update for RFC 3161
	Author(s)       : S. Santesson, N. Pope
	Filename        : draft-ietf-pkix-rfc3161-update-07.txt
	Pages           : 8
	Date            : 2009-10-01

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-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : ESSCertIDv2 update for RFC 3161
	Author(s)       : S. Santesson, N. Pope
	Filename        : draft-ietf-pkix-rfc3161-update-07.txt
	Pages           : 8
	Date            : 2009-10-01

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-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Pope, Nick | 1 Oct 14:00 2009

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

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:stefan <at> aaa-sec.com]
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" <Nick.Pope <at> thales-esecurity.com> wrote:

Fine by me
 
Nick
 

-----Original Message-----
From: Stefan Santesson [mailto:stefan <at> aaa-sec.com]
Sent: 01 October 2009 12:30
To: Pope, Nick; 'denis.pinkas <at> bull.net'
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" <Nick.Pope <at> 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 <at> aaa-sec.com]
Sent: 29 September 2009 20:58
To: Pope, Nick; 'denis.pinkas <at> bull.net <denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
Sent: 29 September 2009 17:40
To: Pope, Nick; 'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net>  <denis.pinkas <at> 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 <at> thales-esecurity.com> wrote:
Either is OK for me too.
 

-----Original Message-----
From: denis.pinkas <at> bull.net [mailto:denis.pinkas <at> bull.net]
Sent: 29 September 2009 17:19
To: Pope, Nick
Cc: 'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net> <denis.pinkas <at> bull.net> <denis.pinkas <at> 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. T
his 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 <at> ietf.org wrote: -----

To: "'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net> <denis.pinkas <at> bull.net> ' <denis.pinkas <at> bull.net> " <denis.pinkas <at> bull.net>, pkix <pkix <at> ietf.org>
From: "Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
Sent by: pkix-bounces <at> 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 <at> ietf.org[mailto:pkix-bounces <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <at> ietf.org] On Behalf Of denis.pinkas <at> 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 <at> ietf.orgwrote: -----

To: Dino Esposito <alfredo.esposito <at> infocert.it>,"Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
From: Stefan Santesson <stefan <at> aaa-sec.com>
Sent by: pkix-bounces <at> ietf.org
Date: 09/29/2009 02:39PM
cc: pkix <pkix <at> ietf.org>, denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 10:28
>> *To:* Pope, Nick; denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 09:06
>> *To:* denis.pinkas <at> 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 <at> 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 <at> ietf.org>
>>
>> *À :* i-d-announce <mailto :i-d-announce <at> 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 <at> 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 <at> ietf.org <mailto: pkix <at> ietf.org>
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>------------------------------------------------------------------------
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> 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 <at> 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 <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
pkix mailing list
pkix <at> 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 <at> 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 <at> ietf.orghttps://www.ietf.org/mailman/listinfo/pkix <listpkix <at> ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> <listpkix <at> ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> <listpkix <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Stefan Santesson | 2 Oct 09:08 2009

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

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" <Nick.Pope <at> thales-esecurity.com> 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:stefan <at> aaa-sec.com]
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" <Nick.Pope <at> thales-esecurity.com> wrote:
Fine by me
 
Nick
 

-----Original Message-----
From: Stefan Santesson [mailto:stefan <at> aaa-sec.com]
Sent: 01 October 2009 12:30
To: Pope, Nick; 'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net> '
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" <Nick.Pope <at> 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 <at> aaa-sec.com]
Sent: 29 September 2009 20:58
To: Pope, Nick; 'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net>  <denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
Sent: 29 September 2009 17:40
To: Pope, Nick; 'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net>  <denis.pinkas <at> bull.net>  <denis.pinkas <at> 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 <at> thales-esecurity.com> wrote:
Either is OK for me too.
 

-----Original Message-----
From: denis.pinkas <at> bull.net [mailto:denis.pinkas <at> bull.net]
Sent: 29 September 2009 17:19
To: Pope, Nick
Cc: 'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net> <denis.pinkas <at> bull.net> <denis.pinkas <at> bull.net> <denis.pinkas <at> 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. T
his 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 <at> ietf.org wrote: -----

To: "'denis.pinkas <at> bull.net <denis.pinkas <at> bull.net> <denis.pinkas <at> bull.net> <denis.pinkas <at> bull.net> ' <denis.pinkas <at> bull.net> " <denis.pinkas <at> bull.net>, pkix <pkix <at> ietf.org>
From: "Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
Sent by: pkix-bounces <at> 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 <at> ietf.org[mailto:pkix-bounces <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <pkix-bounces <at> ietf.org%5bmailto:pkix-bounces> <at> ietf.org] On Behalf Of denis.pinkas <at> 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 <at> ietf.orgwrote: -----

To: Dino Esposito <alfredo.esposito <at> infocert.it>,"Pope, Nick" <Nick.Pope <at> thales-esecurity.com>
From: Stefan Santesson <stefan <at> aaa-sec.com>
Sent by: pkix-bounces <at> ietf.org
Date: 09/29/2009 02:39PM
cc: pkix <pkix <at> ietf.org>, denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 10:28
>> *To:* Pope, Nick; denis.pinkas <at> 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 <at> 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 <at> aaa-sec.com]
>> *Sent:* 29 September 2009 09:06
>> *To:* denis.pinkas <at> 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 <at> 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 <at> ietf.org>
>>
>> *À :* i-d-announce <mailto :i-d-announce <at> 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 <at> 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 <at> ietf.org <mailto: pkix <at> ietf.org>
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>------------------------------------------------------------------------
>>
>> _______________________________________________
>> pkix mailing list
>> pkix <at> 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 <at> 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 <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
pkix mailing list
pkix <at> 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 <at> 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 <at> ietf.orghttps://www.ietf.org/mailman/listinfo/pkix <listpkix <at> ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> <listpkix <at> ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> <listpkix <at> ietf.orghttps:/www.ietf.org/mailman/listinfo/pkix> <listpkix <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Pope, Nick | 5 Oct 10:30 2009

Feedback on visible signatures in PDF

All,

Within ETSI STF 364 on PDF Advanced Electronic Signatures we are reviewing
requirements relating to visible representation of signatures within PDF and
would very much welcome feedback on the questions raised in the attached
document to assist in setting the direction of our work.    Response is
requested by 12 November so that these can be discussed at our next face to
face meeting.  You can send responses to me by email at:

 nick.pope <at> thales-esecurity.com

Regards

Nick Pope
Co-Lead STF 364

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 <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Petr Pisar | 5 Oct 17:20 2009
Picon

How to handle sequence of distributionPoint's

Hello,

I read RFC 3280 (Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile) carefully and I'm not sure how
should application check certificate validity if there is more than one
DistributionPoint. Should application fetch CRLs from all DistributionPoint's
and check certificate against them, or one successfull DistributionPoint is
enough?

I understand situation with one DistributionPoint having more GeneralName's.
RFC states explicitly that such GenerlName's are equivalent. However RFC does
not say anything about multiple DistributionPoint's each having only one
GeneralName.

I think that multiple DistributionPoint's are designed for collection of
incomplete CRLs, thus application should check all of them. However there is
no clarification in given RFC.

And to get sharper edge, what's desired behaviour when all DistributionPoint's
have no reasons flag? I think there is no way how to signal to appliaction the
CRLs are partitioned on some internal organisation reasons (e.g. one CRL for
CA certificates only, another CRL for end user not-CA certficates), thus
appliaction should check all of them.

What's correct procedure?

-- Petr Pisar

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Timothy J. Miller | 5 Oct 17:49 2009
Picon

Re: How to handle sequence of distributionPoint's

Petr Pisar wrote:

> I think that multiple DistributionPoint's are designed for collection of
> incomplete CRLs, thus application should check all of them. However there is
> no clarification in given RFC.

I know of PKIs that used multiple DistributionPoints as alternates, not 
distributing CRL portions.

-- Tim

Attachment (smime.p7s): application/x-pkcs7-signature, 4740 bytes
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Internet-Drafts | 5 Oct 18:00 2009
Picon

I-D Action:draft-ietf-pkix-tamp-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Trust Anchor Management Protocol (TAMP)
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-tamp-03.txt
	Pages           : 98
	Date            : 2009-10-05

This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store.  The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication.  The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-pkix-tamp-03.txt): message/external-body, 70 bytes
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Trust Anchor Management Protocol (TAMP)
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-tamp-03.txt
	Pages           : 98
	Date            : 2009-10-05

This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store.  The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication.  The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Santosh Chokhani | 5 Oct 18:21 2009

Re: How to handle sequence of distributionPoint's

Petr,

You only need to check one (see exception below) as long as the CRL
retrieved is the appropriate one, i.e., either the IDP extension is
absent or if present, the DP in IDP matches the DP in the CRL DP or DP
in IDP is absent.

The exception is when CRL is partitioned by reason code.  We generally
should not do that.  But, if you do, you need to get all the partitions
whose reasons codes are of interest to the relying party (those
generally are all the reason codes).

> -----Original Message-----
> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On 
> Behalf Of Petr Pisar
> Sent: Monday, October 05, 2009 11:21 AM
> To: pkix <at> ietf.org
> Subject: [pkix] How to handle sequence of distributionPoint's
> 
> Hello,
> 
> I read RFC 3280 (Internet X.509 Public Key Infrastructure 
> Certificate and Certificate Revocation List (CRL) Profile) 
> carefully and I'm not sure how should application check 
> certificate validity if there is more than one 
> DistributionPoint. Should application fetch CRLs from all 
> DistributionPoint's and check certificate against them, or 
> one successfull DistributionPoint is enough?
> 
> I understand situation with one DistributionPoint having more 
> GeneralName's.
> RFC states explicitly that such GenerlName's are equivalent. 
> However RFC does not say anything about multiple 
> DistributionPoint's each having only one GeneralName.
> 
> I think that multiple DistributionPoint's are designed for 
> collection of incomplete CRLs, thus application should check 
> all of them. However there is no clarification in given RFC.
> 
> And to get sharper edge, what's desired behaviour when all 
> DistributionPoint's have no reasons flag? I think there is no 
> way how to signal to appliaction the CRLs are partitioned on 
> some internal organisation reasons (e.g. one CRL for CA 
> certificates only, another CRL for end user not-CA 
> certficates), thus appliaction should check all of them.
> 
> What's correct procedure?
> 
> -- Petr Pisar
> 
> 
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix


Gmane