Subject: Re: Love's issue #4; was: Re: PKINIT open issues

From: Martin Rex <[email-masked]>
Date: Tue, 1 Jun 2004 15:29:51 +0200 (MET DST)

Doug Mitchell wrote:
> 
> Yes. From 3.2.1:
> 
>      The ContentInfo in the signedAuthPack is filled out as follows:
> 
>      ...snip...
> 
>      4.  The certificates field MUST contain at least a signature
>          verification certificate chain that the KDC can use to
>          verify the signature over the AuthPack.  Additionally, the
>          client MAY insert an encryption certificate chain, if
>          (for example) the client is not using ephemeral-ephemeral
>          Diffie-Hellman.

Since there was ambiguity about the "certificate chain" in SSL
(which has been documented in TLS), what does it mean here:

Should the certificate chain include the RootCA certificate?

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 01 Jun 2004 10:04:18 -0400

>Should the certificate chain include the RootCA certificate?
Usually including the RootCA certificate is optional.  It may be 
included but should not
be required to be included in order to reduce the message size.  In 
either case the RootCA
certificate should not be trusted (since it is self-signed) unless it 
previously existed in a
locally maintained database of trusted RootCA Certificates. 

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Jun 2004 17:22:30 +0200 (MET DST)

Jeffrey Altman wrote:
> included but should not be required to be included in order to
> reduce the message size.  In either case the RootCA certificate
> should not be trusted (since it is self-signed) unless it 
> previously existed in a locally maintained database of trusted
> RootCA Certificates. 

Well, that explanation is all what TLS did about the ambiguity of SSLv3.
I forgot to mention the actual problems that come with this.

If the certificate chain includes the RootCA certificate:
 - may it be completely ignored by the receipient
 - should it be completely verified by the recipient
   (e.g. self-signature, Key usage, Validity period and validity
         period chaining, policies, etc.)

The complexity of PKI / X.509 combined with options will result
in non-obvious interoperability problems in the long run (or require
a large matrix for interoperability testing).

For more than a year https://www.verisign.com (running with a Netscape
WebServer) was sending out an expired VeriSign RootCA certificate
(that had expired in 1999) in the forward certification path of the
SSL handshake.  MSIE and Netscape 4.7x Browsers (the only ones I checked
at the time) ignored that as long as they had the reissued VeriSign RootCA
certificate configured as a trust anchor.  If you deleted that RootCA
certificate from the trust anchors, then you would get a popup warning
you about the (a) unknown and (b) expired CA certificate.

There was a problem with our (OEM-) SSL Software an the GlobalSign RootCA
certificate for WebServers.  Our OEM-Software stores the own RootCA
certificate ASN.1-decoded, and for inclusion in the SSL handshake
(server role) the RootCA certificate was reassembled according to
the ASN.1 DER encoding rules.  Unfortunately the GlobalSign RootCA
is not valid ASN.1 DER, so the reassembled certificate failed
signature verification.  Again, MSIE and Netscape 4.7x ignored this
with the GlobalSign RootCA cert preconfigured as a trust anchor.
Mozilla/Netscape 6.x gave an error, however, making it impossible
to connect.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 01 Jun 2004 11:40:26 -0400

> - may it be completely ignored by the receipient
It may be completely ignored by the recipient.  The only benefit that 
including the RootCA
certificate does is allow the client application to display the 
certificate to the end user to
determine whether or not it should be trusted (assuming it passes all of 
the other validation
tests).
The RootCA certificate when included in the chain must match exactly the 
certificate stored
in the Trusted CA database.  If it does not, the RootCA certificate MUST 
NOT be trusted.

>         period chaining, policies, etc.)
Absolutely.  If the self-signed certificate is not valid it should be 
dropped on the floor
like a hot potato.  This is true for Intermediate CA certificates as 
well.  The only difference
between Intermediate CA certs is that they MUST be included in the chain.

> you about the (a) unknown and (b) expired CA certificate.
This does not surprise me.  If I remember correctly what is actually 
happening in this case was
that both the expired and re-issued Root CA certificates are stored in 
the MSIE and Netscape/Mozilla
Trust lists.  Therefore, the actual logic was validate that the expired 
RootCA was trusted and that
there exists a valid trusted RootCA with the same name.

This was not an error of the protocol but an error of configuration of 
the server.  In fact, I would
argue that the real fault here was that the Webserver did not validate 
the certificate itself and
prevent its use.
In the United States there are serious problems with the transmission of 
HIPPA protected data
because so many of the HTTP and FTP servers which are used to collect 
this data are misconfigured.
I have been entirely unsuccessful at getting them fixed because there 
are no laws requiring secure
transmission of data or even specifying what secure transmission means.  
Therefore, the companies
are free to do whatever they want.  First Health which handles the 
collection of Medicard and Medicare
data for thirteen states has a misconfigured FTP Server which is sending 
an expired Verisign Intermediate
CA certificate even though the certificate was re-issued almost six 
months ago.

> Mozilla/Netscape 6.x gave an error, however, making it impossible
I would say that Mozilla is doing the better thing.  Kermit would not 
allow this connection to be
automated either.

Jeffrey Altman

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 10 Jun 2004 11:35:03 -0600

Jeffrey Altman said the following at 06/01/2004 09:40 AM:-

> in the Trusted CA database.  If it does not, the RootCA certificate MUST 

FWIW, in PacketCable we explicitly address this issue and allow the 
serial number, validity period and signature to be different (to allow 
for the case of root certs expiring). All the other fields must match 
the trusted stored certificate. So I think that the statement above is a 
bit too strong.

   Doc

-- 

-----------------------------------------------------------
Office: +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 10 Jun 2004 14:06:12 -0400

D. R. Evans wrote:

>> The RootCA certificate when included in the chain must match exactly 
>> the certificate stored
>> in the Trusted CA database.  If it does not, the RootCA certificate 
>> MUST NOT be trusted.
>>
>
> the trusted stored certificate. So I think that the statement above is 
> a bit too strong.
>
>   Doc
>
This really strikes me as a bad idea.  The Root CA certificates sent in 
a certificate chain should not be trusted. 
Why are you not providing a trusted mechanism for updating the client's 
trusted certificate store?

- Jeffrey Altman

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 10 Jun 2004 12:49:45 -0600

Jeffrey Altman said the following at 06/10/2004 12:06 PM:-

> a certificate chain should not be trusted. Why are you not providing a 
> trusted mechanism for updating the client's trusted certificate store?
> 

The short answer is: we do. But more importantly, I don't understand 
your concern. Are you suggesting that there's a security flaw introduced 
by allowing this? I don't see it.

   Doc

--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 11 Jun 2004 01:57:12 -0400

D. R. Evans wrote:

>> This really strikes me as a bad idea.  The Root CA certificates sent 
>> in a certificate chain should not be trusted. Why are you not 
>> providing a trusted mechanism for updating the client's trusted 
>> certificate store?
>>
>
> your concern. Are you suggesting that there's a security flaw 
> introduced by allowing this? I don't see it.
>
>   Doc
>
According to RFC 3280 we do not care at all about the Root CA 
certificate.  What we care about is the "trust anchor" (Distinguished 
Name and Public Key) and a set of constraints (validity date range, 
restrictions on use, etc).  The fact that this information is 
represented, transfered and stored in the form of a self-signed 
certificate is unimportant.  The validation requires require the 
enforcement of the known and trusted "trust anchor" and constraints to 
the certificate path.  By accepting an alternate self-signed certificate 
containing an alternate set of constraints you violating the certificate 
path validation algorithm. 

I will argue that it is unacceptable to accept a new set of constraints 
for a trust anchor after the previous set of constraints has become invalid.
Second, I will argue that you must add the new self-signed certificate 
to the trusted certificate store only via a trusted session authenticated
with the previous certificate.  You will then have both certificates in 
the store.  You should continue to use the old certificate until the 
expiration date at which point the new certificate should be used. 

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Jun 2004 12:11:11 +0200 (MET DST)

> by allowing this? I don't see it.

Yes, that is (a minor) security flaw in ignoring the expiration
of the validity for a trust anchor.

Why should a CA use a short-lived RootCA cert in the first place,
if it is going permitted to change that validity to whatever it feels
like whenever it feels like during an authentication.

That may put clients at risk in the future when they still have
(forgotten, long expired) trusted RootCA certs in their list of
trust anchors and one of those keys gets compromised after its
schedules expiration--either broken because it was weak or stolen
(recovered from inappropriately disposed backup tapes or whatever).

I would consider it less of a problem if one permitted automatic
updating of a _not_yet_expired_ trust anchor with one carrying a
longer lifetime as long as the integrity protection on the
certificate container is valid, even if that update comes as
a side-effect of a normal authentication exchange (because this
would make short lived trust anchors less of a problem.
The roll-over problem has caused CAs to bump the validity by
full 10 years).

-Martin

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 11 Jun 2004 09:11:21 -0600

I think we're so far off on a tangent here that I really don't want to 
prolong this, since it really has nothing to do with PKINIT.

Unless, that is, you are intending to require that all these things that 
should really be left to local policy are going to be included in 
PKINIT. In which case, I will continue the discussion. Starting with 
stating that how the KDC determines validity is not a protocol issue, 
has no place in PKINIT, and should be determined by local policy :-)

   Doc

Martin Rex said the following at 06/11/2004 04:11 AM:-

--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 11 Jun 2004 11:31:21 -0400

D. R. Evans wrote:

> Unless, that is, you are intending to require that all these things 
> that should really be left to local policy are going to be included in 
I believe the following text should be added to the document:

    "Certificate Path Validation MUST be performed according to the
    requirements and algorithm specified by the Internet X.509 Public
    Key Infrastructure Certificate and Certificate Revocation List (CRL)
    Profile [RFC 3280]"

I really do not believe anything more should need to be said on this 
matter in the PKINIT document.  However, I do believe that Martin and I 
have exactly the same concerns regarding the mechanism you are using to 
validate the certificate path.  By ignoring the trust anchor constraints 
you are violating the rules laid out in RFC 3280.

Jeffrey Altman

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 11 Jun 2004 10:14:55 -0600

Jeffrey Altman said the following at 06/11/2004 09:31 AM:-

> you are violating the rules laid out in RFC 3280.

But why should a profile of PKINIT not be allowed to do this if the 
authors of the profile want to do so?

What does the validation mechanism have to do with the protocol? I 
honestly don't understand why anything needs to be said about the 
details of validation, and, especially, why there has to be a MUST attached.

   Doc

--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 11 Jun 2004 12:40:11 -0400

D. R. Evans wrote:

>> matter in the PKINIT document.  However, I do believe that Martin and 
>> I have exactly the same concerns regarding the mechanism you are 
>> using to validate the certificate path.  By ignoring the trust anchor 
>> constraints you are violating the rules laid out in RFC 3280.
>>
>
I will be quite adamant about the MUST because of my recent experience 
with HIPPA regulations.
HIPPA is supposed to guarantee the privacy of personal medical and 
related financial information.
It does not because the laws don't say that the information must be 
protected, but because the
technical standards documents say "should" instead of "must" when it 
comes to how X.509 certificate
paths are to be validated.  "should" is not a requirement.  therefore, 
when it comes to a legal setting
it may be ignored.  Now you are of course allowed to ignore anything you 
don't want to implement
even if it is a MUST; but when someone takes advantage of the loophole 
you have created to prevent
themselves from having legal liability for damages I am going to take 
exception to it.

You have said yourself that there are ways you can ensure that the root 
certificates (trust anchors
and their constraints) are up to date.  Therefore the need for the 
loophole does not exist.

This is of course my opinion an it is a strong one.  I am not the 
working group chair and I do not
determine consensus for this group.  I am not going to protest this to 
the IESG and block the
document moving forward if this is not a MUST but I will remind those 
working on this document
that one of the Area Directors was the PKIX working group chair and will 
be sure to review anything
associated with PKIX very closely.

Just my two cents payable via PayPal.

- Jeff

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 11 Jun 2004 10:49:30 -0600

Jeffrey Altman said the following at 06/11/2004 10:40 AM:-

> themselves from having legal liability for damages I am going to take 

But if the local policy says "certification MUST be in accord with RFC 
3280", then it becomes a legal requirement for that system. We don't 
have to mandate it in the PKINIT document.

Any system is going to require adherence to a bunch of RFCs (as well as 
other documents); all I am saying is that the system designers should 
say "...MUST conform to [the PKINIT RFC]; certificate validation MUST 
conform to RFC 3280;...." instead of saying only "...MUST conform to 
[the PKINIT RFC];..." because the PKINIT RFC includes RFC 3280 by 
reference.

   Doc

--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 11 Jun 2004 13:05:05 -0400

D. R. Evans wrote:

>> I will be quite adamant about the MUST because of my recent 
>> experience with HIPPA regulations.
>> paths are to be validated.  "should" is not a requirement.  
>> therefore, when it comes to a legal setting
>> it may be ignored.  Now you are of course allowed to ignore anything 
>> you don't want to implement
>> even if it is a MUST; but when someone takes advantage of the 
>> loophole you have created to prevent
> Any system is going to require adherence to a bunch of RFCs (as well 
> as other documents); all I am saying is that the system designers 
> should say "...MUST conform to [the PKINIT RFC]; certificate 
> validation MUST conform to RFC 3280;...." instead of saying only 
> "...MUST conform to [the PKINIT RFC];..." because the PKINIT RFC 
> includes RFC 3280 by reference.
>
>   Doc
>
If you are going to selectively decide not to adhere to RFC 3280; which 
PKIX Standards Track documents
do you wish to adhere to?  RFC 3280 is not an Information RFC describing 
a recommended means of
validating certificates.  It is the proposed standard describing the use 
of X.509v3 certificates and X.509v2 CRLs
for use on the Internet. 

All my language does is specify that the use of X.509v3 certificates as 
found in this document requires the
profile adopted by the IETF for use in IETF protocols. 

- Jeff

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 11 Jun 2004 11:23:14 -0600

> profile adopted by the IETF for use in IETF protocols.

But why preclude the possibility of adhering to different documents?

Three years from now maybe there will be three other viable documents. 
But PKINIT will preclude that they be used, even if they are better for 
some purposes. Why is that a good thing?

   Doc

PS Of course, I jest. Three years from now PKINIT won't preclude 
anything, because it won't be an RFC yet :-)

--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2004 13:48:39 -0500

> But why preclude the possibility of adhering to different documents?

Because, for interop, you need a way to figure out which profile to use
from some context, possibly negotiation, but if negotiated then the
negotiation needs to be secure, which, in this case, it cannot be.

> Three years from now maybe there will be three other viable documents. 

See above.  The addition of optional IETF profiles for PKIX won't change
the interop situation mentioned above.

> some purposes. Why is that a good thing?

No, PKINIT won't preclude any new profiles: we'll just have to revise
PKINIT in order to use it with other profiles.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Sat, 12 Jun 2004 01:14:35 +0200 (MET DST)

Well, I think that the PKI stuff is a can of worms that we should
dig into much further.

I'm not convinced that PKINIT needs to require a full blown certificate
profile, because if you're serious, that is likely a huge amount of
code and probably too much to cover it all in interop testing.

Although I agree with Jeff about the path validation and the idea
of trust anchors, I'm don't personally don't feel very cozy with the
full profile since there's just too much stuff in PKI that makes
it far too complex for one or the other use.

We ship SSL but don't support CRLs (certificate revocation),
mostly because it is a huge mess and an implementation that makes
sane use of CRLs is a large piece of work still ahead of us.

(Basically you NEVER EVER want a PKI authentication to require
 any non-local information on a Server, so in order to make
 CRLs work with a Server, you'll need a daemon that regularly
 updates a local CRL cache which the server can check against.)

I don't know what other people feel like, but I consider PKI profiles
more like a guideline, i.e. if you do it, this is how you do it,
but I do consider several features optional, including CRL checking.
(and I don't care if others disagree  ;-).

The Simple Public Key GSS-API mechanism (SPKM) rfc-2025 doesn't
specify any certificate processing rules at all (the internet
profile didn't exist back then), so I don't expect more than
common sense from implementations of SPKM.
(btw. I do consider the discussed path validation and that
 notion of trust anchors a common sense issue, I haven't
 read any of the PKI-related rfcs issued during the last
 few years.)

And even if the majority of the Kerberos crowd wants a full blown
Internet certificate profile requirement in PKINIT, then there will
be no Standards-Police going to arrest implementors that take some
common sense liberties with such a spec.

If one would follow the TLS spec to the letter one would have a very
small customer base because all of the users trying to https-connect
with MSIE would have to be rejected by one's software... 

-Martin