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

[Stefan Santesson <[e-mail]>]

Denis,

I have spoken with Nick and we can both live with this change.

The new security considerations section would then read:

   This draft incorporates the security considerations of RFC 5035
   [ESSV2] with further explanations in this section.

   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.

   The update provided by this draft is motivated by reasons of
   interoperability and migration to other hash algorithms rather than
   mitigating new security issues.

I will include this in the 09 draft and hope the rest of this list can agree
to this text.

/Stefan


On 09-10-23 2:16 PM, "Denis Pinkas" <[e-mail]> wrote:

> Stefan,
>  
> I could agree with the "minimalist" text you propose by changing a single word
> in it.
>  
> Change "known" into "new".
>  
> Then, the last paragraph would become:
> 
>    The update provided by this draft is motivated by reasons of
>    interoperability and migration to other hash algorithms rather than
>    mitigating new security issues.
> 
> Can you live with it ?
>  
> Denis
> 
> ----- Message reçu -----
>>  
>> De  : pkix-bounces <mailto :[e-mail]>
>>  
>> À  : Julien  Stern,pkix <mailto :[e-mail],[e-mail]>
>>  
>> Date  : 2009-10-23, 11:58:02
>>  
>> Sujet  : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-08.txt
>>  
>> 
>>  
>>  
>>  
>>  
>> Julien,
>> 
>> The body of this draft has been done and agreed upon for  quite some time
>> now. The document is hold back only because we have not  manage to agree on
>> one security considerations section.
>> 
>> Removing the  security considerations section is not an option. All RFC
>> documents must  have one.
>> 
>> We are NOT trying to say that ESSCertID serves no security  purpose.
>> The original security considerations section was trying to say  that the
>> motivation for allow algorithm agility (through ESSCertIDv2) is to  allow
>> migration to other hash algorithm rather than reasons of  security.
>> 
>> This approach did however receive serious pushback from  Denis. We have since
>> then tried to find a text that is both acceptable and  accurate. So far
>> unsuccessfully.
>> 
>> In the effort to describe the  particular threat that a stronger hash would
>> protect against, it turns out  that this threat requires a malicious trusted
>> CA. This is however something  that breaks the fundamental security
>> assumptions of PKI. If you trust a bad  CA, you are smoked.. No matter how
>> good your protocol is. As BCP 72  requires us to tell (in the security
>> considerations) what threats are in,  or out, of scope of the specified
>> protocol. Thus, describing this threat  also requires us to tell the reader
>> that threats caused by a trusted  malicious CA in general are out of scope
>> for a protocol to  solve.
>> 
>> Failing to do so may cause a reader to believe that he needs to  migrate to
>> ESSCertIDv2 to avoid serious security threats. This is not a  desired outcome
>> and could cause both confusion and interoperability issues  trough premature
>> and unmotivated migrations to ESSCertIDv2.
>> 
>> You are  free to propose text here that meets the requirements of BCP 72
>> section  5.
>> 
>> I personally would be happy with a short note saying what we  originally
>> wanted to say.. That is:
>> 
>> 
>>    This draft  incorporates the security considerations of RFC  5035
>>    [ESSV2] with further explanations in this  section.
>> 
>>    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.
>> 
>>    The update  provided by this draft is motivated by reasons  of
>>    interoperability and migration to other hash  algorithms rather than
>>    mitigating known security  issues.
>> 
>> 
>> .... And delete the rest.
>> 
>> /Stefan
>> 
>> 
>> 
>> On  09-10-22 5:14 PM, "Julien Stern" <[e-mail] <mailto:
>> [e-mail]> >  wrote:
>> 
>>> > [e-mail] <mailto: [e-mail]>   wrote:
>>>> >> 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-08.txt
>>>> >> Pages : 8
>>>> >> Date :  2009-10-14
>>> > 
>>> > 
>>> > Dear all,
>>> > 
>>> > Sorry for  jumping in late in the discussion.
>>> > 
>>> > I disagree with the  current proposed addition to the security
>>> > considerations  section.
>>> > 
>>> > In the various email exchanges on this list as well  as on the ESTI ESI
>>> > list, it appears that what is currently under  debate is whether the
>>> > ESSCertID is useful from a security standpoint.  So people are trying to
>>> > argue about the feasability or the  infeasability, as well as the
>>> > practicality and the real-life impact of  various certificate
>>> > substitution attacks.
>>> > 
>>> > I do not  think that this is the point. The point of this update is to
>>> > allow the  usage of the ESSCertID v2 (defined in RFC 5035) instead of the
>>> >  ESSCertID v1.
>>> > 
>>> > I do not think that adding a security  consideration that is essentially
>>> > saying "oh, by the way, ESSCertID v2  is essentially useless
>>> > security-wise" when it is meant to be used in  S/MIME, PKIX (3161, 5126),
>>> > CAdES, XAdES, PAdES, ECOM, etc fits in such  an update. I'm not sure
>>> > either that such an update reflects the  largest view of the community...
>>> > 
>>> > People are free to believe  that ESSCertID (v1 or v2) serves no security
>>> > purpose. Others are free  to believe otherwise.
>>> > 
>>> > But if the authors truly believe that  the ONLY possible attack scenario
>>> > is the one roughly described in the  security consideration section, then
>>> > let them prove it. Otherwise,  remove the security consideration section.
>>> > (In my humble opinion, it  is not correct anyway).
>>> > 
>>> > Regards,
>>> > 
>>> > --
>>> >  Julien
>>> > _______________________________________________
>>> > pkix  mailing list
>>> > [e-mail] <mailto: [e-mail]>
>>> >  https://www.ietf.org/mailman/listinfo/pkix
>> 
>> 
>> _______________________________________________
>> pkix  mailing list
>> [e-mail] <mailto: [e-mail]>
>> https://www.ietf.org/mailman/listinfo/pkix
>> 
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix