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

[Stefan Santesson <[e-mail]>]

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]> wrote:

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