Kent Watsen <[email protected]> wrote: > > > > On Oct 23, 2019, at 4:18 AM, Martin Bjorklund <[email protected]> wrote: > > > > Hi, > > > > Since this is a problem with ietf-x509-cert-to-name I reply to this > > question here, rather than buried in a reply to another issue for > > another document ;-) > > > > Kent Watsen <[email protected]> wrote: > >> Separately, I just noticed an issue with the > >> `ietf-[net/rest]conf-server` modules using x509c2n:cert-to-name. > >> > >> ``` > >> leaf fingerprint { > >> type x509c2n:tls-fingerprint; > >> mandatory true; > >> description > >> "Specifies a value with which the fingerprint of the > >> full certificate presented by the peer is compared. If > >> the fingerprint of the full certificate presented by the > >> peer does not match the fingerprint configured, then the > >> entry is skipped, and the search for a match continues."; > >> ``` > >> > >> This definition seems to exclude authenticating client certificates > >> via a trust anchor certificate as, if one can configure a fingerprint, > >> then one could also configure the whole certificate (e.g., > >> `tls-server-parameters/client-authentication/client-certs`), thus > >> obviating the need for > >> `tls-server-parameters/client-authentication/ca-certs`. > > > > [...] > > > >> A better definition (I think) would've been: > >> > >> ``` > >> OLD: full certificate presented by the peer > >> NEW: full certificate of the certificate used to authenticate the > >> certificate presented by the peer, which MAY be the peer's end-entity > >> certificate. > >> ``` > > > > Hmm, I think you found an inconsisteny in this module. Note that the > > description of the list itself has: > > > > The cert-to-name entry's fingerprint > > determines whether the list entry is a match: > > > > 1) If the cert-to-name list entry's fingerprint value > > matches that of the presented certificate, then consider > > the list entry a successful match. > > > > 2) If the cert-to-name list entry's fingerprint value > > matches that of a locally held copy of a trusted CA > > certificate, and that CA certificate was part of the CA > > certificate chain to the presented certificate, then > > consider the list entry a successful match. > > > > Also note: > > > > Security administrators are encouraged to make use of > > certificates with subjectAltName fields that can be mapped to > > names so that a single root CA certificate can allow all > > child certificates' subjectAltName fields to map directly to > > a name via a 1:1 transformation. > > > > So I think this is a bug in the description of "leaf fingerprint". > > I'd rather it be that than a bug in "list cert-to-name". Would an > erratum be appropriate here? While the fix effectively changes the > meaning of "fingerprint", it only would do so in order to resolve the > inconsistency, and thus seems necessary. > > Martin, if you agree, would to like to propose text or go straight to > submitting an erratum?
I'll check with my co-author and get back. > >> I note that `fingerprint` may be 0 characters in length, which is what > >> netconf/restconf servers wanting to support authenticating clients via > >> a trust anchor will need to do in their configurations. I'll update > >> the examples in those drafts to include an empty `fingerprint` node. > > > > But 0-length fingerprint won't match anything, which means you won't > > get a user name and the client can't be authenticated, and the session > > dropped. > > Actually, I thought that this was on purpose, as SnmpTLSFingerprint in > RFC 6353 (referenced by "typedef tls-fingerprint" says (note the 3rd > paragraph): > > SnmpTLSFingerprint ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x:1x" > STATUS current > DESCRIPTION > "A fingerprint value that can be used to uniquely reference > other data of potentially arbitrary length. > > An SnmpTLSFingerprint value is composed of a 1-octet hashing > algorithm identifier followed by the fingerprint value. The > octet value encoded is taken from the IANA TLS HashAlgorithm > Registry (RFC 5246). The remaining octets are filled using the > results of the hashing algorithm. > > This TEXTUAL-CONVENTION allows for a zero-length (blank) > SnmpTLSFingerprint value for use in tables where the > fingerprint value may be optional. MIB definitions or > implementations may refuse to accept a zero-length value as > appropriate." > REFERENCE "RFC 5246: The Transport Layer > Security (TLS) Protocol Version 1.2 > http://www.iana.org/assignments/tls-parameters/ > " > SYNTAX OCTET STRING (SIZE (0..255)) > > Does it not have the same meaning? No, in many SMIv2 objects, a zero-length value is used for optional nodes (due to the way the protocol (SNMP) works). In YANG we don't do this, since the protocls (NETCONF etc) can handle non-existing optional leafs. /martin > > Kent // contributor > > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
