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

[Stefan Santesson <[e-mail]>]

In absence of any objection I ask that the WGLC to be closed for this
document with the conclusion that all raised issues has been addressed in
draft 09.

On the closure of the WGLC I suggest that this document is done in PKIX and
ready for the IESG.

/Stefan


On 09-10-26 1:19 PM, "Stefan Santesson" <[e-mail]> wrote:

> 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
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix