Subject: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Mar 2012 17:05:45 -0400

David has published an updated version of this doc. This version includes
significant new text in several sections, relative to version 3
of the draft, but both docs are very brief. I am initiating a new 
WGLC, starting today, and running through Friday, Sunday, March 25, 
so that the WGLC can be completed before the PKIX WG meeting in Paris.

See the changes using the following link:

(http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-04).

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Mar 2012 00:38:22 +0100 (MET)

> (http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-04).

I can not parse this sentence, based on the grammar rules that I'm
familiar with (it is in rfc5280 and -clarifications):

    The protection afforded private keys is a critical security factor.

Admittedly, I'm not a native english speaker.

-Martin

---

From: Oscar Koeroo <[email-masked]>
Date: Thu, 15 Mar 2012 08:31:46 +0100

On 14/3/12 10:05 PM, Stephen Kent wrote:
> of the draft, but both docs are very brief. I am initiating a new WGLC,
> starting today, and running through Friday, Sunday, March 25, so that the
> WGLC can be completed before the PKIX WG meeting in Paris.
> 

May I request an addition to the Security Considerations which states
something about the implications of having multiple CAs signing certificates
for the same entity.

This could happen by accident or on purpose. In the latter case the form of
the attack is a lot more subtle then stealing a private key.

	Oscar

---

From: David O'Callaghan <[email-masked]>
Date: Thu, 15 Mar 2012 11:12:27 +0000

> Admittedly, I'm not a native english speaker.

Could I suggest:

	Protection of private keys is a critical security factor.

Or more verbosely:
	
	The level of protection that is applied to private keys is a critical
security factor.

Kind regards,

David O'Callaghan

-- 
Ánra Taighde - Scoil na hEolaíochta Ríomhaireachta ⁊ na Staitisticí,
 Coláiste na Tríonóide, Baile Átha Cliath, BÁC 2
Research Fellow - School of Computer Science & Statistics,
 Trinity College Dublin, Dublin 2                    T: +353 1 896 1720

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 15 Mar 2012 08:57:06 -0400

Without commenting on any proposed changes to this sentence, I'll just 
note that this text dates back to RFC 2459, with very few changes.

Dave
--------------------------------------------------------------------------------------------------

RFC 2459 (January 1999):

    The protection afforded private keys is a critical factor in
    maintaining security.  On a small scale, failure of users to protect
    their private keys will permit an attacker to masquerade as them, or
    decrypt their personal information. On a larger scale, compromise of
    a CA's private signing key may have a catastrophic effect.

RFC 3280 (April 2002):

    The protection afforded private keys is a critical security factor.
    On a small scale, failure of users to protect their private keys will
    permit an attacker to masquerade as them, or decrypt their personal
    information.  On a larger scale, compromise of a CA's private signing
    key may have a catastrophic effect.

RFC 5280 (May 2008):

    The protection afforded private keys is a critical security factor.
    On a small scale, failure of users to protect their private keys will
    permit an attacker to masquerade as them or decrypt their personal
    information.  On a larger scale, compromise of a CA's private signing
    key may have a catastrophic effect.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 15 Mar 2012 16:12:42 +0000

>the attack is a lot more subtle then stealing a private key.

Did I miss a major discussion on the list?  What attack?

-- T

---

From: Oscar Koeroo <[email-masked]>
Date: Thu, 15 Mar 2012 19:04:34 +0100

> Did I miss a major discussion on the list?  What attack?

Let me rephrase that to "impersonation" for lack of a more proper word. The
use case is quite simple: somebody could acquire/buy a certificate signed
for a domain that already has a host certificate from another CA. The
purpose could be legitimate, e.g. a migration to another CA. The purpose
could also be illegitimate.

I'm making this note that the Security Considerations section could mention
this risk too.

	Oscar

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 15 Mar 2012 18:39:15 +0000

>could also be illegitimate.

Since it's always been the case that any party can go to any CA and get a
cert in any name they can prove *to the CA's satisfaction* that they're
entitled to, I don't see how that warrants a security consideration.

That horse was never in the barn in the first place.  :)

-- T

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Mar 2012 19:59:06 -0700

The new text seems fine. However, the new text is not covered in the Abstract or Introduction. An easier way to do this would be to not try to introduce everything in the document. I propose:

Abstract

   This document updates RFC 5280, the Internet X.509 Public Key
   Infrastructure Certificate and Certificate Revocation List (CRL)
   Profile, clarifying some parts and making small but important
   changes in other parts.

1.  Introduction

   This document updates the Internet X.509 Public Key Infrastructure
   Certificate and Certificate Revocation List (CRL) Profile [RFC5280].
   Each section of this document changes a different part of RFC 5280.

Then, move the introductory text for certificate policy change ("The ASN.1 [X.680] syntax for the user notice certificate policy...") into section 3, and move the introductory test for IDNs ("Section 7.3 of RFC 5280 specifies rules for converting...") into section 5. The other sections don't need introductory text.

--Paul Hoffman