Subject: [Syslog] -transport-tls-12, section 4.2.3 (fingerprint format)

From: Rainer Gerhards <[email-masked]>
Date: Thu, 08 May 2008 15:30:26 +0200

Hi,

yet another question on the fingerprints. My context is that I am
thinking what I need to compare in order to authorize via fingerprints.

Text in question is:

===
The RECOMMENDED mechanism to generate a fingerprint is to take the
SHA-1 hash of the certificate and convert the 20 byte result into 20
colon separated, hexadecimal bytes, each represented by 2 uppercase
ASCII characters.  When a fingerprint value is displayed or
configured the algorithm used to generate the fingerprint SHOULD be
indicated.
===

What is "the algorithm used to generate..."? Is it SHA1 et al, thus
the hash algorithm used? Or is it actually the algorithm that was
used the generate the fingerprint.

If it is the former, it sounds like I should compare the hash values
and not actually the fingerprints. So

55:D8:43:57:39:6C:23:0F:86:B1:EB:93:1E:F3:09:DE:7B:8B:62:70
55-D8-43-57-39-6C-23-0F-86-B1-EB-93-1E-F3-09-DE-7B-8B-62-70

are identical (it is just RECOMMENDED to use colons). However, this
assumes that the fingerprint is always a hash. In this case, I think it
would be preferable to talk directly about the hash values.

If the fingerprint is not necessarily a hash, I need to compare the 
actual fingerprint, the ASCII representation. Then, the two strings above
would be different. That could cause interop problems.

I propose that we strictly define fingerprints to be arbitrarily long 
printable USASCII. If the fingerprint contains unprintable data, the
whole string must be encoded as a set of octets represented by 2 USASCII
hex characters delimited by colons - or we may specify this format for
all cases. This does not tie us to hashes but prevents interoperability
problems due to different formats.

Rainer

I

_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 8 May 2008 22:00:42 +0200

Hi Joe,

Back via the list, the list processor seems to have been recovered.
Thanks for your speedy reply.

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2008 4:58 PM
> To: Rainer Gerhards
> Subject: RE: -transport-tls-12, section 4.2.3 (fingerprint format)
> 
> Hi Rainer,
> 
> Comments below: 
> 
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]] 
> > Sent: Thursday, May 08, 2008 7:39 AM
> > To: Joseph Salowey (jsalowey)
> > Subject: FW: -transport-tls-12, section 4.2.3 (fingerprint format)
> > 
> > Hi Joe,
> > 
> > it looks like there is a problem with the IETF list server. 
> > This and another message did not (yet?) go through. If you've 
> > got a minute, I would appreciate your thoughts (as I am in 
> > the middle of the implementation). I'll forward the other one, too.
> > 
> > Thanks,
> > Rainer
> > 
> > 
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[email-masked]]
> > > Sent: Thursday, May 08, 2008 3:30 PM
> > > To: [email-masked]
> > > Subject: -transport-tls-12, section 4.2.3 (fingerprint format)
> > > 
> > > Hi,
> > > 
> > configured 
> > > the algorithm used to generate the fingerprint SHOULD be 
> indicated.
> > > ===
> > > 
> > > the hash algorithm used? Or is it actually the algorithm 
> > that was used 
> > > the generate the fingerprint.
> > > 
> [Joe] the algorithm is SHA1 which is the algorithm used to 
> generate the
> fingerprint (I'm not sure I answered your question). 

[Rainer] Yes, you answered it, and it is what I expected. I think it may
be useful that the hash algorithm is identified and not the algorithm to
generate the display text. But that's only an issue if there are
multiple ways to encode the display text.

> > > assumes that the fingerprint is always a hash. In this 
> case, I think
> > it
> [Joe] Yes, exactly.  I specified the format to be compatible 
> with common
> tools such as openssl and browsers.  If another format is better than
> that is OK. 

[Rainer] I think that format is very well. I'd just prefer to have a
MUST instead of a RECOMMENDED because I think it isn't useful to allow
multiple encodings here and it can cause interop problems.
> > > actual fingerprint, the ASCII representation. Then, the 
> two strings 
> > > above would be different. That could cause interop problems.
> > > 
> > > whole string must be encoded as a set of octets represented by 2 
> > > USASCII hex characters delimited by colons - or we may 
> specify this 
> > > format for all cases. This does not tie us to hashes but prevents
> > interoperability
> [Joe] I think I agree with you.  The fingerprint should be 
> general and I
> think it should have a consistent format.   It is also important to
> realize the fingerprint is meaningless unless you know what 
> has was used
> to generate it, so this information needs to be communicated with the
> fingerprint. 

[Rainer] I agree - but that's also the reason why I think we should not
permit different was for formatting the fingerprint.

Rainer