Re: [certid] Fwd: secdir review of

[Martin Rex <[e-mail]>]

some personal comments on (parts of) Barry's review.

Peter Saint-Andre wrote:
> 
> Comments are in order of appearance, not significance:
> 
> -- Page 16, bullet 6:
>        The certificate MAY contain more than one DNS-ID, but SHOULD NOT
>        contain more than one CN-ID.
> 
> Why "SHOULD NOT", and not "MUST NOT" ?  I'm not challenging this; it's
> a question.

This was supposed to be a BCP.  The current implementation practice
is that many existing clients honor/match only the "most specific" CN
(as per rfc-2818), but do _not_ abort when multiple CNs are present,
and a small number of clients match all CNs.

A "MUST NOT" would be a change to what is out there any make the
entire installed base non-compliant that does not abort on the presence
of multiple CN AVAs in a server cert.


But there is another issue.  This document is directed to a non-obviously
large and diverse target audience, and takes short cuts.

  - Server admins MUST NOT create or request server certs with multiple
    CN-IDs.
  - CAs MUST NOT sign/issue server certificates with multiple CN-IDs.
  - Servers should not use certificates with multiple CN-IDs.
  - Clients SHOULD NOT match CN-IDs if SRV-IDs or DNS-IDs are present
    in a server cert.  If client match CN-IDs anyhow, as a fallback
    for server certs without SRV-IDs and DNS-IDs, then they should
    match only the "most specific" CN as per rfc-2818.
  - architecture-wise I personally think of the CN-ID match as a
    fallback for DNS-ID matching rather than an entirely seperate
    reference identifier.

> 
> -- Page 17, sec 4.2, first graf:
>    Before connecting to the server, the client MUST construct a list of
>    acceptable reference identifiers.
> 
> Why MUST it be done "before"?  Can anyone detect, or does it hurt
> interoperability, if it's done, say, in parallel with connection, or
> while the client is waiting for the server to return the certificate?

This imperative MUST is underexplained.  It's likely possible to
convey the underlying idea without an rfc2119 imperative.

rfc-2119 MUST and MUST NOT always translate to code in the
implementation and to test cases for compliance in validation
test suites.  "needs to / will have to", while conveying a very similar
message at the natural language level, doesn't have such impact on the code.

The client consists of several different layers/components,
The application client (above TLS) and the TLS client implementation.

What is probably meant is that the application client needs to produce
a list of acceptable reference identifiers before asking the TLS
client implementation to start a TLS handshake.  The TLS client
implementation will need the DNS-ID for composing a TLS ClientHello
with a TLS extension "Server Name Indication" (SNI).

As a rule of thumb (netiquette/politeness), you should make up your mind
whether you want to enter before you rap on a door (dial a phone number
or connect some network service) in order not to annoy those who answer. :)


> 
> -- Page 18, sec 4.2, last bullet:
>    o  The list SHOULD NOT include a CN-ID; however, the CN-ID (if
>       included) MUST be constructed only from the source domain and
>       never from a target domain.
> 
> I find this oddly put.  How about "The list SHOULD NOT include a
> CN-ID.  If a CN-ID is used despite this advice, it MUST be..." ?

I think its fine to use the term CN-ID when describing actual components
of a certificate, but for the actual matching of the server endpoint
identity, I would always implement CN-ID matching as a fallback of DNS-ID
matching, not as matching of a conceptually distinct reference identifier.


> 
> -- Page 18, sec 4.3, first graf:
>    by seeking a match and aborting the search if any presented
>    identifier matches one of its reference identifiers.
> 
> "Aborting" has the connotation of premature termination, before
> completion, and that's not the case here; you're saying that the match
> completes the process.  How about, simply, "stopping", or "ending" ?

maybe "succeeding the search" or "successfully stop the search"?


> 
> -- Page 19, sec 4.4.3:
> I think implementers might think that you're simply allowing any
> leading wildcard character, so we should explicitly dissuade them.
> 
> So, in the first graf:
>    the wildcard character '*', but only as the left-most label of the
>    domain name,
> make it "only as the complete value of the left-most label".

Now that you mention it:

4.4.3. Checking of Wildcard Labels

(e.g., baz*.example.net is not allowed and MUST NOT be taken to match
   baz1.example.net and baz2.example.net)

This is in clear contradiction to the wildcard matching specified
in rfc-2818 Section 3.1.  And without any rationale for this U-Turn,
that seems to be entirely inappropriate for a BCP.

In my implementation of RFC-2818 wildcard matching, I deliberately
ignore DNS names that contain more than one wildcard character,
have a wildcard character in different but the leftmost label 
or have a wildcard character and less than 3 DNS labels.
But I certainly do the substring match specified in rfc-2818
and I'm not going to remove the substring match from my
implementation without a convincing rationale...

What exactly is the benefit of allowing a full wildcard match but
prohibiting a partial/substring wildcard match of the leftmost label?


> 
> -- Page 19, sec 4.4.3, last graf:
>    A specification that references the rules defined in this document
>    can specify that the wildcard character is not allowed in
>    certificates used by the relevant application protocol or community
>    of interest.

To me this sounds awkward.  It implies that either the CA has a flawed CPS
can not appropriately deal with wildcard reference identifiers in certs,
or is in general not trustworthy or that the wildcard-scheme too dangerous
(=too difficult to handle safely) for server admins.


> 
> How about “...can strengthen this section by ruling out wildcard
> matching altogether for the relevant...” ?
> 
> -- Page 20, sec 4.4.4, second graf:
>    entry types supported by the client), the client MAY as a fallback
>    check for a string whose form matches that of a fully-qualified DNS
>    domain name in the CN-ID.
> 
> Back in section 4.2, you say that the client SHOULD NOT include CN-ID
> in the list, and here you're saying that it MAY make such a
> comparison.  That seems oddly contradictory to me, though one can
> certainly argue that SHOULD NOT implies MAY.  I'd prefer to see this
> worded differently.

Yup, there is a disconnect.  Although at the colloquial level,
"should not" is often treated as a "may", there is a sigificant
difference for these imperatives in technical specs.

  SHOULD NOT   http://tools.ietf.org/html/rfc2119#section-4
  MAY          http://tools.ietf.org/html/rfc2119#section-5

MAY indicates something truely optional, completely at the discretion
of the target audience of this imperative, not requiring considerations
one way or the other, whereas "SHOULD NOT" is a clear recommendation, that
requires a rationale in the spec so that the target audience of
this imperative can "understand and carefully weigh the full implications"
before deciding to not follow the recommendation.


> 
> -- Page 21, sec 4.6.2:
>    client MUST verify that the presented certificate matches the cached
>    certificate and (if it is an interactive client) MUST notify the user
>    if the certificate has changed since the last time a secure
>    connection was successfully negotiated (where causes of change
>    include but are not limited to changes in the DNS domain name,
>    identifiers, issuer, certification path, and expiration date).
> 
> I worry about this kind of advice.  It violates my rule that says,
> "Don't ask the user a question that he's not qualified to answer."

SSH's traditional behaviour in a comparable situation would be to
print a warning an fail (no offering of an _easy_ leap-of-faith
override for something that shouldn't happen).


What confuses me is that 4.6.1 + 4.6.2 + 4.6.3 would allow a server,
which originally offered an inadequate server certificate which the
user manually confirmed, to unconditionally and silently bypass
the users manual confirmation with appropriately looking server cert
from any arbitrary trust anchor.  This doesn't seem right.

The option of memorizing a server certificate for future reconnects
would significantly improve the security.  Once a client caches
a server cert that is manually confirmed by the user, this could
protect a user on future reconnects to the same server from
an attacker that succeeds subverting a trusted CA.  Even from
full compromise of all CAs by that attacker.  
 

I wondering why PKIX designed trust in X.509 PKIs so much
different to trust relationship of human beings.

Human Trust starts with initial (leap-of-)faith and grows
stronger over time.  Memorizing server certs and first contact
would match this much better than the traditional Web Browser
model, where the millionth TLS handshake to the same peer
is just as vulnerable to the full scope of attacks as the
very first TLS handshake.  SSH got this one right from the
beginning, whereas in SSL/TLS the absence of secure re-authentication
looks like a genetic defect that has prevailed through all protocol
and browser generations (inherited from X.509 PKI).


-Martin