[Cscwg-public] [EXTERNAL] Re: Update to key protection (in 16.2 & 16.3)
Tomas Gustavsson
tomas.gustavsson at primekey.com
Fri Feb 5 07:21:26 UTC 2021
Hi,
Two comments:
1.
Mentioning CEN PP EN 419 221-5 is redundant.
"FIPS 140-2 level 2, Common Criteria EAL 4+, or CEN PP EN 419 221-5."
If you want to keep the broad statement like "Common Criteria EAL 4+" it
already includes 419 221-5. I quote from 419 221-5 (draft):
-----
2.1 CC Conformance Claim
This protection profile is conformant to Common Criteria version 3.1
revision 4.
More precisely, this protection profile is:
• CC Part 1 [CC1],
• CC Part 2 extended [CC2],
• CC Part 3 conformant [CC3].
The assurance requirement of this Protection Profile is EAL4 augmented.
Augmentation results from the selection of:
• AVA_VAN.5 Advanced methodical vulnerability analysis
-----
So in this case you can just skip mentioning "CEN PP EN 419 221-5" since
it's already implicitly included.
"FIPS 140-2 level 2 or Common Criteria EAL 4+"
2.
We had the discussion about audits regarding leaving out "or
equivalent", as it's not clear how to judge that for an auditor.
In this context I wonder about "that meets or exceeds". For example, if
EU created a new protection profile (a new version of 419221-5 for
example) with the new assurance levels defined by the EU Cybersecurity
Act. Can there be a mapping for "meet or exceed"?
As stated here:
https://www.enisa.europa.eu/publications/cybersecurity-certification-eucc-candidate-scheme/at_download/fullReport
-----
a certificate at EAL3 augmented with AVA_VAN.3 and associated
dependencies shall be considered as a certificate at the ‘high’
assurance level of the CSA.
-----
Assurance level "high" under the new EU schemes sounds like it will
compare to EAL3+ in the old scale.
It may be safest to not try to be too future proof perhaps, and in that
case update the guidelines instead (it's would be a few years out anyway).
Cheers,
Tomas
On 2021-02-05 00:48, Ian McMillan wrote:
> Hi Folks,
>
>
>
> I've revised the wording on key protection as it relates to the hardware
> crypto module conformance to standards as we discussed in the last call.
> I used the wording, /"crypto module that meets or exceeds the
> requirements of FIPS 140-2 level 2, Common Criteria EAL 4+, or CEN PP EN
> 419 221-5."/ This covers the 3 standards we discussed and commonly see
> in what is available in the market for HSMs, tokens, and cloud key
> protection solutions. Love to get feedback on whether this satisfies
> everyone's feedback.
>
>
>
> As far as the techniques to satisfying the requirements for key
> protection as a signing service (16.2[3]), the feedback was the audit
> verbiage was confusing, so I've updated to state:
>
> / /
>
> /"Contractual terms in the subscriber agreement requiring the Subscriber
> to protect the private key to a standard equivalent to FIPS 140-2 level
> 2, Common Criteria EAL 4+, or CEN PP EN 419 221-5, and with compliance
> being confirmed by means of an audit on the attestation records received
> by the CA from the Subscriber to accepting the terms of the subscriber
> agreement."/
>
>
>
> I am definitely not a lawyer by any means, so I am happy to get feedback
> on wordsmithing the intent of what we are after here.
>
>
>
> Lastly, here is a snapshot of the drafted key protection changes I have
> now, and hope to discuss in our call next week.
>
> * *
>
> *Signing Service Requirements***
>
> The Signing Service MUST ensure that a Subscriber’s private key is
> generated, stored, and used in a secure environment that has controls to
> prevent theft or misuse. A Signing Service MUST enforce multi-factor
> authentication to authorize Code Signing and obtain a representation
> from the Subscriber that they will securely store the tokens required
> for multi-factor access. A system used to host a Signing Service MUST
> NOT be used for web browsing. The Signing Service MUST run a regularly
> updated antivirus solution to scan the service for possible virus
> infection. The Signing Service MUST comply with the Network Security
> Guidelines as a “Delegated Third Party”.
>
> For Code Signing Certificates, Signing Services shall protect private
> keys in a FIPS 140-2 level 2, Common Criteria EAL 4+, or CEN PP EN 419
> 221-5 compliant hardware crypto module. Techniques that may be used to
> satisfy this requirement include:
>
> 1. Use of an HSM, verified by means of a manufacturer’s
> certificate;
>
> 2. A hardware crypto module provided by the CA;
>
> 3. Contractual terms in the subscriber agreement requiring
> the Subscriber to protect the private key to a standard equivalent to
> FIPS 140-2 level 2, Common Criteria EAL 4+, or CEN PP EN 419 221-5, and
> with compliance being confirmed by means of an audit on the attestation
> records received by the CA from the Subscriber to accepting the terms of
> the subscriber agreement.
>
> 4. Cryptographic algorithms, key sizes and certificate
> life-times for both authorities and Subscribers are governed by the NIST
> key management guidelines.
>
> 5. A Cloud-based key generation and protection solution with the
> following requirements enabled on the subscription, and a usage pattern
> as follows:
>
> 1. Key creation, storage, and usage of private key MUST remain
> within the security boundaries of a hardware crypto module that conforms
> to at least FIPS 140-2 Level 2, Common Criteria EAL 4+, or CEN PP EN 419
> 221-5;
>
> 2. Subscription MUST be configured to log key creation,
> importation, deletion, archiving and all access events not associated
> with the act of code signing by the Signing Service. These logs must be
> retained for the life of the certificate bound to the private key;
>
> 3. The identities authorized to the Cloud key protection service
> subscription protecting the private key must be included in logical
> access reviews as required by any audits.
>
>
>
> *Subscriber Private Key Protection***
>
> For Code Signing Certificates, the CA MUST obtain a representation from
> the Subscriber that the Subscriber will use one of the following options
> to generate and protect their Code Signing Certificate private keys:
>
>
>
> 1. A hardware crypto module with a unit design form factor
> certified as conforming to at least FIPS 140-2 Level 2, Common Criteria
> EAL 4+, or CEN PP EN 419 221-5;
>
>
>
> 2. A Cloud-based key generation and protection solution with the
> following requirements enabled on the subscription, and a usage pattern
> as follows:
>
>
>
> 1. Key creation, storage, and usage of private key must remain
> within the security boundaries of the cloud solutions hardware crypto
> module that conforms to at least FIPS 140-2 Level 2, Common Criteria EAL
> 4+, or CEN PP EN 419 221-5;
>
>
>
> 2. Subscription must be configured to log all access, operations,
> and configuration changes on the private key itself.
>
>
>
> For Code Signing Certificates, CAs SHALL ensure that the Subscriber’s
> private key is generated, stored, and used in a crypto module that meets
> or exceeds the requirements of FIPS 140-2 level 2, Common Criteria EAL
> 4+, or CEN PP EN 419 221-5. Acceptable methods of satisfying this
> requirement include (but are not limited to) the following:
>
>
>
> 1. The CA ships a suitable hardware crypto module, with a
> preinstalled key pair;
>
>
>
> 2. The Subscriber counter-signs certificate requests that can be
> verified by using a manufacturer’s certificate indicating that the key
> is managed in a suitable hardware module;
>
>
>
> 3. The Subscriber provides a suitable IT audit indicating that its
> operating environment achieves a level of security at least equivalent
> to that of FIPS 140-2 level 2, Common Criteria EAL 4+, or CEN PP EN 419
> 221-5;
>
>
>
> 4. The Subscriber provides a suitable report of the cloud key
> protection solution subscription configuration protecting the key in
> hardware crypto module with a unit design form factor certified as
> conforming to at least FIPS 140-2 Level 2, Common Criteria EAL 4+, or
> CEN PP EN 419 221-5.
>
> Cheers,
>
> Ian
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of
> Tomas Gustavsson via Cscwg-public
> Sent: Friday, November 13, 2020 12:09 AM
> To: cscwg-public at cabforum.org
> Subject: [EXTERNAL] Re: [Cscwg-public] Update to key protection (in 16.2
> & 16.3)
>
>
>
>
>
> Hi,
>
>
>
> I have reached out to a security architect at a vendor of security
> hardware chips to get a better understanding on the certification side
> of things.
>
>
>
> The story gets foggier...at least for me.
>
>
>
> I have more questions than answers unfortunately. But it boils down to
> if the forum want to high a high level of assurance of private key
> protection, or muddier, opening options for weaker private key protection?
>
>
>
> The security architect I spoke with don't think we should use "or
> equivalent" as that is very non specific. How to judge this? In his
> opinion it open up doors to weak private key protection.
>
>
>
> I got a little better insight into chip silicon certifications.
>
>
>
> FIPS 140-2 or EN 419 221-5 are highly related to HSMs.
>
> BTW: from now on HSMs are evaluated against FIPS 140-3 I believe (since
> september 2020).
>
>
>
> Silicon produced for USB tokens and smart cards are evaluated against:
>
>
>
> TPM silicon is certified against:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fresource%2Fpc-client-tpm-certification%2F&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zyl9OICcX1pLMryY%2BpKcBEG8kesw%2BJMUeWbUgmVP1ao%3D&reserved=0
>
>
>
> Then system vendors can lay FIPS certification on top of the silicon
> certification, adding their firmware.
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fresource%2Ftcg-fips-140-2-guidance-for-tpm-2-0%2F&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CGWExgwKk5iooCrR9%2BUj3q1nRD1PReljYMJ5AThhmd4%3D&reserved=0
>
>
>
> A relevant requirement for TPMs module certification would be:
>
> "Protection Profile PC Client Specific TPM version 2.0"
>
>
>
> For smart cards or USB token chips it could be:
>
> "Security IC Platform Protection Profile version 1.0"
>
>
>
> To complicate things some old tokens like SafeNet was certified against:
>
> "Protection Profile —Secure Signature-Creation Device v1.05"
>
>
>
> Questions:
>
>
>
> 1. How strongly does the forum want to assure private key protection for
> code signing keys?
>
>
>
> 2. Question I guess if for WebTrust, is it reasonable to judge "or
> equivalent", or does it open up too many doors to weak key protection?
>
> For example is the CC evaluation of SafeNet eToken 5110 (a popular USB
>
> token) equivalent?
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcpl.thalesgroup.com%2Faccess-management%2Fauthenticators%2Fpki-usb-authentication%2Fetoken-5110-usb-token&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ovN%2BVo2DUfiSH4KNHPXh%2BUkhxbbqd7os6sGYTYev%2BA%3D&reserved=0
>
>
>
> 3. Should we FIPS 140-3 directly? Evaluations on -3 has begun.
>
>
>
> 4. If the Forum want to specify USB tokens and TPMs more carefully,
> should those certification standards be called out?
>
>
>
> Regards,
>
> Tomas
>
>
>
> On 2020-11-02 20:43, Ian McMillan via Cscwg-public wrote:
>
>> Thanks Bruce!
>
>>
>
>>
>
>>
>
>> For #1, I am interested in better understanding what advantages level
>
>> 3 operations provides here. I do feel level 2 will continue to be the
>
>> best course of requirement as a Signing Service should have the
>
>> ability to execute on resiliency scenarios that would be negated by
>
>> level 3 operations (e.g. HSM vendor and SW diversity/resilience). I
>
>> also do not want to exclude Signing Services from leveraging
>
>> cloud-based key protection services which offer level 2 as a
>
>> base/premium SKU in all cases (not all have a level 3 option).
>
>>
>
>>
>
>>
>
>> On #2, I feel the timing is at least one year out from the June 1,
>
>> 2021 date that we attached to key lengths and hash algorithms. The 1
>
>> year from that date should provide most the opportunity to obtain a
>
>> code signing certificate within the new standards for key protection.
>
>> It may be best to state in the timing that any new certificates issued
>
>> post implementation date (say June 1, 2021) must meet the these key
>
>> protection standards, but private keys for existing valid certificates
>
>> have until June 1, 2022 to meet these requirements. Is this viable in
>
>> folks mind?
>
>>
>
>>
>
>>
>
>> Thanks,
>
>>
>
>> Ian
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> *From:* Bruce Morton <Bruce.Morton at entrust.com
> <mailto:Bruce.Morton at entrust.com>>
>
>> *Sent:* Sunday, November 1, 2020 11:38 AM
>
>> *To:* Ian McMillan <ianmcm at microsoft.com
> <mailto:ianmcm at microsoft.com>>; cscwg-public at cabforum.org
> <mailto:cscwg-public at cabforum.org>
>
>> *Subject:* [EXTERNAL] RE: Update to key protection (in 16.2 & 16.3)
>
>>
>
>>
>
>>
>
>> Hi Ian,
>
>>
>
>>
>
>>
>
>> I will have our team review.
>
>>
>
>>
>
>>
>
>> I have a couple of items:
>
>>
>
>> 1. Signing Service requires FIPS 140-2 level 2. Should this be updated
>
>> to FIPS 140-2 level 3, as this device will not be operated by the
>
>> Subscriber and may have many multiple Subscriber private keys? Level
>
>> 3 might be better for a third party to protect a multi-tenant HSM.
>
>> 2. If this ballot passes, when would it need to be implemented. I think
>
>> that there may be many impacted to CAs and Subscribers. It would be
>
>> good to have many months to a year to implement.
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> Thanks, Bruce.
>
>>
>
>>
>
>>
>
>> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org
>
>> <mailto:cscwg-public-bounces at cabforum.org>> *On Behalf Of *Ian
>
>> McMillan via Cscwg-public
>
>> *Sent:* Friday, October 30, 2020 6:11 PM
>
>> *To:* cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>
> <mailto:cscwg-public at cabforum.org>
>
>> *Subject:* [EXTERNAL][Cscwg-public] Update to key protection (in 16.2
>
>> &
>
>> 16.3)
>
>>
>
>>
>
>>
>
>> *WARNING:* This email originated outside of Entrust.
>
>> *DO NOT CLICK* links or attachments unless you trust the sender and
>
>> know the content is safe.
>
>>
>
>> ----------------------------------------------------------------------
>
>> --
>
>>
>
>> Hi Folks!
>
>>
>
>>
>
>>
>
>> I’ve drafted up the redline for the changes for an upcoming ballot on
>
>> the current version of the Baseline Requirements for the Issuance and
>
>> Management of Publicly-Trusted Code Signing Certificates
>
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcab
>
>> forum.org%2Fwp-content%2Fuploads%2Fbaseline_requirements_for_the_issua
>
>> nce_and_management_of_code_signing.v.2.0.pdf&data=04%7C01%7Cianmcm
>
>> %40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af
>
>> 91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8
>
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
>
>> 000&sdata=VpQ15CkmBvodqdoLhc9SGinv6KEpsI7t90BUFDEbQ1E%3D&reser
>
>> ved=0> on section 16.2 and 16.3 as it pertains to subscriber private
>
>> key protection requirements (leaf-signing cert private keys). The goal
>
>> is to collapse the requirements on non-EV and EV, and to include
>
>> support for cloud-based key protection solution offered by GCP, AWS,
>
>> and Azure.
>
>> Please review and provide comments on the verbiage below and the
>
>> redline changes in the document attached, and *if you would be willing
>
>> to endorse this change in the upcoming ballot, please let me know*.
>
>>
>
>>
>
>>
>
>> */16.2 Signing Service Requirements/**//*
>
>>
>
>> The Signing Service MUST ensure that a Subscriber’s private key is
>
>> generated, stored, and used in a secure environment that has controls
>
>> to prevent theft or misuse. A Signing Service MUST enforce
>
>> multi-factor authentication to authorize Code Signing and obtain a
>
>> representation from the Subscriber that they will securely store the
>
>> tokens required for multi-factor access. A system used to host a
>
>> Signing Service MUST NOT be used for web browsing. The Signing
>
>> Service MUST run a regularly updated antivirus solution to scan the
>
>> service for possible virus infection. The Signing Service MUST comply
>
>> with the Network Security Guidelines as a “Delegated Third Party”.
>
>>
>
>> For Code Signing Certificates, Signing Services shall protect private
>
>> keys in a FIPS 140-2 level 2 (or equivalent) crypto module.
>
>> Techniques that may be used to satisfy this requirement include:
>
>>
>
>>
>
>>
>
>> 1. Use of an HSM, verified by means of a manufacturer’s
>
>> certificate;
>
>>
>
>> 2. A hardware crypto module provided by the CA;
>
>>
>
>> 3. Contractual terms in the subscriber agreement requiring the
>
>> Subscriber to protect the private key to a standard equivalent to FIPS
>
>> 140-2 level 2 and with compliance being confirmed by means of an audit.
>
>>
>
>> 4. Cryptographic algorithms, key sizes and certificate
>
>> life-times for both authorities and Subscribers are governed by the
>
>> NIST key management guidelines.
>
>>
>
>> 5. A Cloud-based key protection solution with the following
>
>> requirements enabled on the subscription, and a usage pattern as follows:
>
>>
>
>> /1. //A hardware crypto module with a unit design form factor
>
>> certified as conforming to at least FIPS 140-2 Level 2, eIDAS
>
>> Protection
>
>> Profile: EN 419 221-5, or equivalent;/
>
>>
>
>> /2. //Key creation, storage, and usage of private key must
>
>> remain within the security boundaries of the cloud solutions hardware
>
>> crypto module;/
>
>>
>
>> /3. //Subscription must be configured to log access, operations,
>
>> and configuration changes on the key. The configuration change log is
>
>> available for audits./
>
>>
>
>>
>
>>
>
>> */16.3 Subscriber Private Key Protection/**//*
>
>>
>
>> For Code Signing Certificates, the CA MUST obtain a representation
>
>> from the Subscriber that the Subscriber will use one of the following
>
>> options to generate and protect their Code Signing Certificate private
> keys:
>
>>
>
>>
>
>>
>
>> 1. A hardware crypto module with a unit design form factor
>
>> certified as conforming to at least FIPS 140-2 Level 2, eIDAS
>
>> Protection
>
>> Profile: EN 419 221-5, or equivalent;
>
>>
>
>>
>
>>
>
>> 2. A Cloud-based key protection solution with the following
>
>> requirements enabled on the subscription, and a usage pattern as follows:
>
>>
>
>> /1. //A hardware crypto module with a unit design form factor
>
>> certified as conforming to at least FIPS 140-2 Level 2, eIDAS
>
>> Protection
>
>> Profile: EN 419 221-5, or equivalent;/
>
>>
>
>> /2. //Key creation, storage, and usage of private key must
>
>> remain within the security boundaries of the cloud solutions hardware
>
>> crypto module;/
>
>>
>
>> /3. //Subscription must be configured to log all access,
>
>> operations, and configuration changes on the key. The configuration
>
>> change log is available for audits./
>
>>
>
>> / /
>
>>
>
>> 3. A type of hardware storage token with a unit design form
>
>> factor of SD Card or USB token certified as conformant with FIPS 140
>
>> Level 2 or eIDAS Protection Profile: EN 419 221-5). The Subscriber
>
>> MUST also warrant that it will keep the token physically separate from
>
>> the device that hosts the code signing function until a signing
> session is begun.
>
>>
>
>>
>
>>
>
>> For Code Signing Certificates, CAs SHALL ensure that the Subscriber’s
>
>> private key is generated, stored and used in a crypto module that
>
>> meets or exceeds the requirements of FIPS 140-2 level 2, eIDAS
>
>> Protection
>
>> Profile: EN 419 221-5, or equivalent. Acceptable methods of satisfying
>
>> this requirement include (but are not limited to) the following:
>
>>
>
>>
>
>>
>
>> 1. The Subscriber counter-signs certificate requests that can be
>
>> verified by using a manufacturer’s certificate indicating that the key
>
>> is managed in a suitable hardware module;
>
>>
>
>>
>
>>
>
>> 2. The Subscriber provides a suitable IT audit indicating that
>
>> its operating environment achieves a level of security at least
>
>> equivalent to that of FIPS 140-2 level 2, eIDAS Protection Profile: EN
>
>> 419 221-5, or equivalent;
>
>>
>
>>
>
>>
>
>> 3. The Subscriber provides a suitable report of the cloud key
>
>> protection solution subscription configuration protecting the key in
>
>> hardware crypto module with a unit design form factor certified as
>
>> conforming to at least FIPS 140-2 Level 2, eIDAS Protection Profile,
>
>> EN
>
>> 419 221-5, or equivalent.
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> Thanks,
>
>>
>
>> Ian McMillan
>
>>
>
>> Microsoft
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> _______________________________________________
>
>> Cscwg-public mailing list
>
>> Cscwg-public at cabforum.org <mailto:Cscwg-public at cabforum.org>
>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>
>> s.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7C
>
>> ianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86
>
>> f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbG
>
>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
>
>> 3D%7C1000&sdata=EI8oFiOeODof9tI47AMHhxynm3%2B02xHZY6k4jjqxAbI%3D&a
>
>> mp;reserved=0
>
>>
>
> _______________________________________________
>
> Cscwg-public mailing list
>
> Cscwg-public at cabforum.org <mailto:Cscwg-public at cabforum.org>
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EI8oFiOeODof9tI47AMHhxynm3%2B02xHZY6k4jjqxAbI%3D&reserved=0
>
More information about the Cscwg-public
mailing list