Subject: [Syslog] Syslog-sign: Trust model, implementation requirements

From: <[email-masked]>
Date: Thu, 5 Feb 2009 10:18:30 +0100

Version -24 added the following text to Section 8:

   The model for syslog-sign is a direct trust system where the
   certificate transferred is its own trust anchor. If a transport
   sender sends a stream of syslog messages that is signed using a
   certificate, the operator or application will transfer to the
   transport receiver the certificate that was used when
   signing. There is no need for a certificate chain.

This clarifies the situation slightly, but does not really have
enough information to ensure interoperable implementations.

I think we need some text specifying the minimal requirements.  Here's
a first sketch, quite similar to what syslog-transport-tls has:

5.3. Originator Authenticaton and Authorization

   When the collector receives a Payload Block, it needs to determine
   whether the signatures are to be trusted. The following methods are
   in scope of this specification:

   o  X.509 certification path validation: The collector is configured
      with one or more trust anchors (typically root CA certificates),
      which allow it to verify a binding between the subject name and
      the public key. Certification path validation is performed
      as specified in [RFC5280].

      If the HOSTNAME contains an FQDN or an IP address, it is then
      compared against the certificate as described in [RFC5425],
      Section 5.2. Comparing other forms of HOSTNAMEs is beyond the
      scope of this specification.

      Collectors SHOULD support this method.

      Note that due to message size restrictions, syslog-sign sends
      only the end-entity certificate in the Payload Block. Depending
      on the PKI deployment, the collector may need to obtain
      intermediate certificates by other means (for example, from a
      directory).

   o  X.509 end-entity certificate matching: The collector is
      configured with information necessary to identify the valid
      end-entity certificates of its valid peers, and for each peer,
      the HOSTNAME(s) it is authorized to use.

      To ensure interoperability, implementations MUST support
      fingerprints of X.509 certificates as described below. Other
      methods MAY be supported.

      Collectors MUST support key blob type 'C', and specifying the
      list of valid peers using certificate fingerprints.  The
      fingerprint is calculated and formatted as specified in
      [RFC5425], Section 4.2.2.

      For each peer, the collector MUST support specifying a list of
      HOSTNAME(s) this peer is allowed to use either as FQDNs or IP
      addresses. Other forms of HOSTNAMEs are beyond the scope of this
      specification.

      If the locally configured FQDN is an internationalized domain
      name, conforming implementations MUST convert it to the ASCII
      Compatible Encoding (ACE) format for performing comparisons as
      specified in Section 7 of [RFC5280]. An exact case-insensitive
      string match MUST be supported, but the implementation MAY also
      support wildcards of any type ("*", regular expressions, etc.)
      in locally configured names.

      Originator implementations MUST provide a means to generate a
      key pair and self-signed certificate in the case that a key pair
      and certificate are not available through another mechanism, and
      MUST make the certificate fingerprint available through a
      management interface.

   o  OpenPGP V4 fingerprints: Like X.509 fingerprints, except key
      blob type 'P' is used, and the fingerprint is calculated as
      specified in [RFC4880] Section 12.2. When the fingerprint value
      is display or configured, each byte is represented in
      hexadecimal (using two uppercase ASCII characters), and space is
      added after every second byte. For example: "0830 2A52 2CD1 D712
      6E76 6EEC 32A5 CAE1 03C8 4F6E".

      Originators and collectors MAY support this methods.

   Other methods, such as "web of trust", are beyond the scope of this
   document.

Thoughts and suggestions for improvement? (We could mandate OpenPGP
fingerprints instead of X.509 -- but using X.509 would be better
aligned with syslog-transport-tls)

Best regards,
Pasi