prEN IEC 63758-11:2026

• Status: Not Published
• Publication Date: 23-Feb-2028
• Technical Committee: CLC/TC 100X - Audio, video and multimedia systems and equipment and related sub-systems
• Current Stage: 4020 - Enquiry circulated - Enquiry
• Start Date: 18-Sep-2026
• Completion Date: 18-Sep-2026
• Directive: 2014/53/EU - Directive 2014/53/EU of The European Parliament and of the Council of 16 April 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of radio equipment and repealing Directive 1999/5/EC
• Mandate: M/607 - COMMISSION IMPLEMENTING DECISION of C(2025)1207 on a Standardisation Request M/607 as regards charging interface and charging communication protocol for radio equipment capable of being recharged by means of wireless charging in relation with Article 3(4), sixth subparagraph, of Directive 2014/53/EU of the European Parliament and of the Council.
• Ref Project: oSIST prEN IEC 63758-11:2026 - Qi Specification - Version 2.3 - Part 11: Authentication protocol (Fast Track)

prEN IEC 63758-11:2026 is a CLC/IEC draft for the Qi Specification, Version 2.3, Part 11, on the Authentication protocol for wireless power. It specifies how a Power Receiver authenticates a Power Transmitter using certificate chains, cryptographic messages, timing rules, and revocation support so the Power Receiver can verify that the Power Transmitter is Qi certified and comes from a registered manufacturer.

What does prEN IEC 63758-11:2026 specify?

prEN IEC 63758-11:2026 defines the architecture and application-level messaging for authentication in the Qi system. The document focuses on the exchange between a Power Receiver and a Power Transmitter, using Data Transport Streams from the Qi communications layer.

Clause 1 introduces the structure, compliance rules, references, and notation. Clauses 2 to 7 cover the authentication concept, certificates and private keys, protocol messages, timing, and example flows. Clause 8 gives informative cryptographic examples, and the annexes provide sample data, behavioural guidance, and object identifiers.

Annex	What it covers
Annex A	Sample data, including PEM and ASN.1 parser output for the example certificates
Annex B	Behaviour guidelines for Qi PRx when a PTx fails to authenticate
Annex C	Object Identifiers (OID) used for Qi Authentication extensions

What are the key requirements of prEN IEC 63758-11:2026?

The core requirement is that a Power Receiver uses this Authentication protocol to verify a Power Transmitter before deciding how much power, if any, to accept. In practice, this lets a receiver apply policy to trusted, untrusted, legacy, or revoked transmitters instead of treating every charger the same.

Certificate-based authentication model

Clause 2.3 describes a certificate-based method. A Power Receiver authenticates a Power Transmitter and, based on policy, can choose whether to use the transmitter’s advertised capabilities. Clause 2.3.2 also allows periodic re-authentication, which matters when a device may be moved, replaced, or tampered with after the first trust check.

Cryptographic methods and randomness

Clause 2.2 sets a 128-bit security target for the cryptographic primitives used here. The document uses ECDSA with the NIST P-256 / secp256r1 curve and SHA-256, with X.509v3 certificates encoded in DER. Clause 2.2.1 ties key generation and protocol exchanges to cryptographic-quality random numbers, with output from an SP800-90A-compliant PRNG seeded with 256 bits of SP800-90B entropy treated as sufficient. For implementers, that means the authentication design depends on standard public-key and hash tooling, not custom algorithms.

Certificate chains, slots, and private keys

Clause 3 defines a Certificate Chain as three certificates: a Root Certificate hash, a Manufacturer CACertificate, and a ProductUnitCertificate. The Root Certificate identifies the WPC Root Certificate Authority, the Manufacturer CACertificate identifies the manufacturer, and the ProductUnitCertificate identifies the individual Power Transmitter product unit.

The document requires each ProductUnitCertificate to identify a unique product unit and each Power Transmitter product unit to have a unique public key. Clause 3.3 limits a Power Transmitter to four Certificate Chain slots, with slots 0 and 1 reserved for chains rooted with a WPC Root Certificate. Slots 2 and 3 can hold manufacturer-dependent chains. In practice, this is the main provisioning model: a product ships with one or more authenticated identities, each tied to protected private keys.

Clause 3.4 and 3.5 place key protection on the manufacturer. A Power Transmitter must store its private key securely, and manufacturers shall not reuse a private key from one product unit or Manufacturer CACertificate in another product unit or certificate.

Certificate profiles and extensions

Clause 3.2.1 fixes the certificate format to X.509v3, ASN.1, and DER. Textual ASN.1 objects in certificates use UTF8String, with a maximum length of 64 bytes excluding DER overhead. That matters for compatibility, because long names or free-form text can break certificate processing.

The Manufacturer CACertificate must carry BasicConstraints with cA set to true and pathLenConstraint set to zero. It also contains the custom wpc-qi-policy extension, which is reserved in this version and must have bits zero and one set. The ProductUnitCertificate must contain the wpc-qi-rsid extension, which stores a unique sequential identifier for range-based revocation. Clause 3.2.1.7 gives the size constants for these fields, and the certificate size limits are set for Manufacturer CACertificate and ProductUnitCertificate.

Authentication messages and error handling

Clause 4 defines three operations: GET_DIGESTS, GET_CERTIFICATE, and CHALLENGE. Clause 5 defines the message header, message types, request formats, and response formats. A Power Receiver may use the operations in any order, which lets implementers optimize for caching or faster trust decisions.

The protocol requires strict handling of bad requests. Invalid fields return INVALID_REQUEST, unsupported protocol versions return UNSUPPORTED_PROTOCOL, timing failures return BUSY, and any other error returns UNSPECIFIED. Clause 4.2 also limits GET_CERTIFICATE reads to valid offsets and lengths. For readers implementing the protocol, this is the part to test carefully because malformed offsets, unsupported versions, and busy responses are all explicitly defined.

Timing and retry behavior

Clause 6 gives the timing rules. A Power Receiver waits 43 seconds for GET_DIGESTS, 23 seconds for CHALLENGE, and for GET_CERTIFICATE it waits N×0.3 + 4 seconds, with a minimum of 5 seconds. A Power Transmitter must be ready to start sending each corresponding response within 3 seconds.

The Power Receiver should retry the first request up to five times if it times out. Later timeouts are treated as errors rather than retried again. In practice, this section defines the user-visible delay budget and the interoperability expectations between receiver firmware and transmitter response timing.

Revocation support and ecosystem impact

Clause 2.5 says that if a Power Receiver supports Authentication functionality, it should support Revocation. Revocation Lists are normally updated offline, such as during firmware updates or manufacturing, and the document encourages frequent updates. Clause 2.4 explains that the impact on existing Power Transmitter products depends on policy decisions for legacy transmitters. That means a product owner can choose either a permissive or a restrictive policy for older equipment.

What terms does prEN IEC 63758-11:2026 define?

• Power Receiver (PRx) - The Qi device that authenticates a Power Transmitter and decides how much power to accept.
• Power Transmitter (PTx) - The charger or other source that proves its identity through the authentication exchange.
• Certificate Chain - The three-certificate structure used for authentication: Root Certificate hash, Manufacturer CACertificate, and ProductUnitCertificate.
• Manufacturer CACertificate - The certificate that identifies the manufacturer and signs ProductUnitCertificates.
• ProductUnitCertificate - The certificate that identifies one Power Transmitter product unit and carries its public key.
• Revocation List - The list used by a Power Receiver to stop trusting revoked certificates.
• RSID - The Qi revocation sequential identifier used for range-based revocation of batches.
• wpc-qi-policy - The custom Manufacturer CA certificate extension reserved by this version of the specification.

Who uses prEN IEC 63758-11:2026?

prEN IEC 63758-11:2026 is used by companies that design Qi Power Transmitters and Power Receivers, especially in wireless charging products such as mobile phones, chargers, and other flat-surface devices. It is also relevant to security engineers, firmware developers, certificate provisioning teams, quality managers, and conformity assessment teams who need to implement or verify authentication behavior.

Manufacturers use it when generating certificates, protecting private keys, building slot-based certificate storage, and deciding how a receiver should behave when authentication fails or revocation applies. Buyers and product managers use it to check whether a device supports authenticated Qi operation and what policy it can enforce against untrusted transmitters.

What standards are used with prEN IEC 63758-11:2026?

The document says that, unless specified otherwise, undated references use the most recent published version available as of 1 January 2018. The main named references are:

• ANSI X9.62-2005 - Provides the ECDSA cryptography reference.
• NIST FIPS 186-4 - Provides ECDSA, DSS, and the recommended elliptic curve reference used for P-256.
• ISO/IEC 14888-3 - Provides discrete-log-based digital signature mechanisms.
• ISO/IEC 15946 - Gives the elliptic-curve framework that includes P-256 as an example.
• SEC1 - Provides elliptic curve cryptography conventions, including point representation.
• SEC2 - Provides recommended elliptic curve domain parameters.
• NIST FIPS 180-4 - Provides SHA-256.
• ISO/IEC 10118-3 - Provides dedicated hash functions, including SHA-256.
• NIST SP 800-90A - Supports the random number generator model used for protocol exchanges.
• NIST SP 800-90B - Provides entropy guidance for the random number source.
• Universal Serial Bus Type-C Authentication Specification - The document aligns closely with USB Authentication.
• ITU-T X.509 - Provides the certificate framework used for all Qi Authentication certificates.
• ISO/IEC 9594-8 - The ISO version of the X.509 public-key and attribute certificate framework.
• IETF RFC 5280 - Provides the X.509 certificate and CRL profile.

The document also relies on the Qi Specification, Communications Protocol for Data Transport Streams and packet notation, and it points to the WPC Manufacturer Agreement and the Authorized Manufacturer and MCSP agreements for private-key protection and revocation-related obligations.

What does the prEN IEC 63758-11:2026 document contain?

prEN IEC 63758-11:2026 contains a technical overview of the authentication model, detailed certificate profiles, message formats, timing rules, and protocol flow examples. Section 8 is informative and walks through X.509 certificate basics, ECDSA signature verification, a dummy root CA certificate, a manufacturer CA certificate example, two ProductUnitCertificate examples, certificate-chain assembly, and full authentication examples.

Annex A gives sample PEM and ASN.1 parser output for the example certificates. Annex B gives behavioural guidance for Qi PRx products when a PTx fails to authenticate, including examples for BPP, legacy EPP, and EPP5 Power Transmitter Products. Annex C lists the OIDs used for the Qi Authentication certificate extensions and the ASN.1 module that defines them.

SLOVENSKI STANDARD
01-november-2026
Specifikacija Qi - Različica 2.3 - 11.del: Avtentikacijski protokol (hitri postopek)
Qi Specification - Version 2.3 - Part 11: Authentication protocol (Fast Track)
Ta slovenski standard je istoveten z: prEN IEC 63758-11:2026
ICS:
29.240.99 Druga oprema v zvezi z Other equipment related to
omrežji za prenos in power transmission and
distribucijo električne energije distribution networks
33.160.99 Druga avdio, video in Other audio, video and
avdiovizuelna oprema audiovisual equipment
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

100/4554/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 63758-11 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2026-09-18 2026-12-11
SUPERSEDES DOCUMENTS:
IEC TC 100 : AUDIO, VIDEO AND MULTIMEDIA SYSTEMS AND EQUIPMENT
SECRETARIAT: SECRETARY:
Japan Ms Mahiru Uehara
OF INTEREST TO THE FOLLOWING COMMITTEES: HORIZONTAL FUNCTION(S):
TC 106,TC 108
ASPECTS CONCERNED:
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft for
Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they
are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).

TITLE:
Qi Specification - Version 2.3 - Part 11: Authentication protocol (Fast Track)

PROPOSED STABILITY DATE: 2029
NOTE FROM TC/SC OFFICERS:
As this is a fast-track process offered by WPC, the Word file is not provided.

electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

QiSpecification
AuthenticationProtocol
Version2.3
PublishDate:08December2025
DISCLAIMER
Theinformationcontainedhereinisbelievedtobeaccurateasofthedateofpublication,butisprovided“asis”andmay
containerrors.TheWirelessPowerConsortiummakesnowarranty,expressorimplied,withrespecttothisdocument
anditscontents,includinganywarrantyoftitle,ownership,merchantability,orfitnessforaparticularuseorpurpose.
NeithertheWirelessPowerConsortium,noranymemberoftheWirelessPowerConsortiumwillbeliableforerrorsin
thisdocumentorforanydamages,includingindirectorconsequential,fromuseoforrelianceontheaccuracyofthis
document.Foranyfurtherexplanationofthecontentsofthisdocument,orincaseofanyperceivedinconsistencyor
ambiguityofinterpretation,contact:[e-mail].

Contents
1. General 6
1.1 StructureoftheQi Specification 6
1.2 Scope 7
1.3 Compliance 7
1.4 References 7
1.5 Conventions 8
1.5.1 Notationofnumbers 8
1.5.2 Tolerances 8
1.5.3 Fieldsinadatapacket 8
1.5.4 Notationoftextstrings 9
1.5.5 Short-handnotationfordatapackets 9
2. Overview 10
2.1 References 10
2.1.1 ECDSA 10
2.1.2 NISTP-256,secp-256r1 10
2.1.3 SEC1 10
2.1.4 SEC2 11
2.1.5 SHA-256 11
2.1.6 SP800-90A 11
2.1.7 SP800-90B 11
2.1.8 USBAuthentication 11
2.1.9 X.509 11
2.2 Cryptographicmethods 11
2.2.1 Randomnumbergenerators 11
2.3 Securityoverview 11
2.3.1 Methodology 12
2.3.2 Periodicre-Authentication 12
2.4 Impacttoexistingecosystem 12
2.5 Supportforrevocation 12
3. Certificatesandprivatekeys 13
3.1 CertificateChains 13
3.2 Certificates 14
3.2.1 FormatofCertificates 14
3.3 CertificateChainslots 25
3.3.1 Provisioning 26
3.4 PowerTransmitterprivatekeys 26
3.5 Otherprivatekeys 26
4. Authenticationprotocol 27
4.1 Digestquery 27
4.2 CertificateChainread 27
4.3 Authenticationchallenge 27
4.4 Errorsandalerts 27
4.4.1 Invalidrequest 27
4.4.2 Unsupportedprotocolversion 28
4.4.3 Busy 28
4.4.4 Unspecified 28
5. Authenticationmessages 29
5.1 Authenticationmessageheader 29
5.2 Authenticationrequests 29
5.2.1 GET_DIGESTS 30
5.2.2 GET_CERTIFICATE 31
5.2.3 CHALLENGE 32
5.3 Authenticationresponses 32
5.3.1 DIGESTS 32
5.3.2 CERTIFICATE 34
5.3.3 CHALLENGE_AUTH 35
5.3.4 Error 37
6. Timingrequirements 39
6.1 PowerReceivertimingrequirements 39
6.2 PowerTransmittertimingrequirements 39
7. Protocolflowexamples 41
7.1 Simpleflow 42
7.2 Flowwithcaching 43
7.3 Flowwithcachingandrevocation 44
7.4 Challengefirstflow 45
8. Cryptographicexamples(informative) 47
8.1 X.509Certificatebasics 47
8.1.1 VerifyingtheECDSAsignatureofanX.509Certificate 47
8.2 DummyRootCACertificate 48
8.2.1 DummyRootCACertificate–DER-encoded 48
8.2.2 DummyRootCACertificate–hash 48
8.2.3 DummyRootCACertificate–data 49
8.2.4 VerificationoftheRootCACertificatesignature 49
8.3 ManufacturerCACertificateExample 50
8.3.1 ExampleManufacturerCACertificate—DER-encoded 52
8.3.2 ExampleManufacturerCACertificate-data 52
8.3.3 VerificationoftheManufacturerCACertificatesignature 53
8.4 ExampleProductUnitCertificates 53
8.4.1 Example1:maximumlengthProductUnitCertificate 53
8.4.2 Example2:typicallengthProductUnitCertificate 55

8.5 CertificateChainanddigestofcertificatesexample 57
8.5.1 Example1:maximumlengthCertificateChain 57
8.5.2 Example2:typicallengthCertificateChain 59
8.6 Authenticationexamples 59
8.6.1 Testofexample1,maximumlengthCertificateChain 59
8.6.2 Testofexample2,typicallengthCertificateChain 68
AnnexA: Sampledata 78
A.1 DummyRootCACertificateinPEMformat 78
A.2 DummyRootCACertificateinASN.1parseroutput 79
A.3 ManufacturerCACertificateinPEMFormat 80
A.4 ManufacturerCACertificateinASN.1parseroutput 81
A.5 ProductUnitCertificate,example1inPEMformat 82
A.6 ProductUnitCertificate,example1inASN.1parseroutput 83
A.7 ProductUnitCertificate,example2inPEMformat 84
A.8 ProductUnitCertificate,example2inASN.1parseroutput 85
AnnexB: BehaviourGuidelinesforQiPRxwhenaPTxFailstoAuthenticate 86
B.1 BPPPowerTransmitterProducts 86
B.2 LegacyEPPPowerTransmitterProducts 86
B.3 EPP5PowerTransmitterProducts 86
B.4 AuthenticationfailurewithPowerTransmitterProducts 86
B.4.1 Incorrectproductunitcertificate 86
AnnexC: ObjectIdentifiers(OID) 87

1. General
TheWirelessPowerConsortium(WPC)isaworldwideorganizationthataimstodevelopandpromoteglobalstandards
forwirelesspowertransferinvariousapplicationareas.Animportantapplicationareacomprisesflat-surfacedevices
suchasmobilephonesandchargersoperatingatpowerlevelsupto25W.
1.1 StructureoftheQi Specification
Generaldocuments
l
Introduction
l
Glossary,Acronyms,andSymbols
l
TechnicalSystemOverview
l
PowerProfiles
Systemdescriptiondocuments
l
Mechanical,Thermal,andUserInterface
l
PowerDelivery
l
CommunicationsPhysicalLayer
l
CommunicationsProtocol
l
ForeignObjectDetection
l
NFCTagProtection
l
AuthenticationProtocol
l
MPPCommunicationsProtocol
l
MPPMagneticsDesign
l
MPP PowerDelivery
l
MPP CommunicationsPhysicalLayer
l
MPP ForeignObjectDetection
l
MPP DesignGuidelines(Informative)
l
MagneticCovers
l
ActiveAlignmentSystem
l
ThermalManagementProtocol
1.2 Scope
TheQiSpecification,AuthenticationProtocol(thisdocument)definesthearchitectureandapplication-levelmessagingfor
theAuthenticationofaPowerTransmitterProductbyaPowerReceivertoensurethatthePowerTransmitterProductis
bothQicertifiedandtheproductofaregisteredmanufacturer.
1.3 Compliance
AllprovisionsintheQiSpecificationaremandatory,unlessspecificallyindicatedasrecommended,optional,note,
example,orinformative.VerbalexpressionofprovisionsinthisSpecificationfollowtherulesprovidedinISO/IEC
Directives,Part2.
Table1-Verbalformsforexpressionsofprovisions
Provision Verbalform
requirement “shall”or“shallnot”
recommendation “should”or“shouldnot”
permission “may”or“maynot”
capability “can”or“cannot”
1.4 References
Forundatedreferences,themostrecentlypublisheddocumentapplies.ThemostrecentWPCpublicationscanbe
downloadedfromhttp://www.wirelesspowerconsortium.com.

1.5 Conventions
1.5.1 Notationofnumbers
l
Realnumbersusethedigits0to9,adecimalpoint,andoptionallyanexponentialpart.
l
Integernumbersindecimalnotationusethedigits0to9.
l
Integernumbersinhexadecimalnotationusethehexadecimaldigits0to9andAtoF,andareprefixedby"0x"
unlessexplicitlyindicatedotherwise.
l
SinglebitvaluesusethewordsZEROandONE.
1.5.2 Tolerances
Unlessindicatedotherwise,allnumericvaluesintheQiSpecificationareexactlyasspecifiedanddonothaveany
impliedtolerance.
1.5.3 Fieldsinadatapacket
Anumericvaluestoredinafieldofadatapacketusesabig-endianformat.Bitsthataremoresignificantarestoredata
lowerbyteoffsetthanbitsthatarelesssignificant.Table2andFigure1provideexamplesoftheinterpretationofsuch
fields.
Table2-Exampleoffieldsinadatapacket(table)
b b b b b b b b
7 6 5 4 3 2 1 0
B (msb)
B 16-bitNumericDataField (lsb)
B OtherField
(msb)
B 16-bitNumericDataField (lsb)
Field
Figure1-Examplesoffieldsinadatapacket

1.5.4 Notationoftextstrings
TextstringsconsistofasequenceofprintableASCIIcharacters(i.e.intherangeof0x20to0x7E)enclosedindouble
quotes(").Textstringsarestoredinfieldsofdatastructureswiththefirstcharacterofthestringatthelowestbyte
offset,andarepaddedwithASCIINUL(0x00)characterstotheendofthefieldwherenecessary.
EXAMPLE: Thetextstring“WPC”isstoredinasix-bytefieldsasthesequenceofcharacters'W','P','C',NUL,NUL,and
NUL.Thetextstring“M:4D3A”isstoredinasix-bytefieldasthesequence'M',':','4','D','3',and'A'.
1.5.5 Short-handnotationfordatapackets
Inmanyinstances,theQiSpecificationreferstoadatapacketusingthefollowingshorthandnotation:
/
Inthisnotation,referstothedatapacket'smnemonicdefinedintheQiSpecification,Communications
Protocol,andreferstoaparticularvalueinafieldofthedatapacket.Thedefinitionsofthedatapacketsin
theQiSpecification,CommunicationsProtocol,listthemeaningsofthemodifiers.
Forexample,EPT/ccreferstoanEndPowerTransferdatapackethavingitsEndPowerTransfercodefieldsetto0x01.

2. Overview
TheQiSpecification,AuthenticationProtocol(thisdocument)definesaprotocolforaPowerReceivertoauthenticatea
PowerTransmitter.Inthiscontext,Authenticationisatamper-resistantmethodtoestablishandverifytheidentityof
thePowerTransmitter,enablingthePowerReceivertotrustthePowerTransmittertooperatewithintheboundsofthe
QiSpecification.ThisAuthenticationprotocolversion(AuthenticationProtocolversion1.0)makesuseofDataTransport
StreamsbetweenthePowerReceiverandPowerTransmitterasdefinedintheQiSpecification,CommunicationsProtocol.
Authenticationallowsanorganizationtosetandenforceapolicywithregardtoacceptableproducts.Thiswillpermit
usefulsecurityassurancesinrealworldsituations.Forexample,amobilephonemanufacturerconcernedaboutproduct
damageorsafetyhazardsresultingfromsubstandardwirelesschargingdevicescansetapolicylimitingthepower
drawnfromanuntrustedwirelesscharger.
ThisdocumentaimstobecloselyalignedwiththeUSBAuthenticationspecification,particularlyasitislikelythat
productswillexistinthemarketthatsupportboth.
Inadditiontothisdocument,theWPCManufacturerAgreementcoverslegalandimplementationrequirements,including
securestorageandhandlingofsecrets(AnnexA)andrevocationrulesandprocedure(AnnexB).
Forfurtherinformationortoobtainacopyofthisagreement,contact:
[e-mail].
2.1 References
Unlessspecifiedotherwise,allstandardsspecified,includingthosefromISO,ITU,andNISTrefertotheversionor
editionwhichismorerecent,asof1January2018.
2.1.1 ECDSA
l
ANSIX9.62-2005;PublicKeyCryptographyfortheFinancialServicesIndustry,TheEllipticCurveDigital
SignatureAlgorithm(ECDSA)(availableatwww.global.ihs.comorhttps://www.techstreet.com)
l
NIST-FIPS-186-4,DigitalSignatureStandard(DSS),Section6,FederalInformationProcessingStandards
Publication,July2013(availableat:http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
l
ISO/IEC14888-3Digitalsignatureswithappendix—Part3:Discretelogarithmbasedmechanisms(Clause6.6)
2.1.2 NISTP-256,secp-256r1
l
NIST-FIPS-186-4,DigitalSignatureStandard(DSS),AppendixD:RecommendedEllipticCurvesforFederal
GovernmentUse,FederalInformationProcessingStandardsPublication,July2013(availableat:
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
l
ISO/IEC15946Cryptographictechniquesbasedonellipticcurves(NISTP-256isincludedasexample)
NOTE:TheISO/IEC15946seriestreatsellipticcurvesdifferentlyfromFIPS186-4.ISO/IEC15946-5isaboutellipticcurve
generation.Thatis,basedonthemethodinpart5,eachapplicationandimplementationcangenerateitsowncurves
touse.Inotherwords,therearenoISO/IECrecommendedcurves.P-256isconsideredanexampleinISO/IEC15946.
Inaddition,EllipticCurvesignaturesandkeyestablishmentschemeshavebeenmovedtoISO/IEC14888andISO/IEC
11770respectively,togetherwithotherdiscrete-logbasedmechanisms.Testvectors(examples)usingP-256are
includedforeachofthosemechanisms.
2.1.3 SEC1
l
CerticomCorp.,StandardsforEfficientCryptographyGroup(SECG),SEC1:“EllipticCurveCryptography,”Version
1.0,September2000(availableat:https://www.secg.org/SEC1-Ver-1.0.pdf)

2.1.4 SEC2
l
CerticomCorp.,StandardsforEfficientCryptographyGroup(SECG),SEC2:“RecommendedEllipticCurveDomain
Parameters,”Version2.0,January2010(availableat:
http://www.secg.org/sec2-v2.pdf)
2.1.5 SHA-256
l
NIST-FIPS-180-4(availableat:http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf)
l
ISO/IEC10118-3Hash-functions—Part3:Dedicatedhash-functions(Clause10)
2.1.6 SP800-90A
l
NIST-SP-800-90ARevision1(availableat:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf.)
2.1.7 SP800-90B
l
NIST-SP-800-90B(availableat:https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf)
2.1.8 USBAuthentication
l
UniversalSerialBusType-C™AuthenticationSpecification
(availableathttp://www.usb.org/developers/docs/aspartoftheUSB3.2Specificationdownloadpackage)
2.1.9 X.509
l
ITU-T-X.509,Informationtechnology-OpenSystemsInterconnection-TheDirectory:Public-keyandattribute
Certificateframeworks(availableat:https://www.itu.int/rec/T-REC-X.509/en)
l
ISO/IEC9594-8,Informationtechnology—OpenSystemsInterconnection—TheDirectory—Part8:TheDirectory:
Public-keyandattributeCertificateframeworks(availableat:https://www.iso.org/standard/80325.html)
l
IETF-RFC-5280:InternetX.509PublicKeyInfrastructureCertificateandCertificateRevocationList(CRL)Profile
2.2 Cryptographicmethods
Thisspecificationtargetsa128-bitsecuritylevelforallcryptographicprimitives.Thecryptographicmethodsusedby
thisspecificationareshowninTable4inSection3.2,Certificates.
2.2.1 Randomnumbergenerators
Thegenerationofcryptographickeysandthecryptographicprotocolexchangesrelyoncryptographicqualityrandom
numbers.Randomnumbersaredefinedasnumbersthataredistinguishablefromrandombynoalgorithmwithan
algorithmiccomplexityoflessthanO(2 ).
TheoutputofaNISTSP800-90A-compliantPRNGseededwitha256-bitfullSP800-90Bentropyvalueissufficientto
meetthisstandard.
2.3 Securityoverview
SecurityoftheAuthenticationprotocoldependsontheprotectionofprivatekeys,andthatprotectionissupportedby
securityevaluation.
2.3.1 Methodology
ThisspecificationdefinesaCertificate-basedmethodforAuthenticationthatallowsaPowerReceivertoauthenticatea
PowerTransmitterand,bypolicy,choosehowtointeractwiththatPowerTransmitter.Forexample,aPowerReceiver
maychoosenottousethefulladvertisedcapabilitiesofanunauthenticatedPowerTransmitter.
2.3.2 Periodicre-Authentication
ThePowerReceivercanoptionallyperformperiodicre-AuthenticationstoverifythatanauthenticatedPower
Transmitterhasnotbeenreplacedbyadifferentone.
2.4 Impacttoexistingecosystem
TheimpacttoexistingPowerTransmitterProductsdependslargelyonindividualPolicydecisionsregardinglegacy
PowerTransmitters(i.e.PowerTransmittersthatpredatethisspecification).Forexample,aPowerReceiverwitha
PolicythatallowsfullfunctioningoflegacyPowerTransmitterswillhaveaminimalimpactonthecurrentecosystem,
whileaPowerReceiverwithaPolicythatlimitsorrefusestousefunctionalitiesexposedbyalegacyPowerTransmitter
willhaveamoresignificantimpact.
2.5 Supportforrevocation
IfthePowerReceiversupportsAuthenticationfunctionality,thenthePowerReceivershouldsupportRevocation.
RevocationListsarenormallyupdatedoffline,e.g.aspartofasoftwareorfirmwareupdateorduringProduct
manufacturing.Manufacturersarenotrequiredtoprovideon-linemaintenanceofRevocationListsortomake
RevocationListsfield-updatableintheirProducts,however,thePowerReceivershouldfrequentlyupdateitsrevocation
listandnotonlyduringfirmwareupdates.ForsomePowerReceiverProductswithInternetconnectivity(e.g.
smartphones),frequentRevocationListupdatesshouldberelativelyeasy.OtherPowerReceiverProductswithoutdirect
Internetconnectivity,suchasfitnesstrackers,maynotbeabletoupdatetheirRevocationListasfrequently,but
manufacturersshouldconsiderwaystokeeptheRevocationListcurrentintheirproductdesigns.
NOTE:SupportforupdatableRevocationListsimpliesfield-updatablenon-volatilememory.
NOTE:TheWPCAuthenticationLicenseAdministrator(WPC-ALA)willissueRevocationListsfromtimetotime.Theformatof
RevocationListsandhowtheyarecommunicatedisoutsidethescopeofthisspecification.

3. Certificatesandprivatekeys
3.1 CertificateChains
TherequirementsinthissectionapplytoCertificateChainsthatarepopulatedinslots0and1.ThePowerTransmitter
ProductmanufacturerdeterminestherequirementsforCertificatesthatarepopulatedinslots2and3.Forfurther
informationaboutslots,seeSection3.3,CertificateChainslots.
ACertificateChainconsistsofthreeCertificates;seeTable3.ThefirstCertificateinthechainistheRootCertificate
identifyingtheWPCRootCertificateAuthority.Itisaself-signedCertificate(i.e.signedbytheWPCRootCertificate
Authority).Asanoptimization,theCertificateChaincontainsahashoftheRootCertificateratherthantheRoot
Certificateitself.ThesecondCertificateisaManufacturerCACertificateidentifyingtheproduct'smanufacturer.Itis
signedbytheWPCRootCertificateAuthority.ThelastCertificateinthechainisaProductUnitCertificateidentifyingthe
individualPowerTransmitterproduct.ItissignedbytheManufacturerCertificateAuthority.
Inadditiontoidentificationdata,theManufacturerCACertificatecontainsapublickeyforverifyingtheauthenticityof
theProductUnitCertificate.TheProductUnitCertificatecontainsapublickeyforverifyingtheauthenticityofthePower
TransmitterProductUnit.SeeSection4,Authenticationprotocol,fordetails.
ThefollowingrequirementsapplytotheCertificatesinaCertificateChain.
l
EachProductUnitCertificateshallidentifyauniquePowerTransmitterProductUnitbyusing,forexample,the
productunit'sRSIDnumber(wpc-qi-rsid).
l
EachPowerTransmitterProductUnitshallhaveauniquepublickey.
l
ProductUnitCertificatescontainedindifferentslotsofthesamePowerTransmitterProductUnitmaycontainthe
sameidentityandpublickey,providedthatthisdoesnotintroduceasecurityvulnerability.
l
AmanufacturermayhavemultipleManufacturerCACertificatestoidentify,forexample,differentproduction
facilitiesorproductfamilies.EachoftheseManufacturerCACertificatesshallcontainauniquepublickeyrelating
toauniqueprivatekey.
NOTE:UsingmultipleManufacturerCACertificatesisencouragedtopartitionvolumesofproductunitstolimitthecollateral
impactcausedintheeventthataManufacturerCACertificateisrevoked(collateralimpactofrevokingallproduct
unitssignedbythatManufacturerCACertificate).
l
AmanufacturershallusetheprivatekeyassociatedwithaManufacturerCACertificatetosignProductUnit
Certificates.
l
TheWPCRootCertificateAuthorityshallensurethatallManufacturerCACertificatescontainuniquepublickeys.
TheCertificateChainspopulatedinslots0and1shalluseX.509Certificates.SeeSection3.3,CertificateChainslots,for
furtherinformationaboutslots0and1.

Table3-CertificateChain(X.509Certificates)
b b b b b b b b
7 6 5 4 3 2 1 0
B.B msb Length
0 1
lsb
B.B RootCertificateHash(lengthN_RH)
2 (1+N_RH)
B .B ManufacturerCACertificate(lengthN_MC)
(2+N_RH) (1+N_RH+N_
MC)
B . ProductUnitCertificate(lengthN_PUC)
(2+N_RH+N_MC)
B
(1+N_RH+N_MC+N_PUC)
NOTE:TheRootCertificateisnotincludedinthechain,onlyitshashisincludedinthechain.
LengthThelengthisthetotalnumberofbytesintheCertificateChainincludingtheLengthfield.
RootCertificateHashASHA-256hashoftheRootCertificate.ThelengthofN_RHis32bytes.SeeSection2,Overview.
ManufacturerCACertificateThisCertificateidentifiesthemanufacturer.
ProductUnitCertificateThisCertificateidentifiestheindividualproductunit.
3.2 Certificates
3.2.1 FormatofCertificates
AllCertificatesshalluse:
l
theX.509v3ASN.1structure,
l
binaryDERencodingforASN.1,and
l
thecryptographicmethodslistedinTable4.
Table4-Summaryofcryptographicmethods
Method Use
X.509v3,DERencoding Certificateformat
ECDSAusingtheNISTP256,secp256r1 DigitalsigningofCertificatesand
curve,uncompressedpointORcompressed AuthenticationMessages
pointformatasspecifiedbySEC1(see
Section2,Overview)
SHA-256 Hashalgorithm,usedintheECDSA
calculationandincreatingdigestsof
CertificatesandCertificateChains.
ThefurtherdescriptionoftheCertificateformatassumesthatthereaderisfamiliarwithX.509v3Certificate
terminology.
NOTE:Certificatesandthefields,attributes,andextensionsdefinedthereinareBigEndian.

ProductunitCertificatesshallnotexceedMaxProdCertSizeinlength.AManufacturerCACertificateshallnotexceed
MaxManufacturerCertSizeinlength.
3.2.1.1 Textualformat
AlltextualASN.1objectscontainedwithinX.509Certificates,includingDirectoryString,GeneralName,andDisplayText,
shallbespecifiedasaUTF8String.Thelengthofanytextualobjectshallnotexceed64bytesexcludingtheDERtypeand
DERlengthencoding.
3.2.1.2 AttributesandExtensions
Whereapplicable,theObjectIdentifier(OID)isprovided.
BasicConstraints(OID2.5.29.19)
ManufacturerCACertificatescontainthisextension.(Theextensionismarkedascritical,itscAcomponentissettotrue,
anditspathLenConstraintcomponentsettozero).ProductUnitCertificatesdonotcontainthisextension.
Validity
ThenotBeforeandnotAfterfieldsindicatethetimeintervalduringwhichinformationregardingaCertificate'svalidityis
maintained.ForProductUnits,thevaliditytimesshouldbeignored.
CertificatenotBeforeandnotAftervaliditytimesshallbespecifiedusingASN.1GeneralizedTimeforanyyear,orASN.1
UTCTimeforyearspriorto2050.
ForaManufacturerCACertificateitisrecommendedthatthenotBeforefieldbe"19700101000000Z"(for00:00on01-
Jan-1970UTC,whichisPOSIXepochtime).ItisrecommendedthatthenotAfterfieldbe"99991231235959Z"(for
23:59:59on31-Dec-9999UTC,whichisusedforanunknownexpirationtimeasdefinedinIETF-RFC-5280,Section
4.1.2.5).UseoftherecommendednotBeforeandnotAftervalueswillmaximizecompatibilitywithCertificateprocessing
stacks.
Qipolicyextension(wpc-qi-policy)
TheWPCQipolicyextensionisacustomManufacturerCACertificateextensionforusewithproductscomplianttothis
specification.Thevalueisabinaryobjectandisreservedinthisversionofthespecification.Theobjectidentifiervalue
ofwpc-qi-policyislistedinAnnexC .
ThebinaryobjectisencodedasanASN.1DEROCTETSTRINGwithafixedsizeofQiPolicySizebytes.
ManufacturerCACertificatesshallcontainthisextension.ProductUnitCertificatesshallnotcontainthisextension.
Bitszeroandone(b0,b1)shallalwaysbeset(i.e.twoleastsignificantbits,0x00000003)
NOTE:0x00000000isaninvalidvalue.
NOTE:TheWPCRootCAbegansettingbitone(b1)forallManufacturerCAcertificatesissuedafter31stDecember2024.The
requirementforbitonetobesetmeansthatproductscompliantwiththisversionofthespecificationhaveaManufacturerCA
certificateissuedafterthatdate.
QiRSIDextension(wpc-qi-rsid)
TheWPCQirevocationsequentialidentifier(RSID)extensionisacustomProductUnitCertificateextensionforusewith
productscomplianttothisspecification.Thevalueisabinaryobjectandisprovidedtostoreasequentialidentifier
uniquetoeachproductunitthatenablesrange-basedrevocationofbatches.Theobjectidentifiervalueofwpc-qi-rsidis
listedinAnnexC .
ThebinaryobjectisDERencodedasanASN.1OCTETSTRINGwithamaximumsizeofMaxQiRSIDSizebytes.TheRSID
valueisuniquetoeachproductunit,fromaminimumof1uptoMaxQiRSIDSizebytes.
ProductUnitCertificatesshallcontainthisextension.
ManufacturerCACertificatesshallnotcontainthisextension.

ASN.1schemaforWPCObjectidentifiers
TheASN.1modulebelowdefinestheWPCadministeredobjectidentifiersandtheschemaforthecertificateextensions
usedforWPCQiauthentication.
-- WPC OID allocation
wpc INTEGER ::= 148
id-wpc OBJECT IDENTIFIER
::= {joint-iso-ccitt(2) international-organizations(23) wpc}
-- Qi Authentication certificate extensions
qiAuth INTEGER ::= 1
id-wpc-qiAuth OBJECT IDENTIFIER ::= {id-wpc qiAuth}
policy INTEGER ::= 1
id-wpc-qiAuth-policy OBJECT IDENTIFIER ::= {id-wpc-qiAuth policy}
rsid INTEGER ::= 2
id-wpc-qiAuth-rsid OBJECT IDENTIFIER ::= {id-wpc-qiAuth rsid}
-- WPC Qi Authentication size constants
wpcQiAuthPolicySize INTEGER ::= 4
wpcQiAuthRsidMaxSize INTEGER ::= 9
-- WPC Qi Authentication certificate extension schema
policy ::= OCTET STRING (SIZE (wpcQiAuthPolicySize))
rsid ::= OCTET STRING (SIZE (1…wpcQiAuthRsidMaxSize))

3.2.1.3 ManufacturerCACertificate
AManufacturerCACertificateusestheASN.1structuredefinedinRec.ITU-TX.509(10/2016),Section 7.2Public-Key
Certificate.
TheTBSCertificatecomponentofaManufacturerCACertificateonlyimplementstheASN.1fieldsshowninTable5.
Table5-CertificateprofileforaManufacturerCACertificate
TBS Certificate
Field OID Datatype Value Example
Version INTEGER 0x02 0x02
{=X.509v3}
SerialNumber INTEGER Aunique1-to 0x011020304050
72-bitpositive 6070
integervalue
NOTE:Themaximumlengthof9bytesreferstothe“baseband”originalvalue,before
DERencoding.Theencodedvaluecanhaveanadditionalzerobyteifthetopbit
oftheoriginalvalueisset.Beawarethatthiscanbe10 bytesafterencoding.
NOTE:UnderDER,anintegervalueisalwaysencodedinthesmallestpossiblenumber
ofoctets.Avaluebetween1and127wouldthusbeencodedinonebyte.
signature 1.2.840.10045.4.3. N/A "WPCCA1"
{ecdsa-with-
SHA256}
issuer 2.5.4.3 UTF8String “WPCCA“+one 2000-01-01
{CommonName} charactersuffix 00:00:00
denotingdif-
ferentrootCA
instances
validity.notBefore Either Anyvalue 9999-12-31
Gen- (notusedby 23:59:59
eralizedTimefor PRx)
anyyear,or
UTCTimefor
yearspriorto
validity.notAfter Either Anyvalue “CACA-1A”
GeneralizedTime (notusedby
foranyyear,or PRx)
UTCTimefor
yearspriorto
TBS Certificate
Field OID Datatype Value Example
subject 2.5.4.3 UTF8String 7bytestring
{CommonName} consistingof:
• four
upper-case
characters
containinga
PTMChex
value
• one
character
containinga
dash
• two
arbitrary
alpha-
numeric
characters
subjectPublicKeyInfo.algorithm 1.2.840.10045.2.1 N/A
{ecPublicKey}
1.2.840.10045.3.1.- N/A
(i)
{secp256r1}
subjectPublicKeyInfo.subjectPublicK BITSTRING (PublicKey 0x04:64:68:34:24:4e
:1a:37:b2:f8:3a:d5:3
ey value;option-
0:68:73:8a:65:9b:e2:
allymayuse
a6:d2:c6:f3:c9:3f:90:
compressed
5e:8c:7d:a3:59:79:2
pointrep-
(ii) 7:6b:a7:fb:d4:30:83:
resentation)
42:a9:90:a7:c1:92:9
0:
98:20:7d:90:77:f2:9
7:f3:f5:3a:77:25:01:3
c:55:44:19:e8:4a
Extensions.1 2.5.29.19 N/A
{basicConstraints}
Extensions.1. BOOLEAN TRUE TRUE
critical
Extensions.1. BOOLEAN TRUE TRUE
extnValue.cA
(i)
1.2.840.10045referstothenamedcurvedefinedequivalentlybythreeorganizationsas:
NIST(FIPS186-4):"P-256",SECG(SEC2):"secp256r1",andIETF(RFC3279):"prime256v1"
(ii)
ACertificateverifiercanunambiguouslydistinguishcompressedfromuncompressedpointrepresentationsby
evaluatingthevalueofthefirstbyte(0x02and0x03forcompressedpointsand0x04foranuncompressedpoint).

TBS Certificate
Field OID Datatype Value Example
Extensions.1. INTEGER 0 0x00
extnValue.pathLenConstraint
Extensions.2 2.23.148.1.1 N/A
{wpc-qiAuth-
policy}
Extensions.2. BOOLEAN TRUE TRUE
critical
Extensions.2. OCTET 4octets(bytes) 0x00000003
extnValue STRING reservedfor
futureuse
3.2.1.4 ProductUnitCertificate
AProductUnitCertificateusestheASN.1structuredefinedinRec.ITU-TX.509(10/2016),Section 7.2Public-Key
Certificate.
TheTBSCertificatecomponentofaProductUnitCertificateonlyimplementstheASN.1fieldsshowninTable6.
Table6-CertificateprofileforaProductUnitCertificate
TBSCertificate
Field OID Datatype Value Example
Version INTEGER 0x02 0x02
{=X.509v3}
serialNumber INTEGER Aunique1-to72-bit 0x0110203040506070
positiveintegervalue
NOTE: Themaximumlengthof9bytesreferstothe“baseband”originalvalue,beforeDERencoding.The
encodedvaluecanhaveanadditionalzerobyteifthetopbitoftheoriginalvalueisset.Beaware
thatthiscanbe10 bytesafterencoding.
NOTE:UnderDER,anintegervalueisalwaysencodedinthesmallestpossiblenumberofoctets.Avalue
between1and127wouldthusbeencodedinonebyte.
signature 1.2.840.10045.4.3.2 N/A
{ecdsa-with-SHA256}
issuer 2.5.4.3 UTF8String 7bytesstring "CACA-1A"
{CommonName}
consistingof:
• Fourupper-case
characterscontaining
aPTMChexvalue
• onecharacter
containingadash
• twoarbitrary
alpha-numeric
characters
• thismatches
exactlybyte-for-byte
thevaluefromthe
ManufacturerCA
CertificateSubject
commonname
validity.notBefore EitherGen- Shouldusethecurrent 2020-10-0100:00:00
eralizedTime timewhenissuingthe
foranyyear, Certificate(notusedby
orUTCTime PRx)
foryears
priorto2050
TBSCertificate
Field OID Datatype Value Example
validity.notAfter EitherGen- Shoulduseoneday 2020-10-0200:00:00
eralizedTime after
foranyyear, NotBefore(notusedby
orUTCTime PRx)
foryears
priorto2050
subject.attribute1 2.5.4.3{Common UTF8String Stringconsistingof: "006386-Model5"
Name} • TheQiIDencoded
asasix-character
textstring,leftpadded
withUTF-8“0”(zero)
charactersas
necessary.For
example,theSubject
IDforaproductwith
QiID6386isencoded
as“006386“
• Optionallyone
charactercontaininga
dashfollowedbyup
to28arbitrary
characterstoimprove
readabilitye.g.
productname
subject.attribute2 2.5.4.92{tagAFI} OCTET Optional:upto32arbit- 0x20200923F4
{optional} STRING rarybytes
subject.attribute3 0.9.2342.1920 UTF8String Optional:upto32arbit- “SEPT-23“
{optional} 0300.100.1.1 rarycharacters
{userId}
subjectPublic 1.2.840.10045.2.1 N/A
KeyInfo.algorithm {ecPublicKey}
(i)
1.2.840.10045.3.1.7 N/A
{secp256r1}
(i)
1.2.840.10045referstothenamedcurvedefinedequivalentlybythreeorganizationsas:
NIST(FIPS186-4):"P-256"
SECG(SEC2):"secp256r1"
IETF(RFC3279):"prime256v1"
TBSCertificate
Field OID Datatype Value Example
subjectPublic BITSTRING (PublicKeyvalue; 0x04:64:68:34:24:4e:1a:37:
KeyInfo.subject optionallymayusecom- b2:f8:3a:d5:30:68:73:8a:65:
PublicKey pressedpointrep- 9b:e2:a6:d2:c6:f3:c9:3f:90:
(i)
resentation) 5e:8c:7d:a3:59:79:27:6b:a7:
fb:d4:30:83:42:a9:90:a7:c1:
92:90:98:20:7d:90:77:f2:97:
f3:f5:3a:77:25:01:3c:55:44:
19:e8:4a
Extensions.1 2.23.148.1.2{wpc- N/A
qiAuthrsid
Extensions.1.crit- BOOLEAN TRUE TRUE
ical
Extensions.1.ext- OCTET RSID 0x0000000000
nValue STRING
(i)
ACertificateverifiercanunambiguouslydistinguishcompressedfromuncompressedpointrepresentationsby
evaluatingthevalueofthefirstbyte(0x02and0x03forcompressedpointsand0x04foranuncompressedpoint).

3.2.1.5 RootCACertificate
ARootCACertificateusestheASN.1structuredefinedinRec.ITU-TX.509(10/2016),Section 7.2Public-KeyCertificate.
TheTBSCertificatecomponentofaRootCertificateonlyimplementstheASN.1fieldsshowninTable7
Table7-CertificateprofileforaRootCACertificate
TBSCertificate
Field OID DataType Value Example
Version INTEGER 0x02 0x02
{=X.509v3}
serialNumber INTEGER Auniquenum- 0x0110203040506070
berupto9
bytesinlength
signature 1.2.840.1004- N/A
5.4.3.2
{ecdsa-with-
SHA256}
issuer 2.5.4.3{Com- UTF8String "WPCCA"+one "WPCCA1"
monName} charactersuf-
fixdenotingdif-
ferentrootCA
instances
valid- Either Anyvalue(not 2000-01-0100:00:00
ity.notBefore Gen- usedbyPRx)
eralized
Timefor
anyyear,
or
UTCTime
foryears
priorto
validity.notAfter EitherGen- Anyvalue(not 9999-12-3123:59:59
eralized usedbyPRx)
Timefor
anyyear,
or
UTCTime
foryears
priorto
subject 2.5.4.3 UTF8String Sameas "WPCCA1"
{Common
"issuer"
Name}
TBSCertificate
Field OID DataType Value Example
subjectPublic 1.2.840.1004 N/A
KeyInfo.al- 5.
2.1
gorithm
{ecPublicKey}
1.2.840.1004 N/A
5.
3.1.7
{secp256r1}
subjectPublic BIT (PublicKey 0x04:64:68:34:24:4e:1a:37:b2:
KeyInfo.subject STRING value;option- f8:3a:d5:30:68:73:8a:65:9b:e2:
PublicKey allymayuse a6:d2:c6:f3:c9:3f:90:5e:8c:
compressed 7d:a3:59:79:27:6b:a7:fb:d4:30:83:
pointrep- 42:a9:90:a7:c1:92:0:98:20:7d:90:77:f2:97:f3:f5:3a:
resentation)* 77:25:01
:3c:55:44:19:e8:4a
Extensions.1 2.5.29.19 N/A
{basicConstrai
n
ts}
Extensions.1. BOOLEAN TRUE TRUE
critical
Extensions.1.ext- BOOLEAN TRUE TRUE
nValue.cA
Extensions.1.ext- notpresent N/A N/A N/A
nValue.
pathLenCon-
straint
*ACertificateverifiercanunambiguouslydistinguishcompressedfromuncompressedpointrepresentationsby
evaluatingthevalueofthefirstbyte(0x02and0x03forcompressedpointsand0x04foranuncompressedpoint).
3.2.1.6 Additionalattributesandextensions
AdditionalCertificateattributesandextensionsdefinedinX.509v3arenotallowedinaManufacturerCACertificateor
inaProductUnitCACertificate.
3.2.1.7 Constraints
l
QiPolicySize=0x4bytes
l
MaxQiRSIDSize=0x9bytes
l
MaxManufacturerCertSize=0x200bytes
l
MaxProdCertSize=0x200bytes
3.3 CertificateChainslots
CertificateChainsresideinpositionscalledslots.EachslotshalleitherbeemptyorcontainonecompleteCertificate
Chain.APowerTransmittershallnotcontainmorethan4slots.Slot0andslot1(optional)shallonlybeusedfor
CertificateChainsrootedwithaWPCRootCertificateandshallnotcontainanyotherCertificateChains.The

manufacturermayuseSlots2and3foranyadditionalCertificateChains.Ifused,slots2and3shallbepopulatedin
orderstartingwithslot2.
Table8-CertificateChainslots
Slot# Usage
0 Mandatory;useonlyforCertificateChainrootedwithaWPCRootCertificate
1 Optional;useonlyforCertificateChainrootedwithaWPCRootCertificate
2 Optional;additionalCertificateChainifneededbythemanufacturer
3 Optional;additionalCertificateChainifneededbythemanufacturer
Manufacturer-dependentCertificateChainsdonotneedtobestructuredasdefinedinTable3.Forexample,theymaybe
inanX.509v3formatwithASN.1DERencoding,and/ortheymaybesignedinamanufacturer-dependentmanner.
Manufacturer-dependentCertificateChainsthatshareapublic/privatekeypairwithaCertificateChaininoneormore
ofslots0and1shallbeconstructedtoprovideatleastthesamelevelofsecuritytothepublic/privatekeypairasis
requiredfortheCertificateChainsstoredinslots0and1.Protectionformanufacturer-dependentCertificateChainsand
theformatsandprotocoltheyuseshallmatchorexceedtheprotectionforCertificateChains,formats,andprotocols
definedintheQiSpecification,AuthenticationProtocol(thisdocument)andstoredinslots0and1.
3.3.1 Provisioning
ProvisioningistheprocessbywhichaPowerTransmitterprivatekeyacquiresoneormoreCertificateChains.This
procedureisoutsidethescopeoftheQiSpecification.
3.4 PowerTransmitterprivatekeys
EachCertificateChaininaPowerTransmittercorrespondstoaPowerTransmitterprivatekeywhosecorresponding
publickeyiscertifiedintheProductUnitCertificateoftheslotassociatedwiththeCertificateChain.ThePower
Transmittershallhaveaccesstothatprivatekey.ThePowerTransmittershallstoreprivatekeysinamannerthat
adequatelyprotectstheconfidentialityofthekeyasoutlinedinAnnexAoftheWPCManufacturerAgreement.
AManufacturershallnotuseaprivatekeyassociatedwithonePowerTransmitterProductUnitinanyotherPower
TransmitterProductUnitorManufacturerCACertificate.
3.5 Otherprivatekeys
EachManufacturerCACertificateisassociatedwithauniquepublic/privatekeypair.Theprivatekeyassociatedwitha
ManufacturerCACertificateisusedforsigningthenextCertificateinaCertificateChain.Manufacturersshallgenerate,
provision,andstoreprivatekeysinamannerthatadequatelyprotectstheconfidentialityofthekey.Requirementsare
specifiedinAnnexAoftheAuthorizedManufacturerandMCSPagreements.
AManufacturershallnotuseaprivatekeyassociatedwithoneManufacturerCACertificateinanyotherManufacturer
CACertificateorProductUnitCertificate.

4. Authenticationprotocol
ThePowerReceivercanperformthreeoperations:
l
QueryaPowerTransmitterforCertificateChaindigests
l
ReadaCertificateChainfromaPowerTransmitter
l
ChallengeaPowerTransmitterinordertoverifyitsauthenticity
APowerReceivermayinitiateasmanyorasfewoftheseoperationsasareneededtoachievethedesired
Authenticationlatency.Inaddition,aPowerReceivermayinitiatetheoperationsinanyorder.Forexample,aPower
ReceivermayfirstchallengeaPowerTransmitter,andtheninitiateaCertificateChainreadiftheessentialinformation
fromatargetCertificateChainisnotalreadycached.Section7,Protocolflowexamples,providessomeflowexamples.
4.1 Digestquery
ToqueryaPowerTransmitterforCertificateChaindigests,aPowerReceiversendsaGET_DIGESTSrequestasdefined
inSection5.2.1,GET_DIGESTS.Ifanerrorconditionisencountered,thePowerTransmittershallrespondwiththe
appropriateERRORresponseasdefinedinSection5.3.4,Error.Otherwise,thePowerTransmittershallrespondwitha
DIGESTSresponseasdefinedinSection5.3.1,DIGESTS.AfterreceivingaDIGESTSresponse,thePowerReceivercan
checktoseeifithasanyofthePowerTransmitter'sCertificateChainscached.ThisallowsthePowerReceiverto
potentiallyskipreadingaCertificateChainandthussavetime.
4.2 CertificateChainread
ToreadaCertificateChain,orportionthereof,aPowerReceivershallsendaGET_CERTIFICATErequestasdefinedin
Section5.2.2,GET_CERTIFICATE.
IfaPowerTransmitterreceivesaGET_CERTIFICATErequestthattargetsanoffsetthatisoutsidetheCertificateChain
(i.e.offset>length)orattemptstoreadbeyondthelengthofthetargetCertificateChain(i.e.(offset+length)>
CertificateChainlength),thenthePowerTransmittershallreturnanERRORresponseofINVALID_REQUEST.
ThePowerTransmittershallrespondtoerrorconditionswiththeappropriateERRORresponseasdefinedinSection
5.3.4,Error.Otherwise,thePowerTransmittershallrespondwithaCERTIFICATEresponseasdescribedinSection5.3.2,
CERTIFICATE.
4.3 Authenticationchallenge
TochallengeaPowerTransmitter,thePowerReceiversendsaCHALLENGErequestasdefinedinSection5.2.3,
CHALLENGE.Ifanerrorconditionisencountered,thePowerTransmittershallrespondwiththeappropriateERROR
responseasdefinedinSection5.3.4,Error.Otherwise,thePowerTransmittershallrespondwithaCHALLENGE_AUTH
responseasdescribedinSection5.3.3,CHALLENGE_AUTH.
NOTE:APowerReceiverthatsupportsAuthenticationProtocolVersionsgreaterthan1shouldensurethattheversionofthe
CHALLENGErequestandtheversionoftheresponsematch.Thepurposeofthisistoresistadowngradeattack.
4.4 Errorsandalerts
4.4.1 Invalidrequest
IfaPowerTransmitterreceivesanAuthenticationrequestwithoneormoreinvalidfields,itshallrespondtothat
AuthenticationrequestwithanERRORresponseofINVALID_REQUESTasdescribedinSection5.3.4,Error.

4.4.2 Unsupportedprotocolversion
IfaPowerTransmitterreceivesanAuthenticationrequestthatcontainsanunsupportedAuthenticationProtocolVersion
intheQiAuthenticationProtocolVersionfield,itshallrespondtothatAuthenticationrequestwithanERRORresponse
ofUNSUPPORTED_PROTOCOLthathastheAuthenticationProtocolVersionsettothemaximumAuthenticationProtocol
VersionitsupportsandtheErrorDatafieldalsosettothemaximumAuthenticationProtocolVersionitsupportsas
describedinSection5.3.4,Error.
4.4.3 Busy
IfaPowerTransmitterreceivesanAuthenticationrequestbutisunabletomeetthetimingrequirementslistedin
Section6,Timingrequirements,itshallrespondtothatAuthenticationrequestwithanERRORresponseofBUSYas
describedinSection5.3.4,Error,withintherequiredresponsetime.
4.4.4 Unspecified
IfaPowerTransmitter,uponreceivinganAuthenticationrequest,encountersanerrorthatisnotcoveredbythe
conditionsabove,itshallrespondtothatAuthenticationrequestwithanERRORresponseofUNSPECIFIEDasdescribed
inSection5.3.4,Error.
5. Authenticationmessages
AuthenticationmessagesareusedtoconveyinformationrelatedtoAuthentication.NeitheraPowerReceivernora
PowerTransmittershalladdanypaddingafteranAuthenticationmessage,i.e.thefirstbyteoftheAuthentication
messageshallbethefirstbyteofthedatatransportstreamandthelastbyteoftheAuthenticationmessageshallbethe
lastbyteofthedatatransportstream.
TherearetwotypesofAuthenticationmessages:AuthenticationrequestsandAuthenticationresponses.Authentication
requestsaredefinedinSection5.2,Authenticationrequests.AuthenticationresponsesaredefinedinSection5.3,
Authenticationresponses.
5.1 Authenticationmessageheader
AllAuthenticationmessagesstartwithaone-byteheader,whichshallhavetheformatshowninTable9.Theheader
maybefollowedbyapayload,asdefinedinSection5.2,Authenticationrequests,andSection5.3,Authentication
responses.
Table9-Authenticationmessageheader
b b b b b b b b
7 6 5 4 3 2 1 0
B AuthenticationProtocolVersion MessageType
AuthenticationProtocolVersionThisfieldidentifieswhichversionoftheAuthenticationSpecificationisbeingused.
Table10showsthevalidvaluesforthisfield.AProductshallnotuseanAuthenticationProtocolVersionvalue
correspondingtoaspecificationrevisionthatitdoesnotsupport.
Table10-AuthenticationProtocolVersion1.0
Name Value Meaning
Reserved 0x0 Reservedvalue
V1.0 0x1 AuthenticationProtocolVersion1.0
Reserved 0x2-0xF Reservedvalue
ThePowerReceivershallindicatethemaximumprotocolversionthatitsupportsintheAuthenticationProtocolVersion
fieldofthefirstAuthenticationrequestthatitsendstothePowerTransmitteronanewconnection.IfthePower
ReceiverreceivesanERRORresponseofUNSUPPORTED_PROTOCOL,itshallusetheversionindicatedintheErrorData
fieldoftheERRORresponseinallsubsequentAuthenticationrequests.IfaPowerTransmitterreceivesan
AuthenticationrequestthatcontainsanAuthenticationProtocolVersionintheAuthenticationProtocolVersionfieldthat
islowerthanthehighestversionitsupports,itshallusethelowerversioninallAuthenticationresponses.
Inallcases,theformatofthemessageshallmatchthatspecifiedfortheversionoftheAuthenticationProtocolVersion
givenintheAuthenticationProtocolVersionfield.
MessageTypeThisfieldidentifiesAuthenticationMessagetypefromoneofthevaluesinTable11(authentication
requests)orTable15(authenticationresponses).
5.2 Authenticationrequests
AuthenticationrequestsareusedbyaPowerReceivertosendacommandtoaPowerTransmitterand/ortoretrieve
data.AuthenticationrequesttypesarelistedinTable11.

APowerReceivershallnotsendanotherAuthenticationrequestuntilithaseitherreceivedaresponseforortimedout
thepreviously-sentAuthenticationrequest.
Table11-Authenticationrequests
Value Description
0x0-0x7 UsedforAuthenticationresponses
0x8 Reserved
0x9 GET_DIGESTS
0xA GET_CERTIFICATE
0xB CHALLENGE
0xC.0xF Reserved
5.2.1 GET_DIGESTS
ThisrequestisusedtoretrieveCertificateChaindigests.ThePowerReceivermayrequestanynumberofdigestsata
time.TheformatforaGET_DIGESTSrequestisdef
...