idnits 2.17.1 draft-evans-palmer-hsts-pinning-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 645 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2011) is 4601 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 588 looks like a reference -- Missing reference section? '2' on line 250 looks like a reference -- Missing reference section? '0' on line 601 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Security C. Evans 3 Internet-Draft C. Palmer 4 Expires: March 24, 2012 Google, Inc. 5 September 21, 2011 7 Certificate Pinning Extension for HSTS 8 draft-evans-palmer-hsts-pinning-00 10 Abstract 12 This memo describes an extension to the HTTP Strict Transport 13 Security specification allowing web host operators to instruct UAs to 14 remember ("pin") hosts' cryptographic identities for a given period 15 of time. During that time, UAs will require that the host present a 16 certificate chain including at least one public key whose fingerprint 17 matches one or more of the pinned fingerprints for that host. By 18 effectively reducing the scope of authorities who can authenticate 19 the domain during the lifetime of the pin, we hope pinning reduces 20 the incidence of man-in-the-middle attacks due to compromised 21 Certification Authorities and other authentication errors and 22 attacks. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 24, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 We propose to extend the HSTS HTTP header to enable a web host to 59 express to UAs which certificate(s) UAs may expect to be present in 60 the host's certificate chain in future connections. We call this 61 "certificate pinning". The Google Chrome/ium browser ships with a 62 static set of pins, and individual users can extend the set of pins. 63 Although effective, this does not scale. This proposal addresses the 64 scale problem. 66 Deploying certificate pinning safely will require operational and 67 organizational maturity due to the risk that HSTS Hosts may "brick" 68 themselves by pinning to a certificate that becomes invalid. We 69 discuss potential mitigations for those risks. We believe that, with 70 care, host operators can greatly reduce the risk of MITM attacks and 71 other false-authentication problems for their users without incurring 72 undue risk. 74 This document extends the version of HSTS defined in [hsts-spec] and 75 follows that document's notational and naming conventions. 77 This draft is being discussed on the WebSec Working Group mailing 78 list, websec@ietf.org. 80 1.1. About Notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119. 86 This document includes some pseudocode examples written in a Python- 87 like language, to clarify UA behavior. The examples assume that a 88 global data structure, hsts_metadata, exists and contains the HSTS 89 metadata that the UA has accumulated over time. It is indexable by 90 domain name and includes the usual HSTS parameters (maxAge, 91 includesSubDomains) as well as the new HSTS parameter, pins, that 92 this document introduces. It also assumes a hypothetical X.509 93 datatype, denoted with a variable named "certificate", that includes 94 likely X.509 fields such as public_key (which would correspond to the 95 SubjectPublicKeyInfo field in a real X.509 certificate). 97 There are also some working code examples using the Python and Go 98 languages. 100 The examples are intended to be illustrative, not necessarily precise 101 or using algorithms that a real, optimized UA would employ. 103 2. Server and Client Behavior 105 To set a pin, HSTS Hosts use a new STS extension directive (STS-d- 106 ext) in their HSTS response header field: pins. To enable pin 107 revocation (Section 2.3), hosts may also use the new breakv and 108 breakc directives. 110 STS-d-ext-pin = "pins" OWS "=" OWS [fingerprints] 111 STS-d-ext-breakv = "breakv" OWS "=" OWS fp-type "/" base64-digits 112 STS-d-ext-breakc = "breakc" OWS "=" OWS base64-digits 114 fingerprints = fingerprint 115 / fingerprint "," fingerprints 117 fingerprint = fp-type "/" base64-digits 119 fp-type = "sha1" 120 / "sha256" 122 Figure 1 124 Here is an example response header field using the pins extension 125 (folded for clarity): 127 Strict-Transport-Security: max-age=500; includeSubDomains; 128 pins=sha1/4n972HfV354KP560yw4uqe/baXc=, 129 sha1/IvGeLsbqzPxdI0b0wuj2xVTdXgc= 131 Figure 2 133 Here is an example response header field using both the pins and the 134 breakv extensions (folded for clarity): 136 Strict-Transport-Security: max-age=500; includeSubDomains; 137 pins=sha1/4n972HfV354KP560yw4uqe/baXc=, 138 sha1/IvGeLsbqzPxdI0b0wuj2xVTdXgc=; 139 breakv=sha1/jUQEXH7Q2Ly+Xn/yFWJxAHT3fDc= 141 Figure 3 143 The fingerprint is the SHA-1 (or SHA-256) hash of the raw 144 SubjectPublicKeyInfo field of the certificate, encoded in base-64 for 145 brevity. We pin public keys, rather than entire certificates, to 146 enable operators to generate new certificates containing old public 147 keys (see [why-fingerprint-key]). (Although host operators may do 148 this, certification authorities already do. Additionally, when UAs 149 check certificate chains, they do so by checking that each 150 certificate is signed by its parent's public key, making the public 151 key -- not the certificate -- the essential identifier.) 153 See Appendix A for an example program that generates public key 154 fingerprints from SubjectPublicKeyInfo fields in certificates. 156 The breakv directive communicates to UAs a pin break verifier, and 157 the breakc directive communicates the pin break code. Hosts SHOULD 158 generate pin break codes and verifiers. When present, UAs MUST note 159 pin break verifiers and honor pin break codes. See Section 2.3 for a 160 discussion of verifiers and codes. 162 2.1. Noting and Validating Pins 164 Upon receipt of this header field, the UA will note the HSTS Host as 165 a Known Pinned HSTS Host. When connecting to a Known Pinned HSTS 166 Host, the UA will compare the public key fingerprint(s) in the Host's 167 certificate chain to the pinned fingerprints, and will fail closed 168 unless at least one public key in the chain has a fingerprint 169 matching one of the pinned fingerprints. (Following the HSTS 170 specification, TLS errors for HSTS hosts must be hard, with no chance 171 for the user to click through any warnings or errors. We treat 172 fingerprint mismatch in the same way.) 174 Note that to validate pins, UAs must necessarily read the headers of 175 a response. In case of mismatch, UAs SHOULD NOT read the response 176 body as part of failing hard. 178 This pseudocode illustrates how UAs validate the certificate chains 179 they receive from Known Pinned HSTS Hosts. 181 def chain_is_pinned_valid(chain, pins): 182 for certificate in chain: 183 for fingerprint in pins: 184 if certificate.public_key.fingerprint == fingerprint: 185 return True 187 return False 189 # ... 190 if not chain_is_pinned_valid(request.tls_info.certificate_chain, 191 hsts_metadata[request.hostname].pins): 192 request.fail() 193 # ... 195 Figure 4 197 The pin list appearing in an HSTS header MUST have at least one pin 198 matching one of the public key fingerprints in the chain that was 199 validated for the HTTPS connection. This defends against HTTP header 200 injection attacks (see Section 3.4.1). 202 UAs MUST cache pins and pin break verifiers for Known Pinned HSTS 203 Hosts, and MIGHT AS WELL do so in the same manner as other HSTS 204 metadata. If the maxAge directive is present in the HSTS response 205 header, the HSTS metadata -- including fingerprints in the pins 206 directive -- expire at that time. 208 2.2. Interactions With Built-in HSTS Lists 210 UAs MAY choose to implement built-in certificate pins, alongside any 211 built-in HSTS opt-in list. UAs MUST allow users to override a 212 built-in pin list, including turning it off. 214 Hosts can update built-in pin lists by using this extension. 215 Similarly, UAs can update their built-in pin lists with software 216 updates. In either case, UAs MUST use the newest information -- 217 built-in or set via HSTS -- when validating certificate chains for 218 the host. 220 2.3. Un-pinning 222 Hosts can enable pin revocation for their previously-pinned key 223 fingerprints by setting pin break verifiers using the breakv 224 directive. Then, when hosts want to break pins, they set the pin 225 break code in their HSTS headers using the breakc directive. (This 226 idea is due to Perrin in [pin-break-codes].) 228 Pin break codes are short random strings, kept secret until the host 229 operator wants to break the pins. Pin break verifiers are simply 230 hashes of the codes. Generating codes and verifiers, and verifying 231 that codes match a previously set verifier, is trivial. See 232 Figure 5. 234 def make_pin_break(): 235 code = os.urandom(16) 236 verifier = hashlib.sha1(code).digest() 237 return base64.b64encode(code), base64.b64encode(verifier) 239 def verify_code(code, verifier): 240 c = base64.b64decode(code) 241 v = hashlib.sha1(c).digest() 242 return verifier == base64.b64encode(v) 244 if __name__ == "__main__": 245 import sys 247 if 1 == len(sys.argv): 248 print make_pin_break() 249 elif 3 == len(sys.argv): 250 print verify_code(sys.argv[1], sys.argv[2]) 252 Figure 5 254 Hosts can request that UAs forget pinned fingerprints by issuing a 255 valid HSTS header containing the pin break code. UAs MUST forget all 256 pinned fingerprints associated with the matching pin break verifier, 257 and MUST NOT forget any pinned fingerprints not associated with that 258 verifier. 260 In the event that a host sends an HSTS header containing a breakc 261 that does not match a breakv the UA has previously noted, the UA MUST 262 ignore that breakc and MUST process any pins or breakv directives as 263 normal. This is so that hosts can break old pins but still 264 successfully set new pins and verifiers in UAs that have not 265 previously (or recently) noted the host. 267 Host operators SHOULD keep the pin break code secret, and SHOULD 268 generate codes that are computationally infeasible to guess (such as 269 by using their system's cryptographic random number generator; note 270 that a 128-bit security level suffices). 272 2.4. Pinning Self-Signed Leaf Certificates 274 To the extent that UAs allow or enable hosts to authenticate 275 themselves with self-signed end entity certificates, they MAY also 276 allow hosts to pin the public keys in such certificates. The 277 usability and security implications of this practice are outside the 278 scope of this specification. 280 3. Security Considerations 282 3.1. Deployment Guidance 284 To recover from disasters of various types, as described below, we 285 recommend that HSTS Hosts follow these guidelines. 287 o Operators SHOULD have a safety net: they should generate a backup 288 key pair, get it signed by a different (root and/or intermediary) 289 CA than their live certificate(s), store it safely offline, and 290 set this backup pin in their pins directive. 292 * Having a backup certificate was always a good idea anyway. 294 o It is most economical to have the backup certificate signed by a 295 completely different signature chain than the live certificate, to 296 maximize recoverability in the event of either root or 297 intermediary signer compromise. 299 o Operators SHOULD periodically exercise their backup pin plan -- an 300 untested backup is no backup at all. 302 o Operators SHOULD have a diverse certificate portfolio. They 303 should pin to a few different roots, owned by different companies 304 if possible. 306 o Operators SHOULD start small. Operators SHOULD first deploy HSTS 307 certificate pinning by setting a maxAge of minutes or a few hours, 308 and gradually increase maxAge as they gain confidence in their 309 operational capability. 311 3.2. Disasters Relating to Compromises of Certificates 313 3.2.1. The private key for the pinned leaf is stolen 315 If a leaf certificate is compromised, the host is likely to have 316 experienced a complete compromise, in which case the problem is 317 greater than certificates and pins. See Section 3.4.2. 319 3.2.2. The root or intermediary CA is compromised 321 This disaster will affect many hosts (HSTS Hosts and other), and will 322 likely require a client software update (e.g. to revoke the signing 323 CA and/or the false certificates it issued). 325 If the operator has a backup pin whose signature chain is still 326 valid, they should deploy it. In this case, the host need not even 327 degrade from Known Pinned to Known. 329 3.3. Disasters Relating to Certificate Mismanagement 331 3.3.1. The leaf certificate expires 333 Operators should deploy their backup pin. 335 Note that when evaluating a pinned certificate, the UA MUST un-pin 336 the fingerprint if the certificate has expired. If a pin list 337 becomes empty, the UA downgrades the host from Known Pinned HSTS Host 338 to Known HSTS Host. The usual HTTPS validation procedure now 339 applies. 341 Operators should get any CA to sign a new cert with updated expiry, 342 based on the existing, unchanged public key. 344 o And/or, operators should deploy their backup pin and/or have a CA 345 sign an all-new key. 347 o Operators should continue to set pins in their HSTS header, and 348 UAs will upgrade from Known HSTS Host to Known Pinned HSTS Host 349 when the fingerprint(s) refer(s) to valid certificate(s) again. 351 3.3.2. The leaf certificate is lost 353 Operators should deploy their backup pin. Alternately, if they 354 pinned to a root or intermediary signer, they should get a new leaf 355 certificate signed by one of those signers. 357 Operators SHOULD attempt to get the certificate revoked by whatever 358 means available (extant revocation mechanisms like CRL or OCSP, 359 blacklisting in the UA, or future revocation mechanisms). 361 o We know that extant revocation mechanisms are unreliable. 362 Operators SHOULD NOT not depend on them. 364 3.3.3. The CA is extorting the operator approaching renewal/expiry time 366 If the backup pin chains to a different signer, the operator should 367 deploy it. (They should then get a new backup pin.) 369 The time running up to renewal can be used to serve additional HSTS 370 public key hashes, pinning to new root CAs. 372 o Hosts can also disable pinning altogether as described above. 374 If the host is pinned to leaves or its own intermediary, operators 375 can simply get a different root CA to sign the existing public key. 377 If the operator fails to get new certs in time, and the host is 378 pinned only to the one root CA, the solution is simple; see 379 Section 3.3.1. 381 3.4. Disasters Relating to Vulnerabilities in the Known HSTS Host 383 3.4.1. The host is vulnerable to HTTP header injection 385 Note that header injection vulnerabilities are in general more severe 386 than merely disabling pinning for individual users. 388 The attacker could set additional pins for certificates he controls, 389 or pin break verifiers for codes he controls, allowing him to 390 undetectably MITM clients. When or if the client is outside the 391 scope of the attacker's MITM attack, the result is DoS. 393 The attacker could disable HSTS and pins. 395 3.4.2. The host suffers full server-side compromise 397 After setting up a new host, operators should deploy the backup pin. 398 Alternately, if the host is pinned to a root or intermediary signer, 399 the operator should get a new leaf certificate signed by one of those 400 signers. 402 Operators SHOULD attempt to get the certificate containing the 403 compromised private key revoked by whatever means available (extant 404 revocation mechanisms like CRL or OCSP, blacklisting in the UA, or 405 future revocation mechanisms). 407 o We know that extant revocation mechanisms are unreliable. Do not 408 depend on them. 410 4. Usability Considerations 412 When pinning works to detect impostor Known Pinned HSTS Hosts, users 413 will experience denial of service. UAs SHOULD explain the reason 414 why. If it happens that true positives (actual attacks) outnumber 415 false positives (hosts bricking themselves by accident), the feature 416 will gain a positive reputation. Note that pinning has started life 417 with a good reputation because it provoked the discovery of the 418 DigiNotar CA compromise. (When DigiNotar signed a certificate for 419 *.google.com in August 2011, Chrome users discovered the attack due 420 to the pre-loaded pins for Google domains.) 422 We believe that, in general, DoS is a better failure mode than user 423 account/session compromise or other result of TLS compromise. 425 UAs MUST have a way for users to clear current pins that were set by 426 HSTS. UAs SHOULD have a way for users to query the current state of 427 Known (Pinned) HSTS Hosts. 429 5. Economic Considerations 431 If pinning becomes common, host operators might become incentivized 432 to choose CAs that get compromised less often, or respond better to 433 compromise. This will require information to flow into the market, 434 and for people to interpret no news post-compromise as bad news. 435 Pinning itself will provide some of that information, as will sources 436 like UA vendor communications, the EFF SSL Observatory, the Qualys 437 SSL survey, etc. 439 The disaster recovery plans described above all incur new costs for 440 host operators, and increase the size of the certificate market. 441 Arguably, well-run hosts had already absorbed these costs because 442 (e.g.) backup certificates from different CAs were necessary disaster 443 recovery mechanisms even before certificate pinning. Small sites -- 444 which although small might still need to provide good security -- may 445 not be able to afford the disaster recovery mechanisms we recommend. 446 (The cost of the backup certificate is not the issue; it is more the 447 operational costs in safely storing the backup and testing that it 448 works.) Thus, low-risk pinning may be available only to large sites; 449 small sites may have to choose no pinning or potentially bricking 450 their host (up to the maxAge window). This is not worse than the 451 status quo. 453 6. Ideas 455 6.1. Requiring Backup Pins 457 Because bricking risk mitigation requires a backup pin, UAs could 458 require that the pins directive have at least two fingerprints, at 459 least one of which does not match any of the public keys in any of 460 the certificates in the chain. (This idea due to Tom Sepez.) 462 6.2. Prepopulating Pin Lists 464 HSTS-based certificate pinning, unlike built-in pinning, suffers from 465 the bootstrap problem. To work around this, we could pre-populate a 466 built-in pin list with public keys as observed in the wild by one or 467 more global observers, such as Googlebot, the EFF SSL Observatory, 468 Convergence notaries, and so on. 470 One problem with this approach is that it does not involve host 471 operators. It is best to get operator consent before signing them up 472 for a potentially risky new protocol such as this. Therefore we 473 leave this idea for work (including third-party UA extensions). 475 6.3. Tools to Assist Creation of Header 477 It would be good to provide tools that read X.509 certificate chains 478 and generate example HSTS headers that operators can easily add to 479 their webs erver configurations. 481 6.4. Pinning Subresources 483 Many hosts have pages that load subresources from domains not under 484 the control, or under only partial control, of the main host's 485 operators. For example, popular hosts often use CDNs, and CDN 486 customers may have only limited, if any, ability to influence the 487 configuration of the CDN's servers. (This long-standing problem is 488 independent of certificate pinning.) 490 To a limited extent, the includeSubDomains HSTS directive can address 491 this: if the CDN host has a name that is a subdomain of the main host 492 (e.g. assets-from-cdn.example.com points to CDN-owned servers), and 493 if the main host's operators can guaranteeably keep up-to-date with 494 the CDN's server certificate fingerprints -- perhaps as part of 495 example.com's contract with the CDN -- then the problem may be 496 solved. 498 CDNs SHOULD also use certificate pinning independently of any of 499 their customers. 501 Although one can imagine an extension to this specification allowing 502 the main resource to set pins for subresources in other domains, it 503 is complex and fragile both from technical and business perspectives. 504 The UA would have to accept those pins for the subresource domains 505 ONLY when loading resources from the subdomains as part of a page 506 load of the main host. The independence of the two domains' 507 operations teams would still pose synchronization problems, and 508 potentially increase the bricking risk. 510 Therefore, except in simple cases, this document leaves the cross- 511 domain subresource problem to future work. Operational experience 512 with HSTS-based certificate pinning should guide the development of a 513 plan to handle the problem. 515 6.5. Pinning Without Requiring HTTPS 517 Some host operators would like to take advantage of certificate 518 pinning without requiring HTTPS, but having clients require pins in 519 the event that they do connect to the host with HTTPS. As specified 520 above, the current HSTS-based mechanism does not allow for this: 521 clients that receive the pins directive via HSTS will also therefore 522 require HTTPS -- that is the purpose of HSTS after all. To have an 523 additional directive, e.g. mode=optional, would not work because 524 older clients that support HSTS but not the mode extension would 525 effectively require HTTPS. 527 Alternatives include (a) putting the pins directive in a new header 528 instead of extending HSTS; and (b) some kind of hack like setting 529 maxAge=0 and having an additional directive to keep the pins alive 530 (e.g. pinMaxAge). These alternatives seem ugly to us and we welcome 531 suggestions for a better way to support this deployment scenario. 533 7. Acknowledgements 535 Thanks to Jeff Hodges, Adam Langley, Nicolas Lidzborski, SM, and Yoav 536 Nir for suggestions and edits that clarified the text. Trevor Perrin 537 for providing the pin break codes mechanism. Adam Langley provided 538 the SPKI fingerprint generation code. 540 8. What's Changed 542 This is the first draft of this proposal submitted as an official 543 Internet Draft. 545 9. References 547 [hsts-spec] 548 Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 549 Transport Security (HSTS)", August 2011, . 553 [why-fingerprint-key] 554 Langley, A., "Public Key Pinning", May 2011, 555 . 557 [pin-break-codes] 558 Perrin, T., "Self-Asserted Key Pinning", September 2011, 559 . 561 [rfc-2119] 562 Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", March 1997, 564 . 566 Appendix A. Fingerprint Generation 568 This Go program generates public key fingerprints, suitable for use 569 in pinning, from PEM-encoded certificates. 571 package main 573 import ( 574 "io/ioutil" 575 "os" 576 "crypto/sha1" 577 "crypto/x509" 578 "encoding/base64" 579 "encoding/pem" 580 "fmt" 581 ) 583 func main() { 584 if len(os.Args) < 2 { 585 fmt.Printf("Usage: %s PEM-filename\n", os.Args[0]) 586 os.Exit(1) 587 } 588 pemBytes, err := ioutil.ReadFile(os.Args[1]) 589 if err != nil { 590 panic(err.String()) 591 } 592 block, _ := pem.Decode(pemBytes) 593 if block == nil { 594 panic("No PEM structure found") 595 } 596 derBytes := block.Bytes 597 certs, err := x509.ParseCertificates(derBytes) 598 if err != nil { 599 panic(err.String()) 600 } 601 cert := certs[0] 602 h := sha1.New() 603 h.Write(cert.RawSubjectPublicKeyInfo) 604 digest := h.Sum() 606 fmt.Printf("Hex: %x\nBase64: %s\n", digest, 607 base64.StdEncoding.EncodeToString(digest)) 608 } 610 Figure 6 612 Authors' Addresses 614 Chris Evans 615 Google, Inc. 616 1600 Amphitheater Pkwy 617 Mountain View, CA 94043 618 US 620 Email: cevans@google.com 622 Chris Palmer 623 Google, Inc. 624 1600 Amphitheater Pkwy 625 Mountain View, CA 94043 626 US 628 Email: palmer@google.com