Subject: [pkix] reminder

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Aug 2012 13:06:43 -0400

Below is the text that was briefed in the PKIX meeting yesterday and 
that represents
the current, proposed text for addition to Section 3.2. Russ noted that 
we need to
add a reference to the 2008 version of X.509 from which we have cited 
text.  Peter will
reissue the doc with this change. I plan to forward that version to the 
IESG a week after
it is posted, unless we hear otherwise.

Steve
-----

Add the following paragraph to the end of RFC 5280, Section 3.2:

Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of 
self-issued certificates and self-signed certificates issued by other 
than CAs are outside the scope of this specification. Thus, for example, 
a web server or client might generate a self-signed certificate to 
identify itself. These certificates, and how a relying party uses them 
to authenticate asserted identities, are both outside the scope of RFC 5280.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 02 Aug 2012 19:46:35 +0200

On 08/02/2012 07:06 PM, Stephen Kent wrote:
> the current, proposed text for addition to Section 3.2. Russ noted 
> that we need to
> reissue the doc with this change. I plan to forward that version to 
> the IESG a week after

Could one change  'generate' to 'want to use' ?
TIA

> than CAs are outside the scope of this specification. Thus, for 
> example, a web server or client might generate a self-signed 
> certificate to identify itself. These certificates, and how a relying 
> party uses them to authenticate asserted identities, are both outside 
> the scope of RFC 5280.
>
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Aug 2012 16:03:30 -0400

> Could one change  'generate' to 'want to use' ?
No. As I noted before, 5280 discusses cert signing (aka generation) and 
cert processing
by an RP. The text above addresses these separately, and appropriately.

Steve

---

From: Scott Schmit <[email-masked]>
Date: Fri, 3 Aug 2012 21:16:34 -0400

On Thu, Aug 02, 2012 at 01:06:43PM -0400, Stephen Kent wrote:
> that represents the current, proposed text for addition to Section
> 3.2. Russ noted that we need to add a reference to the 2008 version of
> X.509 from which we have cited text.  Peter will reissue the doc with
> this change. I plan to forward that version to the IESG a week after
> Consistent with Section 3.4.61 of X.509 (11/2008) we note that use
> of self-issued certificates and self-signed certificates issued by
> other than CAs are outside the scope of this specification. Thus,
> for example, a web server or client might generate a self-signed
> certificate to identify itself. These certificates, and how a
> relying party uses them to authenticate asserted identities, are
> both outside the scope of RFC 5280.

As I read it, if you aren't a CA and generate a self-signed certificate,
then that certificate isn't a PKIX certificate.  Is that statement
right?

If so, it sort of screws up draft-ietf-dane-protocol:

From section 2.2.1:
#     3 -- Certificate usage 3 is used to specify a certificate, or the
#     public key of such a certificate, that MUST match the end entity
#     certificate given by the server in TLS.  This certificate usage is
#     sometimes referred to as "domain-issued certificate" because it
#     allows for a domain name administrator to issue certificates for a
#     domain without involving a third-party CA.  The target certificate
#     MUST match the TLSA record.  The difference between certificate
#     usage 1 and certificate usage 3 is that certificate usage 1
#     requires that the certificate pass PKIX validation, but PKIX
#     validation is not tested for certificate usage 3.
#
#  The certificate usages defined in this document explicitly only apply
#  to PKIX-formatted certificates in DER encoding [X.690].  If TLS
#  allows other formats later, or if extensions to this RRtype are made
#  that accept other formats for certificates, those certificates will
#  need their own certificate usage values.

(TLSA Certificate usage 3 is intended for self-signed "PKIX"
certificates.)

Maybe the problem is that we talk about PKIX-formatted certificates vs.
PKIX-validated certificates, but both are handled in RFC 5280.

Can we distinguish the two?

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Aug 2012 08:41:34 -0700

> then that certificate isn't a PKIX certificate.  Is that statement

Partially. Those certificates are outside the scope of PKIX. However...

> (TLSA Certificate usage 3 is intended for self-signed "PKIX"

No. It is intended for PKIX-formatted certificates, which is exactly what the DANE spec says.

> PKIX-validated certificates, but both are handled in RFC 5280.

Can you say why that's a problem?

> Can we distinguish the two?

Yes, easily.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Sat, 4 Aug 2012 21:02:39 -0400

> Can you say why that's a problem?

Because someone could easily use that paragraph to say, "there's no such
thing as a PKIX-formatted certificate that isn't PKIX-validatable." 

RFC 5280 == PKIX, so being out of scope of RFC 5280 makes it not
PKIX-anything.  After all, how the certificate is signed determines if
it's in scope of PKIX.

> > Can we distinguish the two?

I'd suggest we do that.  I think think that's why people were trying to
inject "use of" the certificates instead of "generation of" the certs--
to make that distinction.

I'd be happier if the last sentence read:

"Validation of these certificates, and how a relying party authenticates
the asserted identities, are both outside the scope of RFC 5280."

Then it makes sense for a certificate to be a PKIX[-formatted]
certificate, but not PKIX-validatable.

-- 
Scott Schmit

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Aug 2012 16:12:42 -0400

Scott,

I tend to think of cert validation as equivalent to authentication of 
asserted
identities, but I am in favor trying to make this as clear as possible. 
Your text drops
the phrase "These certificates" which in intended to address the format 
part of the
topic. So, how about:

*"These certificates, and how a relying party uses them to authenticate 
the asserted
identities (certificate validation), are both outside the scope of RFC 
5280."
*
Steve

---

From: Scott Schmit <[email-masked]>
Date: Mon, 6 Aug 2012 21:44:05 -0400

On Mon, Aug 06, 2012 at 04:12:42PM -0400, Stephen Kent wrote:
> asserted identities, but I am in favor trying to make this as clear as
> possible. Your text drops the phrase "These certificates" which in
> intended to address the format part of the topic. So, how about:

No, I'm *trying* to exclude the formatting.  Other RFCs refer to 5280 as
a way to format certificates.  I think it's legitimate to say that this
formatting as defined by 5280 is in scope of 5280.  (From what I read,
the X.509 spec is unusuable on its own -- it needs a profiling
specification like PKIX.) As I see it, the contention over self-signed
non-CA certificates isn't their formatting, it's their
validity/authentication.  I'm trying to make those two issues distinct.

-- 
Scott Schmit

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Aug 2012 10:31:25 -0400

Scott,
> validity/authentication.  I'm trying to make those two issues distinct.
Many folks, me included, believe that the formatting is not consistent 
with 5280,
which is why we are going to the trouble of making this change. The 
formatting
issue is that, in general, the issuer of a cert IS implicitly a CA, and 
thus a self-signed
cert needs to contain a basic constraints extension, with the CA flag 
set TRUE. The certs that
we are working to accommodate are not formatted consistent with this 
interpretation of 5280,
hence the changed text.

Since your motivation for the rewording is at odds with that, I'll 
retract my proposed change.

Steve