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
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
