Subject: Re: [pkix] End-entity self-signed certs

From: Sean Turner <[email-masked]>
Date: Mon, 14 Nov 2011 09:18:35 +0800

So maybe I'm being simple minded but this is pretty much what I was 
asking for.

spt

On 9/28/11 12:16 AM, Kemp, David P. wrote:
> Change 1 - on page 12 replace:
>    "X.509 v3 also includes an extension that identifies the subject of a
>     certificate as being either a CA or an end entity, reducing the
>     reliance on out-of-band information demanded in PEM.
>
> with:
>     X.509 v3 also includes two extensions that identify ...
>
>
> Change 2 - on page 12-13 replace:
>    "This specification covers two classes of certificates: CA
>     certificates and end entity certificates.  CA certificates may be
>     further divided into three classes: cross-certificates, self-issued
>     certificates, and self-signed certificates.  Cross-certificates are
>     CA certificates in which the issuer and subject are different
>     entities.  Cross-certificates describe a trust relationship between
>     the two CAs.  Self-issued certificates are CA certificates in which
>     the issuer and subject are the same entity.  Self-issued certificates
>     are generated to support changes in policy or operations.  Self-
>     signed certificates are self-issued certificates where the digital
>     signature may be verified by the public key bound into the
>     certificate.  Self-signed certificates are used to convey a public
>     key for use to begin certification paths.  End entity certificates
>     are issued to subjects that are not authorized to issue
> certificates."
>
> with:
>
>    "This specification covers two classes of certificates: CA
>     certificates and end entity certificates.  CA and EE certificates may
> be
>     further divided into three classes: CA-issued certificates,
> self-issued
>     certificates, and self-signed certificates.  Cross-certificates are
>     CA certificates in which the issuer and subject are different
>     entities.  Cross-certificates describe a trust relationship between
>     the two CAs.  Self-issued certificates are certificates in which
>     the issuer and subject are the same entity.  Self-issued certificates
>     are generated to support changes in policy or operations.  Self-
>     signed certificates are self-issued certificates where the digital
>     signature may be verified by the public key bound into the
>     certificate.  Self-signed CA certificates are used to convey a public
>     key for use to begin certification paths.  End entity certificates
>     are issued to subjects that are not authorized to issue certificates.
>     Self-signed end entity certificates are used to convey a public key
>     and other information directly to relying parties without using
>     a PKI."
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Tuesday, September 27, 2011 9:55 AM
> To: PKIX
> Subject: [pkix] End-entity self-signed certs (was: Re: AD Review
> ofdraft-ietf-pkix-rfc5280-clarifications-03.txt)
>
>> On Aug 22, 2011, at 5:52 AM, Sean Turner wrote:
>>
>>> I think the -03 version is just about ready to go.  That is I have no
> comments on the existing text though I expect getting it through the
> IESG will be interesting (Apps ADs love to discuss about anything to do
> with characters strings/sets).  But, I think this draft needs to also
> address the issue of self-signed EE certificates.  I know at least the
> DANE WG had a lengthy discussion about self-signed EE certificates, I
> see that Max's EST draft also includes them, and they're used in the
> wild.  I want to see text included that addresses them.
>>>
>
> This thread started there, but then sidetracked on more "improvements"
> on trust anchors that are express as certificates. Could we please have
> two threads?
>
> --Paul Hoffman
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 14 Nov 2011 01:55:54 +0000

Um, maybe I missed something but there's no such thing as an end-entity
self-signed certificate.  Since constraints can't be enforced every
self-signed cert is potentially a CA, and should be treated as such.

-- T

On 11/13/11 7:18 PM, "Sean Turner" <[email-masked]> wrote:

>>certificates.

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 14 Nov 2011 02:18:55 +0000

What about a application who wants to use a pki enabled protocol using a self-signed certificate because they will validate the certificate by other means  and will never issue a certificate to another entity. There are a lot of implementations who create such certificates and don't want to be branded as a CA. We do that in Microsoft Exchange and assert in the basic constraints = end entity in a self-signed certificate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Monday, November 14, 2011 9:56 AM
To: Sean Turner; Kemp, David P.
Cc: PKIX; Paul Hoffman
Subject: Re: [pkix] End-entity self-signed certs

Um, maybe I missed something but there's no such thing as an end-entity self-signed certificate.  Since constraints can't be enforced every self-signed cert is potentially a CA, and should be treated as such.

-- T

On 11/13/11 7:18 PM, "Sean Turner" <[email-masked]> wrote:

>>     certificates and end entity certificates.  CA and EE certificates 
>>may  be
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Paul Hoffman
>> IESG will be interesting (Apps ADs love to discuss about anything to 
>> do with characters strings/sets).  But, I think this draft needs to 
>> also address the issue of self-signed EE certificates.  I know at 
>> least the DANE WG had a lengthy discussion about self-signed EE 
>> certificates, I see that Max's EST draft also includes them, and 
>> they're used in the wild.  I want to see text included that addresses them.
>>>>
>>
>> on trust anchors that are express as certificates. Could we please 
>> have two threads?
>>
>> --Paul Hoffman
>>

---

From: Sean Turner <[email-masked]>
Date: Mon, 14 Nov 2011 10:36:01 +0800

Tim,

You're right there's no such thing as an EE self-signed cert according 
to RFC 5280.  The point is for RFC 5280 to be updated to say that there 
are such things as EE self-signed certs, which reflects reality (e.g., 
dane).

spt

On 11/14/11 9:55 AM, Miller, Timothy J. wrote:
> On 11/13/11 7:18 PM, "Sean Turner"<[email-masked]>  wrote:
>
>>> may

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Nov 2011 04:48:00 +0200

And yet even DANE has not decided that they really need it.

You can always generate a self-signed certificate, and have that sign an EE certificate. You could write a 5-line script to do it with OpenSSL. 4 if you follow the suggestion to use the same public key for CA and EE (this came up today in DANE)

Yoav

On Nov 14, 2011, at 10:36 AM, Sean Turner wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Nov 2011 12:56:50 +0800

> And yet even DANE has not decided that they really need it.

That is a premature statement, and "really" is unclear in this context. As we discovered in the WG this morning, it is still an open question.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Mon, 14 Nov 2011 07:27:27 -0500

On Mon, Nov 14, 2011 at 10:36:01AM +0800, Sean Turner wrote:
> You're right there's no such thing as an EE self-signed cert
> according to RFC 5280.  The point is for RFC 5280 to be updated to
> say that there are such things as EE self-signed certs, which
> reflects reality (e.g., dane).

To head off the other subthread, I think it would be fairer to say
"reflects reality (e.g., the 7 million HTTPS servers with self-signed
certificates [1])". I'm not sure how solid that 7 million number is, but
it's fair to say that it's probably a lot--I run into HTTPS sites that
use a self-signed certificate fairly regularly, and they're generated by
default when I install mod_ssl on my machines.

DANE using/not using this will be as a result of the users out there
already doing it or in spite of them IMHO.

[1]
https://www.ietf.org/mail-archive/web/keyassure/current/msg01810.html

-- 
Scott Schmit

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 14 Nov 2011 12:53:54 +0000

It's not just web sites. The protocol logs from our public email gateways show the majority of SMTP servers who advertise STARTTLS on the internet have self-signed certificates. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Schmit
Sent: Monday, November 14, 2011 8:27 PM
To: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

On Mon, Nov 14, 2011 at 10:36:01AM +0800, Sean Turner wrote:
> >Um, maybe I missed something but there's no such thing as an 
> >end-entity self-signed certificate.  Since constraints can't be 
> >enforced every self-signed cert is potentially a CA, and should be treated as such.
>
> to RFC 5280.  The point is for RFC 5280 to be updated to say that 
> there are such things as EE self-signed certs, which reflects reality 
> (e.g., dane).

To head off the other subthread, I think it would be fairer to say "reflects reality (e.g., the 7 million HTTPS servers with self-signed certificates [1])". I'm not sure how solid that 7 million number is, but it's fair to say that it's probably a lot--I run into HTTPS sites that use a self-signed certificate fairly regularly, and they're generated by default when I install mod_ssl on my machines.

DANE using/not using this will be as a result of the users out there already doing it or in spite of them IMHO.

[1]

--
Scott Schmit

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 14 Nov 2011 13:21:01 +0000

I should have been more clear:  RFC5280 path vaildation does not apply to
self-signed certificates.  So none of the constraints in such certificates
apply with compliant algorithms.

In short, the change is insufficient because the text proposal is not
matched by behavior of the path validation algorithm, and the two should
align.

It may be relatively common practice to apply certificate path validation
to certificate trees of depth 0, but that doesn't make it safe.

-- T

On 11/13/11 8:18 PM, "Trevor Freeman" <[email-masked]>
wrote:

>What about a application who wants to use a pki enabled protocol using a
>self-signed certificate because they will validate the certificate by
>other means  and will never issue a certificate to another entity. There
>are a lot of implementations who create such certificates and don't want
>to be branded as a CA. We do that in Microsoft Exchange and assert in the
>basic constraints = end entity in a self-signed certificate.
>
>Miller, Timothy J.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 14 Nov 2011 13:29:59 +0000

To elaborate:  If you want to transport public keys in X.509 structures
for convenience, by all means go ahead.  But if you're not going to follow
X.509 trust models, you shouldn't be using X.509 processing to validate
those keys; roll your own and be explicit about it.

Key continuity management is a perfectly valid concept (and more secure
though more cumbersome than X.509), but expecting to translate seamlessly
between that model and X.509 without any issues is a mistake.  The
differences in understanding, both obvious and subtle, create
opportunities for exploitation.

-- T

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Nov 2011 19:38:23 +0100 (MET)

Miller, Timothy J. wrote:
> 
> I should have been more clear:  RFC5280 path validation does not apply to

That is sort-of correct.

> to certificate trees of depth 0, but that doesn't make it safe.

Neither X.509[1] nor PKIX(rfc5280)[2] define a
"certificate path validation to certificate trees of depth 0"
so I'm somewhat confused what you mean.

[1] X.509-200811  10.5.1 Basic certificate check

   Self-signed certificates, if encountered in the path, are ignored.

[2] rfc5280, Section 6.1  Basic Path Validation, near end of page 73

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path. 

Anyhow, some existing _implementations_ (igoring X.509 and PKIX specs)
will path-validate self-signed certs to itself (i.e. receiving a self-signed
cert as end-entity cert and check it against a locally stored trust anchor
containing the same self-signed cert.  That operation will likely succeed
for self-signed certs that look like CA certs, i.e. either X.509v3 with
BasicContraint cA=TRUE or X.509v1.  I don't know well it works for
self-signed X.509v3 certs with BasicConstraint cA=FALSE or without
BasicConstraints.

The current situation is that X.509 explicitly says that the standard
does not cover self-signed end-entity certs:

  3.4.61 self-signed certificate: A special case of self-issued
         certificates where the private key used by the CA to sign
         the certificate corresponds to the public key that is
         certified within the certificate. A CA might use a self-signed
         certificate, for example, to advertise their public key or other
         information about their operations.

     NOTE  Use of self-issued certificates and self-signed certificates
           issued by other than CAs are outside the scope of this
           Recommendation | International Standard.

And rfc-5280, being a mere profile of X.509, therefore does not currently
describe (desired) semantics and processing of self-signed X.509 certs
either.

In spite of X.509 and rfc5280 being silent about them, self-signed
X.509 certs are in widespread use (millions of them in current use),
and implementations have been supporting their use for decades.

So the only part that is lacking is coverage and guidance by the
standards, following the current practice of the installed base
where possible.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Nov 2011 19:53:00 +0100 (MET)

Trevor Freeman wrote:
> 
> It's not just web sites. The protocol logs from our public email
> gateways show the majority of SMTP servers who advertise STARTTLS
> on the internet have self-signed certificates. 

SMPTS & STARTTLS are a completely different issue.  Their purpose
is _strictly_ limited to optimistic encryption.  Both, PKIX certificate
path validation of any kind as well as server endpoint identification
of the hostname would preclude the TLS handshake to complete
successfully in the installed base of TLS servers.  And it is far
too late to turn back the clock on the installed base.

Even such large companies such as Google use X.509 certs from
a private CA (which precludes PKIX certificate path validation)
and through the use of DNS MX-record indirection there is *NO*
secure match between target/recipient domain and the names contained
in the SMTP server's TLS server certificate.

Most TLS servers will fallback to SMTP (MTA-to-MTA) delivery,
in which case both checks (PKIX path validation and server
endpoint identification) would not provide any real security anyway.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 14 Nov 2011 19:00:37 +0000

>matched by behavior of the path validation algorithm, and the two should

The proposal text adds self-signed certificates to descriptive text but
doesn't include self-signed certificates into the important bits, like
adding them to the path validation algorithm.  This is a problem, and as
pointed out in private mail we actually have a way to do this in RFC 5937,
but that's only Informational.

Proceeding with any change that fails to change the algorithm would do
nothing to drive convergence of inconsistent implementations, and would
IMHO exacerbate the problem by making it seem as if the RFC covers the
case when it actually does not.

Without changes to both the descriptive text and the algorithm, I wouldn't
consider the proposal complete.

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 14 Nov 2011 15:29:16 -0500

Nothing precludes an Informational RFC (such as 5937) from being
included in a list of acquisition requirements, and nothing precludes
vendors from building products that comply with Informational RFCs.
There's no reason to believe that the standards-track status of the RFC
will affect its speed of adoption.

The 5280 proposed descriptive text changes it from being incompatible
with self-signed EE certs to being compatible with them.  Fixing that
obstacle to convergence is necessary regardless of whether/how
additional incentives are applied.

Dave

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 2:01 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Kemp, David P.;
[email-masked]; [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

On 11/14/11 12:38 PM, "Martin Rex" <[email-masked]> wrote:

>standards, following the current practice of the installed base where 
>possible.

I believe I said:

>matched by behavior of the path validation algorithm, and the two 
>should align.

The proposal text adds self-signed certificates to descriptive text but
doesn't include self-signed certificates into the important bits, like
adding them to the path validation algorithm.  This is a problem, and as
pointed out in private mail we actually have a way to do this in RFC
5937, but that's only Informational.

Without changes to both the descriptive text and the algorithm, I
wouldn't consider the proposal complete.

-- T

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Nov 2011 21:47:47 +0100 (MET)

> >matched by behavior of the path validation algorithm, and the two should

I'm sorry, I failed to read the prior messages:
https://www.ietf.org/mail-archive/web/pkix/current/msg29992.html
https://www.ietf.org/mail-archive/web/pkix/current/msg29772.html

> adding them to the path validation algorithm.  This is a problem,
> 

I agree.  The more important part is not officially acknowledging
that they do exist, but how they should (not) be processed.

In particular, a guidance what such certs should look like that they're
less likely to get confused with real CA certs when configured as trusted.

But that is likely also the more controversial part...

>
> and as pointed out in private mail we actually have a way to do this
> in RFC 5937, but that's only Informational.

RFC 5937 "Using Trust Anchor Constraints during Certification Path Processing"
is IMO entirely irrelevant to the issue of self-signed end-entity certs,
that exist, by definition, in a PKI-less space.  There are only two
attributes where "honoring" by default IMO makes sense (a) the validity
and (b) absence of BasicConstraints cA=TRUE.

rfc5937 & rfc5914 only makes sense for rootCA certs of PKIs, and even
there they're completely irrelevent for >90% of the installed base.

Btw. the name constraints processing in rfc5937 might interact badly
with (b) and (c) of rfc5280 section 6.1.3.

-Martin

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 15 Nov 2011 00:44:40 +0000

Wow - Martin you cannot seriously expect me to buy into such as sweeping generalization.

It is a matter of local policy what the sending server does wrt the receiving server certificate. It is common practice for organization to enforce TLS authentication with partner domains. Some verticals have adopted it as a requirement.  At Microsoft we have over 50 domains we enforce TLS authentication for SMTP delivery.  If the server does not have a local policy for the domain; it does not validate the certificate resulting in unauthenticated encrypted deliver which is a security oxymoron but it gives some people comfort. Probably the same set that think man did not land on the moon and Elvis is alive.

Trevor 

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 2:53 AM
To: Trevor Freeman
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

Trevor Freeman wrote:
> gateways show the majority of SMTP servers who advertise STARTTLS on 
> the internet have self-signed certificates.

SMPTS & STARTTLS are a completely different issue.  Their purpose is _strictly_ limited to optimistic encryption.  Both, PKIX certificate path validation of any kind as well as server endpoint identification of the hostname would preclude the TLS handshake to complete successfully in the installed base of TLS servers.  And it is far too late to turn back the clock on the installed base.

Even such large companies such as Google use X.509 certs from a private CA (which precludes PKIX certificate path validation) and through the use of DNS MX-record indirection there is *NO* secure match between target/recipient domain and the names contained in the SMTP server's TLS server certificate.

Most TLS servers will fallback to SMTP (MTA-to-MTA) delivery, in which case both checks (PKIX path validation and server endpoint identification) would not provide any real security anyway.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 15 Nov 2011 14:19:20 +1300

"Kemp, David P." <[email-masked]> writes:

>Nothing precludes an Informational RFC (such as 5937) from being included in
>a list of acquisition requirements, and nothing precludes vendors from
>building products that comply with Informational RFCs. There's no reason to
>believe that the standards-track status of the RFC will affect its speed of
>adoption.

Actually, something does preclude an RFC of any kind from being written.  I
tried this more than a decade ago:

http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt

and after battling intense opposition from PKIX ("but that's not how you're
supposed to do PKI!") I tried to get it published as an independent,
informational RFC.  At the time I was told that this would be seen as an
attempt to do an end-run around an IETF standing committee and it would be
referred back to PKIX, who would then again reject it, at which point I
realised it was a hopeless battle.

If it is indeed possible to publish such a document as an informational RFC
then I can get that draft re-submitted in no time, I just don't want to run
into the same problem again.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Nov 2011 02:35:58 +0100 (MET)

Trevor Freeman wrote:
> 
> It is a matter of local policy what the sending server does wrt the
> receiving server certificate. It is common practice for organization
> to enforce TLS authentication with partner domains. Some verticals
> have adopted it as a requirement.

In theory, it can be could be done on a one-by-one basis.
There were 193 Million DNS domains mid of last year.
This scales nowhere.

>
> At Microsoft we have over 50 domains we enforce TLS authentication
> for SMTP delivery.

That seems to cover roughly 0.000026% of the internet -- way to go.

You mean for "@exchange.microsoft.com"?

 ;; QUESTION SECTION:
 ;exchange.microsoft.com.	IN  MX
 
 ;; ANSWER SECTION:
 exchange.microsoft.com.  3600	IN  MX	10 mail1.exchange.microsoft.com.
 exchange.microsoft.com.  3600	IN  MX	10 mail7.exchange.microsoft.com.

Although the server certificates that are presented by those two servers
chain to an old 1024-bit md5WithRSA-signed "GTE CyberTrust Global Root" 
they are issued to "mail1.exchange.microsoft.com" and
"mail7.exchange.microsoft.com" respectively, instead
of "exchange.microsoft.com".

I didn't notice DNSSEC in .microsoft.com, so DNS spoofing should be
possible.  What would happen if someone successfully spoofed an
MX record for exchange.microsoft.com point to "mail1.evilguy.x-y-y"
onto one of your 50 partners that tries to deliver EMail to you,
pointing to a server with an official TLS server certificate
for "mail1.evilguy.x-y-y" ?  

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 03:36:51 +0200

> into the same problem again.

You won't know unless you try.

And while the powers that be can prevent your document from becoming an RFC (sometimes), you and everyone else can submit a draft whenever you want. AFAIK the most popular of the three certificate enrollment protocols is still http://tools.ietf.org/html/draft-nourse-scep-23 .

It may be that with the DANE requirements, it would be easier to get that autonomous certificate document published. But you never know.

Yoav

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Nov 2011 03:02:22 +0100 (MET)

Trevor Freeman wrote:
> to enforce TLS authentication with partner domains. Some verticals have
> adopted it as a requirement.  At Microsoft we have over 50 domains
> we enforce TLS authentication for SMTP delivery.

 ;; QUESTION SECTION:
 ;live.com.			IN	MX
 
 ;; ANSWER SECTION:
 live.com.		3600	IN	MX	5 mx4.hotmail.com.
 live.com.		3600	IN	MX	5 mx1.hotmail.com.
 live.com.		3600	IN	MX	5 mx2.hotmail.com.
 live.com.		3600	IN	MX	5 mx3.hotmail.com.

 ;; QUESTION SECTION:
 ;hotmail.com.			IN	MX
 
 ;; ANSWER SECTION:
 hotmail.com.		3600	IN	MX	5 mx1.hotmail.com.
 hotmail.com.		3600	IN	MX	5 mx2.hotmail.com.
 hotmail.com.		3600	IN	MX	5 mx3.hotmail.com.
 hotmail.com.		3600	IN	MX	5 mx4.hotmail.com.

openssl s_client told me that, in contrast to the MX-hosts for
exchange.microsoft.com, none of the above hotmail MX-hosts
supports STARTTLS.

So no amount of configuration will help you in ensuring that an Email
sent from @exchange.microsoft.com to @live.com or @hotmail.com
is not disclosed while it is delivered over the internet ... or rerouted
to someone else.

Is @hotmail.com and @live.com still owned by Microsoft?

Actions speak louder than words.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 15 Nov 2011 22:08:52 +1300

>You won't know unless you try.

Well, I'd have to spend some time editing the whole thing into XML, and if
it's going to run into the same roadblock as last time I kinda have better
things to do... let's see how bored I get on the flight to Australia on
Friday.

Peter.

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 15 Nov 2011 09:40:40 +0000

Martin,

I have no idea what point you are trying to make here .

If you want to know how SMTP server authenticate the DNS name they are trying to reach via TLS - I suggest you read the product documentation rather than speculating. As I said it is a matter of local policy. 

Email delivery is not as reliable as you think. Typically on outbound gateways there are tens or hundreds of domains whose messages are stuck in retry. Email administrators don't have time to diagnose the reason for each domain. For the vast bulk of the domains, they simply want the message delivered at all costs, secure or not. Administrators only nominate a small fraction of the domains  to enforce authentication of the receiving domain. If the domain is on the require authentication list and authentication fails, the domain is put into retry. If the domain is not on the require authentication list, we don't check the certificate and if TLS negotiation fails or is not available, the email server sends in the clear. What that should tell you is that even if DNS SEC were widely available, if the domain was not on the require authentication list, we would not check the DNSSEC entry just like we would not check the DNS name in the certificate for the same reason, if authentication fails we will still try and deliver to the domain because that is what the administrators wants.

Trevor

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 9:36 AM
To: Trevor Freeman
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

>
> At Microsoft we have over 50 domains we enforce TLS authentication for 
> SMTP delivery.

 ;; QUESTION SECTION:
 
 ;; ANSWER SECTION:

Although the server certificates that are presented by those two servers chain to an old 1024-bit md5WithRSA-signed "GTE CyberTrust Global Root" 
they are issued to "mail1.exchange.microsoft.com" and "mail7.exchange.microsoft.com" respectively, instead of "exchange.microsoft.com".

I didn't notice DNSSEC in .microsoft.com, so DNS spoofing should be possible.  What would happen if someone successfully spoofed an MX record for exchange.microsoft.com point to "mail1.evilguy.x-y-y"
onto one of your 50 partners that tries to deliver EMail to you, pointing to a server with an official TLS server certificate for "mail1.evilguy.x-y-y" ?  

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 15 Nov 2011 13:40:11 +0000

>vendors from building products that comply with Informational RFCs.

Nothing formal, but obscurity is a tough nut to crack.  :)

>additional incentives are applied.

Fixing the textual issue is necessary but not sufficient, and leaves the
reader with the impression that *all* the methods described by the RFC
similarly include self-signed certificate processing.  This is patently
false because the path validation algorithm terminates without applying
constraints in self-signed certificates.  This may result in a trust
decision made assuming that constraints are applied when the
implementation does not actually do so, and we already have *multiple*
examples of how that works out (how many basicConstraints bugs have we had
so far?).

-- T

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 15 Nov 2011 09:02:09 -0500

> realised it was a hopeless battle.

I also tried the independent RFC publication route for a variation of 
the self-signed end-entity certificate, i.e. "auto-issued" with the 
draft "Auto Issued X.509 Certificate Mechanism (AIXCM)", 
http://tools.ietf.org/html/draft-moreau-pkix-aixcm-00
With similar reactions, I came to the same conclusion.

(Nonetheless in the short period where the idea was discussed, it was 
appreciated by the drafters of an application-oriented protocol which 
now has this draft as an informative reference.)

Regards,

- Thierry Moreau

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 15 Nov 2011 14:59:56 +0100

http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt

more wood on the fire :-)

Anders

---

From: Tom Gindin <[email-masked]>
Date: Tue, 15 Nov 2011 09:20:39 -0500

Key Usage, Subject Alt Name, and possibly EKU, make sense to me as 
well.  If nothing else, having KeyUsage with CASign off is a pretty good 
indicator that it's not a CA certificate, and the absence of Basic 
Constraints only matters if there's some other extension to make it a v3 
certificate.
        So my proposal would look like the following, in those cases where 
a self-signed certificate has been accepted by direct trust:
1       Issuer and Subject must match by the definition of a self-signed 
certificate
2       Version, Validity, Subject, and Subject Public Key Info have their 
usual meanings
3       Signature is verified against Subject Public Key Info
4       Serial number and the unique ID's don't have much meaning
5       The Basic Constraints, Key Usage, Subject Alternative Name, and 
Extended Key Usage extensions should be treated as having the same meaning 
which they have for typical EE certificates
6       PKIX-defined extensions other than those in #5 should not be 
processed
7       Nobody except the certificate subject vouches for the contents of 
most of these fields.  In particular, the attributes within Subject and 
the values of Subject Alternative Name are not verified by any trusted 
entity, nor are the values of Extended Key Usage.

Tom Gindin

From:   Martin Rex <[email-masked]>
To:     [email-masked] (Miller Timothy J.), 
Cc:     [email-masked], [email-masked]
Date:   11/14/2011 03:53 PM
Subject:        Re: [pkix] End-entity self-signed certs
Sent by:        [email-masked]

> >matched by behavior of the path validation algorithm, and the two 
should

> Without changes to both the descriptive text and the algorithm, I 
wouldn't

> in RFC 5937, but that's only Informational.

RFC 5937 "Using Trust Anchor Constraints during Certification Path 
Processing"

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Nov 2011 15:59:02 +0100 (MET)

> Constraints only matters if there's some other extension to make it a v3 

As it turns out, reality does not fit your plans:

  http://www.ietf.org/mail-archive/web/pkix/current/msg29091.html

Several of the self-signed RootCA certificates in the TLS X.509 PKI have
inconsistency problems (are not valid X.509v3 CA certs per PKIX/rfc5280):

  http://www.entrust.net/knowledge-base/technote.cfm?tn=7875

If you're configuring a self-signed certificate as trusted, then
you're always trusting _only_ the key, not any of the self-asserted
attributes in the certificate.  Those attributes are only a handle
to make it easier to deal with self-signed certs rather than
looking only at hexdumps of public keys alone.

> entity, nor are the values of Extended Key Usage.

I fail to see the purpose of (5).
Even the subject name in self-signed certs are untrusted.

To change that, the RP would have to perform an even stronger verification
of the claimed name than that done by RAs of commercial CAs before issuing
an EV cert.

-Martin

---

From: [email-masked]
Date: Tue, 15 Nov 2011 16:12:12 +0100

I support Tom's proposal in general.
 
Martin, the point is NOT to draft a specification which would be backwards 
compatible with all existing implementations.
The point is to write a draft which will define rules on how using 
self-signed EE certificates.
If you trust a self-signed EE certificate, then you trust all its content, 
otherwise you don't trust it.

Denis

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Nov 2011 16:22:14 +0100 (MET)

> otherwise you don't trust it.

There really is no point in processing any constraints for
as self-signed end-entity cert.  Such a cert ought to never appear
as signer of any other cert (otherwise it is by definition not an
end-entity, but a CA cert).  For a self-signed cert, the attributes
and any constraints that may be present are completely static.

So if any processing of the self-consistency of such data should
be done at all, then prior to accepting of that certificate as
trusted.  Doing it over and over again when the certificate is
use is a complete waste of resources.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 15 Nov 2011 15:53:01 +0000

>4       Serial number and the unique ID's don't have much meaning

Yes they do.  E.g., Microsoft Smart Card Logon in Windows Server 2008 or
later permits mapping certificates to accounts using Issuer and Serial
Number.  Since a self-signer can forge any issuer DN, this is a potential
problem.

>Processed

I presume this means an augmentation to path validation is forthcoming.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 15 Nov 2011 15:56:33 +0000

On 11/15/11 9:12 AM, "[email-masked]" <[email-masked]> wrote:

>Martin, the point is NOT to draft a
>specification which would be backwards compatible with all existing
>implementations.
>The point is to write a draft which
>will define rules on how using self-signed EE certificates.
>If you trust a self-signed EE certificate,
>then you trust all its content, otherwise you don't trust it.

The only trustable content in a self-signed certificate is the public key,
and only when that key is verified by the signature.

*Nothing* else in that cert has any meaning.  The signer can lie about
everything *except* his possession of the private key.

-- T

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 15 Nov 2011 15:02:55 -0500

> everything *except* his possession of the private key.

Let us see the semantic of "the signer possession of the private key".

(A) Only the alleged signer is in possession of the private key.

(A') A set of entities, including the signer, has the private key. (A 
key escrow agent, an attacker, an outsourcer, ... may be in the set)

Since I can trivially prepare a self-signed certificate for any CA 
entity with a locally generated key pair, the possession can further be 
characterized by:

(B) Only an entity other than the alleged signer is in possession of the 
private key.

(B') A set of entities, not including the alleged signer, ...

And for sake of completeness, since I can prepare such a certificate and 
then destroy the private key:

(C) No entity is in possession of the private key.

And also:

(D) The private key is publicly known.

Nothing in the self-signed certificate ensures you that either (A) or a 
suitable instance of (A') applies. That's a leap-of-faith decision.

Then, the same leap-of-faith applied to the certificate public key can 
be applied to other elements of the self-signed certificate.

PKI discussions are deemed to last forever.

Regards,

- Thierry Moreau

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 15 Nov 2011 15:52:34 -0500

Nits.   A private key could be known to one entity [A], few entities
[A'], or all entities [D], but that is true of all keys, symmetric and
asymmetric.  The indictment applies to all cryptography, and yet
Kerberos, PKI, and Wi-Fi still manage to see practical use because
self-interest encourages subjects not to share their keys with
attackers.

There is no "alleged signer"; the signature can be generated only by an
entity that possesses the private key, and every other field in the
certificate can have any value, with zero assurance.  So [B] and [B'] do
not exist independently of [A] and [A'].

Private keys (again, symmetric and asymmetric) are routinely destroyed
as a matter of good cryptographic hygiene.  So [C] is a feature, not a
bug - it allows unique identifiers to be created in a manner that
precludes (to the limit of cryptographic strength) impersonation or
forgery.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thierry Moreau
Sent: Tuesday, November 15, 2011 3:03 PM
To: Miller, Timothy J.
Cc: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

Miller, Timothy J. wrote:
>> If you trust a self-signed EE certificate, then you trust all its 
>> content, otherwise you don't trust it.
> 
> The only trustable content in a self-signed certificate is the public 
> key, and only when that key is verified by the signature.
> 

And also:

Regards,

- Thierry Moreau

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 16 Nov 2011 00:05:13 +0000

Of course other attributes of the certificate have meaning. 

Just because I am creating a self-signed certificate does not mean I want that key to be used for anything. It's the principle of least privilege. Only enable the set of uses you need. You are trusting the key for use in some protocol, what is wrong with trusting the certificate extensions as well. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, November 15, 2011 11:57 PM
To: [email-masked]; [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

>content, otherwise you don't trust it.

The only trustable content in a self-signed certificate is the public key, and only when that key is verified by the signature.

*Nothing* else in that cert has any meaning.  The signer can lie about everything *except* his possession of the private key.

-- T

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 15 Nov 2011 21:10:47 -0500

Kemp, David P. wrote:
> There is no "alleged signer";

I thought that the very purpose of a PKI was to distribute trust about 
the alleged signer (the one indicated in an end-entity certificate 
backed/signed by a CA) when a) signatures along the certification path 
validates, b) there is an out-of-band basis of trust for the CA public 
key, and c) the CA is careful in carrying evidence of security breaches 
into CRLs and/or on-line OCSP services. Under these conditions, the 
relying party can be (somewhat) confident that the true signer is the 
alleged one.

You seem to state that there is no alleged signer (then presumably only 
trusted or legitimate ones) for any public key. Then I don't see a 
purpose in pursuing this discussion about reliable portions of a 
self-signed certificate (a special case in the big picture, yet an 
inescapable one).

>                               the signature can be generated only by an

Ah, I see. Bogus self-signed certificates do not exist because an active 
ietf/pkix participant says so. From now on, I should feel confident to 
accept any self-signed certificate that comes to my browser.

Regards,

- Thierry Moreau

---

From: Tom Gindin <[email-masked]>
Date: Tue, 15 Nov 2011 21:38:40 -0500

Martin:

        As we all recognize, you can't trust much in a self-signed 
certificate.  Everything in it except version, signature and public key 
info is just a claim.  However, if you're going to manually add a 
self-signed certificate to a particular user's entry in your personal 
address book so you can encrypt email to it (something a user might 
legitimately do with such a certificate), SAN.rfc822Address is a 
meaningful field for the email client to use.  Similarly, SAN.DNSName and 
the CN attribute of the subject are reasonable places to put the claimed 
name of a test TLS server where the client's user is individually familiar 
with the administrator - I don't want to encourage anyone to trust public 
servers which do that.
        An individual trust decision for a self-signed certificate 
typically means that the person accepting that certificate believes that 
its values for the naming attributes that his client cares about (host 
name for TLS servers, email address for mail users) are correct.  Maybe 
that should mean that such a self-signed certificate should trigger an 
extra warning if it contains more than one such name.  The only other use 
case I can think of that I'd want to encourage is the one where a user who 
has already authenticated to an HTTPS server via password uploads a 
self-signed client certificate into his own registration record for future 
connections.  It's no weaker than a password, and harder to steal.  In 
that case, the name fields are irrelevant and the actual trust decision is 
similar to SSH.

Tom Gindin

From:   Martin Rex <[email-masked]>
To:     [email-masked], 
Cc:     [email-masked]
Date:   11/15/2011 10:28 AM
Subject:        Re: [pkix] End-entity self-signed certs
Sent by:        [email-masked]

> If you trust a self-signed EE certificate, then you trust all its 
content, 

-Martin

---

From: [email-masked]
Date: Wed, 16 Nov 2011 09:05:44 +0100

Tim,

I do not think so.

Please take a look at some products like Adobe Acrobat X Pro and Adobe 
Reader.
They allow to generate self-signed certificates which contain in 
particular a DN, a public key and a key usage.
All values are either either accepted alltogether or rejected.

They allow to verify signatures using direct trust rather than a path 
validation scheme. 

It is certainly not usable when there are numerous certificates, but fully 
adequate on a small scale.

Please, don't confuse lies and trust.

Denis

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Nov 2011 14:21:17 +0000

>Of course other attributes of the certificate have meaning.

Not really.  Since they're self-asserted, they can be re-asserted at any
time.  E.g., today my self-signed instrument permits only signing;
tomorrow I'll reissue that instrument (using the same key) to permit
encryption.  

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Nov 2011 14:28:27 +0000

>relying party can be (somewhat) confident that the true signer is the

The context of this discussion is self-signed, not CA-signed.  These are
entirely different, so don't confuse the two.

>self-signed certificate (a special case in the big picture, yet an

I think you're trying to distinguish between the identity of the entity
*holding* a private key from the identity to which the private key is
bound.  You can't do that without specifying hardware, so I recommend you
don't go there.  

*From the perspective of network interactions* the current private key
holder *is* the identity bound to the that key.

>ietf/pkix participant says so.

No, bogus self-signed certificates do not exist because you can't
distinguish between them and the putative "legitimate" self-signed
certificates.  A difference that makes no difference is, in fact, no
difference.

>					From now on, I should feel confident to

Don't be dense.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Nov 2011 14:32:01 +0000

My point (assuming I have one :) is basically under these assumptions, you
don't actually need the certificates.  If you're going out-of-band to
establish trust (IOW, associate a key to an identity), then stuff those
*independently verified attributes* in the damn key database (or Contacts
list, or authorized_keys file, or whatever) and throw the cert out--it's
not required and it's just going to confuse people.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Nov 2011 14:40:42 +0000

I'm starting to think y'all are missing the point.  If you're directly
trusting end-entity keys, you're *not* using X.509.  This is a perfectly
valid approach to authentication (no-one is arguing that SSH is a
failure), but it's up to you how to verify identities and attributes under
such a scheme.  

Relying on X.509 mechanisms to bind keys to attributes *without also using
X.509 methods of trust* is the exact wrong thing to do.

-- T

On 11/16/11 2:05 AM, "[email-masked]" <[email-masked]> wrote:

>Tim,
>
>I do not think so.
>
>Please take a look at some products
>like Adobe Acrobat X Pro and Adobe Reader.
>They allow to generate self-signed certificates
>which contain in particular a DN, a public key and a key usage.
>They allow to verify signatures using
>direct trust rather than a path validation scheme.
>
>It is certainly not usable when there
>are numerous certificates, but fully adequate on a small scale.
>

---

From: Tom Gindin <[email-masked]>
Date: Wed, 16 Nov 2011 10:21:56 -0500

No, Tim.  The application or protocol needs a certificate (e.g. 
RFC 5246 sections 7.4.2 and 7.4.6 or RFC 3852 section 5.1).  The code 
implementing those standards expects a certificate rather than a 
collection of attributes, and the users want to give the code something it 
will understand and process.

Tom Gindin

From:   "Miller, Timothy J." <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, "[email-masked]" <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   11/16/2011 09:34 AM
Subject:        Re: [pkix] End-entity self-signed certs

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 16 Nov 2011 10:38:51 -0500

-----Original Message-----
From: Thierry Moreau [mailto:[email-masked]] 

> You seem to state that there is no alleged signer (then presumably
> only trusted or legitimate ones) for any public key. Then I don't
> see a purpose in pursuing this discussion about reliable portions
> of a self-signed certificate (a special case in the big picture,
> yet an inescapable one).

Put your thinking cap on, this isn't difficult.  Do you agree that if I
possess a keypair, I can use it to sign anything at all, including using
the name of any person or organization in the subject and issuer fields?
If I create a self-signed cert with Subject = Issuer =
[email-masked], do you have any reason to believe anything
contained in the TBS portion of that cert?

>From Wikipedia: "An allegation (also called adduction) is a claim of a
fact by a party in a pleading, which the party claims to be able to
prove."

Because a self-signed cert can be created by anyone and can contain
anything, it cannot claim to prove anything.  In particular, my cert
cannot claim to prove that it was signed by you any more than my writing
your name on a piece of paper proves that you signed the paper.  Because
there is no credible proof, there is no allegation, and no alleged
signer.
(I'm having visions of a Monty Python skit in which Eric Idle stands in
a courtroom in front of Judge John Cleese, signs a document on the spot,
shows it to the judge, points to a person in the room, and says "Here's
your proof - 'is name's right there in black an' white.")

>>                               the signature can be generated only by 
>> an entity that possesses the private key, and every other field in
the 
>> certificate can have any value, with zero assurance.  So [B] and [B']

>> do not exist independently of [A] and [A'].
>
> Ah, I see. Bogus self-signed certificates do not exist because
> an active ietf/pkix participant says so. From now on, I should
> feel confident to accept any self-signed certificate that comes to my
browser.

That's a breathtaking leap of illogic.  All self-signed certificates are
bogus (zero-assurance) until some out-of-band mechanism is used to
designate them as trustable.  Unless you're a masochist, how to you get
from "they're all bogus" to "I should accept them all"?

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 16 Nov 2011 10:45:08 -0500

Not only do I agree with Dave Kemp, but I want to further add that for precisely the reasons Dave cited, using extensions like basic constraints and key usage to determine if self-signed certificate is a CA or not is not a good idea since creator of the signed certificate can add these extensions.

This, however does not mean that the relying parties do not use these extensions to decide if a trust anchor is a CA or not.  However, doing so, requires the relying parties to make an explicit decision about the self-signed payload uaing some out of band means as Dave cited.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Wednesday, November 16, 2011 10:39 AM
To: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

-----Original Message-----

the 

browser.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Nov 2011 16:37:59 +0000

>will understand and process.

So rewrite the code.  :)

I'm only being half-facetious.  If the protocol is defined to require
X.509 formats *and* requires  X.509 processing (as both TLS and CMS
currently do), then by implication that protocol relies on the X.509 trust
model because *only* under the X.509 trust model does X.509 processing of
X.509 attributes actually tell you anything you can rely on.

If you want to do something different, then you need to *write code* to
support "something different."  Attempting to slap a few new words into a
spec isn't enough, and in fact will be very very dangerous to others.

There's nothing particularly wrong with using X.509 formats for
convenience of key transport, but if your "something different" is a
non-X.509 trust model, then you should *explicitly* dispense with X.509
processing and everything it can tell you about the attributes bound into
certificates.  You're on your own from there.

You mix and match trust semantics at your peril.  We have plenty of
vulnerability history on this topic to draw on, so I don't see why this is
even remotely controversial.

-- T

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 17 Nov 2011 02:35:10 +0000

Yes the extensions in the self-signed certificate are self-asserted data, but so what. If you decide to trust the certificate, you can either accept the assertions or not. You get to choose. You are going to be trusting other assertions from the key. 

If the self-signer wants to define some restriction over what they intend to use the key for - what wrong with using existing mechanisms to communicate those restrictions. 

If you have code that understands all those restrictions from pkix, you want to reuse it rather than invent something new.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Wednesday, November 16, 2011 10:39 AM
To: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

-----Original Message-----

> only trusted or legitimate ones) for any public key. Then I don't see 
> a purpose in pursuing this discussion about reliable portions of a 

Put your thinking cap on, this isn't difficult.  Do you agree that if I possess a keypair, I can use it to sign anything at all, including using the name of any person or organization in the subject and issuer fields?
If I create a self-signed cert with Subject = Issuer = [email-masked], do you have any reason to believe anything contained in the TBS portion of that cert?

>From Wikipedia: "An allegation (also called adduction) is a claim of a fact by a party in a pleading, which the party claims to be able to prove."

Because a self-signed cert can be created by anyone and can contain anything, it cannot claim to prove anything.  In particular, my cert cannot claim to prove that it was signed by you any more than my writing your name on a piece of paper proves that you signed the paper.  Because there is no credible proof, there is no allegation, and no alleged signer.
(I'm having visions of a Monty Python skit in which Eric Idle stands in a courtroom in front of Judge John Cleese, signs a document on the spot, shows it to the judge, points to a person in the room, and says "Here's your proof - 'is name's right there in black an' white.")

the 

> Ah, I see. Bogus self-signed certificates do not exist because an 
> active ietf/pkix participant says so. From now on, I should feel 
> confident to accept any self-signed certificate that comes to my
browser.

That's a breathtaking leap of illogic.  All self-signed certificates are bogus (zero-assurance) until some out-of-band mechanism is used to designate them as trustable.  Unless you're a masochist, how to you get from "they're all bogus" to "I should accept them all"?

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 17 Nov 2011 08:51:19 -0500

Trevor,

Seems to me that my second paragraph said what you are saying.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Wednesday, November 16, 2011 10:39 AM
To: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

-----Original Message-----

the 

browser.

---

From: Tom Gindin <[email-masked]>
Date: Thu, 17 Nov 2011 09:05:48 -0500

Tim:

        I don't buy this.  It seems little more dangerous to directly 
trust an EE self-signed certificate than to directly trust an EE 
certificate from a root you don't currently trust, and it is less 
dangerous to do either than to trust that root because that's the only way 
to trust the leaf.  What is truly dangerous is for users to make ad-hoc 
trust decisions based on very little (including overriding unexpected 
browser messages that a server certificate is untrusted), or for software 
vendors to configure RP's so that they trust every commercial CA in the 
world to have unlimited naming scope until such a CA is proven thoroughly 
untrustworthy.
        My own understanding of the X.509 trust model is that a 
certificate is to be accepted only if it or one of its ancestors in a 
valid chain is directly trusted.  Direct trust of an EE certificate, which 
typically involves trusting the binding of the key to the name and the key 
usage, does not break that model.
        In any case, X.509 version 4 section 8.1.5 says, with respect to 
self-issued certificates, that "Self-issued certificates of type b) may 
only appear as end certificates in a path, and shall be processed as end 
certificates" and defines type b as having "key usages other than 
certificate and CRL signing (such as time-stamping)".  It's true that that 
section describes the entity creating these certificates as a CA, but the 
usage is not restricted to those characteristic of CA's and there is no 
restriction that these certificates cannot be self-signed.

Tom Gindin

P.S. -  The opinions above are mine, and not necessarily those of my 
employer

From:   "Miller, Timothy J." <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, 
Cc:     "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date:   11/16/2011 11:38 AM
Subject:        Re: [pkix] End-entity self-signed certs

So rewrite the code.  :)

-- T

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 18 Nov 2011 04:04:51 +0000

Yes we are in violent agreement :)

Sent from my Windows Phone
________________________________
From: Santosh Chokhani
Sent: 11/17/2011 9:51 PM
To: Trevor Freeman; Kemp, David P.; [email-masked]
Subject: RE: [pkix] End-entity self-signed certs

Trevor,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Wednesday, November 16, 2011 10:39 AM
To: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

-----Original Message-----

the

browser.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 20 Nov 2011 13:14:39 +1300

Thierry Moreau <[email-masked]> writes:

>I also tried the independent RFC publication route for a variation of the
>self-signed end-entity certificate, i.e. "auto-issued" with the draft "Auto
>Issued X.509 Certificate Mechanism (AIXCM)",
>http://tools.ietf.org/html/draft-moreau-pkix-aixcm-00 With similar reactions,
>I came to the same conclusion.

Something like this was eventually snuck past PKIX disguised as a (handwave)
grid-computing mechanism (I'm talking about Proxy Certificates here), although
I'm not sure if that was a genuine attempt to fix a grid computing problem or
a genuine attempt to do an end-run around the PKIX roadblock.

Similarly, PKIX has a straightforward positive-assertion, whitelist-based
certificate status protocol as a standards-track RFC that was snuck through as
something completely different, although unfortunately the level of disguise
is sufficient that most people reading the spec don't recognise what you can
actually do with it.

Anyway, I'll reformat my old draft in XML and see what happens...

Peter.