- From: Ryan Sleevi <sleevi@google.com>
- Date: Sat, 1 Mar 2014 13:25:29 -0800
- To: Jim Schaad <ietf@augustcellars.com>
- Cc: public-webcrypto@w3.org
- Message-ID: <CACvaWvZU=M2-0_kOkaKHBG7Ho1FqVwW5pFtWDPg2X6rKcUAcjA@mail.gmail.com>
The normative reference is RFC 2631. How does that not answer the question? On Mar 1, 2014 1:13 PM, "Jim Schaad" <ietf@augustcellars.com> wrote: > I ran across this problem within the last couple of years. There is, > unfortunately two different answers to the question. > > > > TLS (RFC 5246) > > > > A conventional Diffie-Hellman computation is performed. The > > negotiated key (Z) is used as the pre_master_secret, and is converted > > into the master_secret, as specified above. Leading bytes of Z that > > contain all zero bits are stripped before it is used as the > > pre_master_secret. > > > > CMS (RFC 2631) > > > > H is the message digest function SHA-1 [FIPS-180 <http://tools.ietf.org/html/rfc2631#ref-FIPS-180>] ZZ is the shared > > secret value computed in Section 2.1.1 <http://tools.ietf.org/html/rfc2631#section-2.1.1>. Leading zeros MUST be > > preserved, so that ZZ occupies as many octets as p. For instance, if > > p is 1024 bits, ZZ should be 128 bytes long. > > > > > > As you can see from the above text, some specifications say to remove > leading zero bytes from ZZ while others say to keep them. > > > > We need to document which is to be implemented by the spec. I would say > to keep the leading zero bytes as I think this is more common, but I have > absolutely no proof of that fact. > > > > Jim > > >
Received on Saturday, 1 March 2014 21:25:57 UTC