Subject: [Isms] Responses to Michael Peck's comments for last call

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Apr 2010 16:59:36 -0700

Mike,

Thank's for your comments during IETF last call.  I've simply addressed
most of them but do have some comments below that you may wish to
review.  Pasi, I'd specifically like you to look at item #6 below since
the issue comes from text you contributed to the document.  The WG
should also consider the matter carefully and provide responses.

My responses are prefixed below with "WH:" if you want to search for
them.  The status of each item is as follows:

  DONE:     Suggestion was acted on
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
  DISCUSS:  There is an outstanding question back to you
  ANSWERED: A question was answered but had no action resulting from it

1 DONE Section 2.1 
~~~~~~~~~~~~~~~~~~~
        "TLS Transport Model SHOULD support the message encryption"
        change to:
        "TLS Transport Model SHOULD support message encryption"

        + WH: done

2 DONE 4.1 
~~~~~~~~~~~
        Change "; Other" to "; other"

        + WH: done

3 DONE 4.1.1 
~~~~~~~~~~~~~
        Trusted public keys.. certificates, MUST
        - Remove the comma before MUST

        + WH: done

4 DONE 5.1.1 Step 2a 
~~~~~~~~~~~~~~~~~~~~~
        Missing letter "I" (as in If) at the beginning of the paragraph

5 DONE 5.3.1 Step 4, 5.3.2 Paragraph 2: 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        These both imply transmitting can begin before the TLS
        handshake is complete as long as the certificates have been
        transmitted/verified?  I think you want to say that the TLS
        handshake has successfully completed first.

        + WH: How's this for new text replacing the previous sentence:

          The (D)TLS client MUST NOT transmit SNMP messages until the
          server certificate has been authenticated, the client
          certificate has been transmitted and the TLS connection has
          been fully established.

6 DISCUSS 5.3.2 Paragraph 1: 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        "authenticating... through a path validation process.. or
        through a certificate fingerprint verification"

        Just to clarify, does this mean that if a certificate directly
        matches the fingerprint in the MIB, then RFC5280 path
        validation is not performed and nothing else about the
        certificate is checked?  I think that may be okay.  For
        example, it would provide an override mechanism to be able to
        manage the device even if the certificate (or the certificates
        above it in the chain) has expired, rather than potentially
        being locked out of the device completely.

        + WH: That's correct: a matching fingerprint can be used to not
          require chaining to a trust anchor.  The current text
          actually comes from Pasi and the interesting side-effect is
          that we don't discuss date ranges and I'm not sure we should
          do this.  I'm more tempted to say we need to add in text
          describing that the date validity should be checked.  I
          don't think anyone intended for this to be a way to trump
          other issues with it other than trust anchor chaining.

6.1 DONE "fingerprints configure" -> "fingerprints configured" 
===============================================================

       + WH: done

6.2 DONE "establishment MUST fail, the" -> "establishment MUST fail, and the" 
==============================================================================

       + WH: done

7 DONE tlstmCertToTSNTable: 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Change "CA certificate or self-signed public certificate" to
        "trust anchor, which could be represented as a self-signed
        certificate"

        A CA certificate or self-signed certificate
        provides a means for representing a trust anchor - other
        formats exist, such as the Trust Anchor Format recently
        published by PKIX.  For your document's purposes it doesn't
        matter which format is used (it can be implementation
        dependent).  Usually a certification path doesn't begin with
        any CA certificate (for example, an intermediary CA
        certificate), it begins with a root CA certificate, which is
        typically represented as a self-signed certificate.  However,
        someone could choose to designate the intermediary CA
        certificate as a trust anchor and just start the path
        validation there if they wanted to.

        + WH: I've made this change.  I was originally shying away
          from using the term "trust anchor" since the current PKIX
          work hasn't finished yet (ie, it's not an RFC yet).  But I
          do agree the wording is better.

8 WONTDO "However, the usage of the CommonName field is deprecated" 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        I think the usage of CommonName is deprecated for representing
        hostnames (SubjectAltName dNSName should be used instead), but
        the general usage of CommonName is not deprecated.

        + WH: I believe that it shouldn't be used as a unique
          identifier.  Though I agree that it hasn't been deprecated to
          name someone, I think the rfc822Name is a better unique naming
          for principals.  If others have opinions on this subject,
          please speak up!

9 DONE tlsTmParamsClientFingerprint 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        Change "should store the hash of a locally held X.509
        certificate (and the corresponding private key) that should be
        used" to:

        "should store the hash of a locally held X.509 certificate
        that should be used (along with the corresponding private
        key)" to make it clear that the private key is not part of
        what is hashed, only the certificate

        + WH: done

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: <[email-masked]>
Date: Wed, 7 Apr 2010 09:17:38 +0200

> should also consider the matter carefully and provide responses.
<snip>

> 6 DISCUSS 5.3.2 Paragraph 1:

AFAIK the intent was that if the fingerprint matches, the only field
used from the certificate is SubjectPublicKeyInfo (since that's needed
by TLS) -- everything else (such as validity dates, subject,
subjectAltName, key usages, constraints, policies, etc.) is ignored.

(But the main use case for this is self-signed certificates -- where
nobody is really certifying that those ignored fields contain anything
meaningful -- but I guess nothing prevents one from using it as an
override mechanism...)

<snip>
> 7 DONE tlstmCertToTSNTable:

I think the intent was slightly different here: the client's
certificate can *either* be validated with a trust anchor, or it can
directly match a row (in which case it's probably self-signed -- but
doesn't have to be).

But it looks like the text indeed says something else: the third
paragraph says this table is consulted only after the certificate has
been found authentic, so a self-signed certificate would never
match...

Proposed rephrasing:

   This table is used by a (D)TLS server to map the (D)TLS client's
   presented X.509 certificate to a tmSecurityName.

   On an incoming (D)TLS/SNMP connection the client's presented
   certificate must either be validated based on an established trust
   anchor, or it must directly match a fingerprint in this table. This
   table does not provide any mechanisms for configuring the trust
   anchors; the transfer of any needed trusted certificates for path
   validation is expected to occur through an out-of-band transfer.

   Once the certificate has been found acceptable (either by path
   validation or directly matching a fingerprint in this table), this
   table is consulted to determine the appropriate tmSecurityName to
   identify with the remote connection. [...]

Best regards,
Pasi

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 07 Apr 2010 09:06:08 -0700

>>>>> On Wed, 7 Apr 2010 09:17:38 +0200, <[email-masked]> said:

PE> AFAIK the intent was that if the fingerprint matches, the only field
PE> used from the certificate is SubjectPublicKeyInfo (since that's needed
PE> by TLS) -- everything else (such as validity dates, subject,
PE> subjectAltName, key usages, constraints, policies, etc.) is ignored.

Ok; I was willing to go either way as I consider both ways useful.
(actually, if this was earlier in the game I might have pushed for
another column to dictate whether the date should be checked or not).

PE> But it looks like the text indeed says something else: the third
PE> paragraph says this table is consulted only after the certificate has
PE> been found authentic, so a self-signed certificate would never
PE> match...

That's a good point.

PE> Proposed rephrasing:

And I've installed that text, which I agree better describes what the WG
solution was expecting.  Thanks!
-- 
Wes Hardaker
Cobham Analytic Solutions