Certificate status checks vs validity period; self-signed certs (Re: Current state of editor's draft / IdentitySignal)

On 2007-08-24 14:00:49 -0400, Mary Ellen Zurko wrote:

http://www.w3.org/2006/WSC/drafts/rec/rewrite#sec-pathval

> "Instead of performing step (a) (2) of Basic Certificate Processing 
> (section 6.1.3 of [ref-PKIX]; verification of validity date), the Web user 
> agent verifies that the intersection of the validity period of all 
> certificates in the path (including the entity certificate and trust 
> anchor) is non-empty. If this intersection is empty, relaxed path 
> validation fails."

> I don't remember discussion on this ("not remembering" includes the 
> possibility that it happened and I didn't understand it). 

We didn't have any, yet.

> What's the scoop with redefining path validity periods? Is the
> note at the end of 4.2 the key to it? [it's times like this that
> I'm reminded that reading standards, like reading Shakespeare, is
> not a natural act.]

> And the pkix ref doesn't go anywhere. 
> 
> "Step (a) (3) (status verification) is skipped."
> 
> Since the pkix ref doesn't seem to work, can you say a bit about what this 
> is? Is this CRL/OCSP? (that's what I'm guessing.) 

PKIX is to be a reference to RFC 3280.

Section 4.1.2.5 there:

   The certificate validity period is the time interval during which
   the CA warrants that it will maintain information about the
   status of the certificate.  

The basic point of this section is to deal with certificate
expiration errors.  Currently, user agents don't check certificate
validity against a CRL (using OCSP or whatever other means), but do
check the validity of the certificates, and bug users about that.

That's pretty much meaningless, since users have no way to usefully
deal with it.

The idea in our draft is to say that user agents should do either of
the following two things:

- Follow Basic Path Validation *and* take certificate validity
  checks seriously, i.e., check against a CRL. If that is the case,
  then a certificate that's outside its validity period is a really
  bad thing, and must be treated accordingly.

- Follow the relaxed version defined in section 4.2, and don't
  bother users with validity period errors, since you don't care
  about revocation and validity issues anyway.


> "This specification assumes that Web user agents establish that a
> trust root is [Definition: EV-qualified] through
> security-critical application-specific out-of-band mechanism. "

> I'm always uncomfortable with "and magic happens here", without
> even a single understandable worked example. Is the
> understandable worked example embedding them in the user agent
> code? 

... or a configuration file, yes.

> "Implementations MUST NOT consider a certificate that otherwise
> matches the definition as an Extended Validation Certificate if
> the certificate is marked as an no interaction certificate. "

> I don't understand this, even after following the reference.

If the certificate is marked with the EV policy OID, and with the
"no interaction OID", then the latter takes precedence.

> "Implementations MUST NOT use Relaxed Path Validation if the trust anchor 
> is EV-qualified. "

> But they could use any other random form of validation, including
> a meaningless or null one? 

The intent was to say they should use Basic Path Validation and take
it seriously, but looking into the document right now, that's not
actually said.  Oooops.

(Incidentally, I put this in as a strawman; this is one of the
points that I expect discussion on.)

> "This specification assumes that Web user agents establish that a
> trust root is [Definition: qualified to attest] through a
> security-critical out-of-band mechanism that is out of scope for
> this specification."

> It's getting harder and harder for me to hold on to why this is
> supposed to be helpful with trust decisions. It seems a gap in
> the standard of standards writing that there's not an easy way to
> provide annotations or references to back up statements like
> this. It would certainly cut down on the overhead of dealing with
> comments (where you can provide references to examples or group
> decision making inline, and track them as the draft goes along). 

I'm not quite sure I understand what you're getting at.

Incidentally, the text you're quoting here is more about saying what
we *don't* deal with, than what we do deal with.

> "Self-signed certificates are commonly used for appliances and
> web sites catering to small groups of users,"

> They are also commonly used for inward facing functions in enclosed 
> organizations such as enterprises. 

Happy to add that.

> "[Definition: (normative) A self-signed certificate is called proven for a 
> destination if it has been used for TLS-protected interactions with 
> resources whose URIs share the same authority (domain) and port number for 
> an extensive amount of time, the "probation time."] "

> Is there any background on this, in SSH, or in experience? What
> has SSH used? I suppose it's clear it refers to a specific self
> signed certificate. So that if the self signer changed keys, it
> would be a new one, in a new probation time.

The SSH model is that every host has a key pair (there's no need to
bother with certificates there).

You can administratively distribute the public keys (or their
fingerprints) within an organization (out of band); sometimes,
that's done, sometimes, it isn't done.

When you first connect to an unknown host, you're shown the
fingerprint, you duly ignore that, and tell your client to store it
away in a local configuration file:

| $ ssh people.w3.org
| The authenticity of host 'people.w3.org (128.30.54.11)' can't be established.
| RSA key fingerprint is
| 97:e9:ee:0f:4f:cc:cb:92:94:84:6b:a9:8b:11:86:2a.
| Are you sure you want to continue connecting (yes/no)? 
| Warning: Permanently added 'people.w3.org' (RSA) to the list of known hosts.
  ...

Subsequent logins will just go through, unless a change of key
occurs (either against your personal list of known hosts, or against
an administratively set system-wide one).  

If it does occur, you get nasty error messages, for instance like
this:

| $ ssh people.w3.org
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| @       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| The RSA host key for people.w3.org has changed,
| and the key for the according IP address 128.30.54.11
| is unchanged. This could either mean that
| DNS SPOOFING is happening or the IP address for the host
| and its host key have changed at the same time.
| Offending key for IP in /home/roessler/.ssh/known_hosts:7
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
| Someone could be eavesdropping on you right now (man-in-the-middle
| attack)!
| It is also possible that the RSA host key has just been changed.
| The fingerprint for the RSA key sent by the remote host is
| 97:e9:ee:0f:4f:cc:cb:92:94:84:6b:a9:8b:11:86:2a.
| Please contact your system administrator.
| Add correct host key in /home/roessler/.ssh/known_hosts to get rid
| of this message.
| Offending key in /home/roessler/.ssh/known_hosts:57
| RSA host key for people.w3.org has changed and you have requested
| strict checking.
| Host key verification failed.
| $

(In this case, it actually meant that I had messed around with the
known_hosts file. ;-)

The idea of a probation period (multiple exchanges over some time)
is an addition to the ssh model.

> "If a certificate that otherwise matches the definition for an Extended 
> Validation Certificate bears the User Experience suppression extension, 
> then it MUST NOT be considered as an Extended Validation Certificate. 
> Instead, behavior specified for no interaction certificates MUST be 
> applied. "

> Which is what? or where?

Mostly here:

  http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-change-level
  http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal

Cheers,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Saturday, 25 August 2007 10:02:17 UTC