[cabfcert_policy] CA vs. CA draft proposal
陳立群
realsky at cht.com.tw
Thu Mar 24 21:54:25 MST 2016
I missed the policy call last night here as it showing up on my calendar at
the wrong time, too. When I call it is time for Validation working group.
I agree with Wendy point out the exact definition of self-issued
certificate . Also, In 34 F2F meeting , we have discussed about self-signed
certificate, self-issued certificate and bug about Microsoft IIS for
processing self-issued certificates. Please see attached presentation
and below meeting minutes:
Li-Chun CHEN of Chunghwa Telecom presented a discussion on Roll Over
Certificate Issues –
<https://cabforum.org/wp-content/uploads/Chunghwatelecom201503cabforumV4.pdf
>
https://cabforum.org/wp-content/plugins/filetype-icons/icons/16/file_extensi
on_pdf.pngChunghwatelecom201503cabforumV4
He explained the rollover certificate process outlined in RFC 4210 by
signing the old public key with the new private key and the new public key
with the old private key. He also gave the definition of Self-issued
certificates and Self signed certificates as RFC 5280. Following RFC 5280 6.
1, a certificate is self-issued if the same DN appears in the subject and
issuer fields. The Taiwanese Government Root CA (GRCA) has switched over
from SHA1 to SHA256 (in 2012), but he has encountered IIS issues following
the processes found in the RFCs. See Slide pp.8-pp.13. IIS 7 falsely treated
GRCA’s Self-Issued certificate (new with old) as a Self-Signed certificate,
because it has the same issuer and subject name. He found SSL Cert –> GCA
Cert –> new-with-old GRCA Cert –> old GRCA cert in IIS side, but IIS only
sends SSL Cert –> GCA Cert to client. For Mozilla Firefox, it uses its own
trust list and it only trusts old GRCA and new GRCA is waiting to be built
in NSS. So there are lots of complaints of Firefox users connected to IIS
sites. He noted that because Windows clients support AIA chasing there are
less chaining problems.
Sites powered by IIS such as <https://gcaweb.nat.gov.tw/>
https://gcaweb.nat.gov.tw & <https://www.hrd.gov.tw/>
https://www.hrd.gov.tw/
Site powered by Apache, which will send the entire Certificate Chain:
<https://www.ncert.nat.gov.tw/> https://www.ncert.nat.gov.tw/
Users could use below pages to test the behavior of webserver and browser:
<https://www.sslshopper.com/ssl-checker.html>
https://cabforum.org/wp-content/plugins/filetype-icons/icons/16/file_extensi
on_html.pnghttps://www.sslshopper.com/ssl-checker.html
<https://certlogik.com/ssl-checker/> https://certlogik.com/ssl-checker/
Chunghwa Telecom finds there is a bug the same as IIS that Qualys SSL Labs
tool can’t distinguish self-issued certificate with self-signed
certificate.
So Chunghwa Telecom requested Microsoft to solve the bug of IIS ASAP
through Premium support.
Chunghwa Telecom suggested to make AIA mandatory and browsers must support
fetching intermediate certificates through AIA. Supporting AIA will also
reduce some web site administrators forget to install intermediate
certificates to their server follow CAs or web server’s manuals. (In SSL
protocol, SSL servers should send intermediate certificate & SSL certificate
to SSL client)
Gerv said that even if Mozilla were to fix AIA chasing there would still be
problems with other clients. Ryan said that the newer versions of OpenSSL
and Apache have behavior similar to IIS 7, due to server operators failing
to configure their servers properly. OpenSSL 1.1.0 will prefer trusted
certificates first. Newer versions of Apache will try to build a valid
chain. You can still force it to send the chain you want with the old
directive, but the default will be to try to construct the ideal chain
before sending it. Anoosh said that there are things you can do to force IIS
to send a different chain. One thing is to add the unwanted certificate to
the “Untrusted Store.” Ryan said another approach is to manually disable
the Windows operating system’s trust store and direct it to use a
Certificate Trust List (CTL). Robin said that the server operator would
still need to ensure that the server is able to trust what it needs to
trust.
Ryan and Gerv agreed that better solution would have been not to use the
same issuer-subject names in the rollover.
Ryan added that with the SHA1 deprecation server operators have had trouble
deciding which types of chains to build. For instance, CloudFlare’s chain
builder tool asks whether you prefer strong cryptography over broad
usability. Gerv said that the problem is that you cannot send all of the
possible paths that all clients might need, so a choice has to be made. A
decision has to be made also for clients that chase AIAs. Gerv said that if
a certificate contained multiple AIAs with different paths, a client would
have to be able to chase all of them and then decide which path to choose,
and that can become complicated and take additional time.
[Additionally, Brian Smith commented separately via email, “It is also
possible, and recommended, for the rollover certificate to be added to
Firefox’s certificate store. Then Firefox will be able to use it even if
IIS doesn’t send it.”]
Sincerely Yours,
Li-Chun CHEN
From: policyreview-bounces at cabforum.org
[mailto:policyreview-bounces at cabforum.org] On Behalf Of Brown, Wendy (10421)
Sent: Thursday, March 24, 2016 11:17 PM
To: Peter Bowen; policyreview at cabforum.org
Subject: Re: [cabfcert_policy] CA vs. CA draft proposal
I missed the policy call this morning based on it showing up on my calendar
at the wrong time.
But I have a question on one of the suggestions below:
In section 4.3.1, append the following text:
A CA shall only issue a Self-Issued CI Certificate when the Private Key used
by the CA to sign the Certificate corresponds to the Public Key that is
certified within the Certificate.
I believe this is the definition of a self-signed certificate rather than a
self-issued one.
A self-issued certificate may also include certificates issued when a CA
does a key rollover and signs the new key with the old and vice-verse. In
these self-issued certificates the Private Key used by the CA to sign the
Certificates does NOT correspond to the Public Key in the same certificate.
Thanks,
Wendy
Wendy Brown
Protiviti Government Services
703-299-4705 (office) 703-965-2990 (cell)
wendy.brown at protiviti.com
-----Original Message-----
From: policyreview-bounces at cabforum.org
[mailto:policyreview-bounces at cabforum.org] On Behalf Of Peter Bowen
Sent: Thursday, March 24, 2016 9:43 AM
To: policyreview at cabforum.org
Subject: [cabfcert_policy] CA vs. CA draft proposal
New Definitions:
Certificate Issuer (CI): An issuer of Certificates defined by a distinct
Distinguished Name and Public Key
CI Certificate: A Certificate for which any of the following are true:
- A Basic Constraints extension is present and the cA component is set to
TRUE
- A Key Usage extension is present and the keyCertSign bit is set
CI Key Pair: A Key Pair which has its Public Key included in a CI
Certificate
Cross-Certificate: A CI certificate which is not a Self-Issued CI
Certificate
End-entity Certificate: A Certificate which is not a CI Certificate
Root CI: A CI which is distributed by Application Software Suppliers as a
trust anchor
Root CI Key Pair: A CI Key Pair which has its Public Key included in a Root
Certificate
Root CI Certificate: A CI Certificate which contains the Public Key from a
Root CI Key Pair
Self-Issued CI Certificate: A CI Certificate where the subject and issuer
Distinguished Names match
Technically Constrained CI Certificate: A CI certificate which uses a
combination of Extended Key Usage settings and Name Constraint settings to
limit the scope within which CI may issue Subscriber or additional CI
Certificates.
Modifications:
In section 3.1.5, insert the following text:
Each CI Public Key MUST be associated with a single distinct Distinguished
Name. Each CI Distinguished Name MUST be associated with a single unique
Public Key.
In section 4.3.1, append the following text:
A CA shall only issue a Self-Issued CI Certificate when the Private Key used
by the CA to sign the Certificate corresponds to the Public Key that is
certified within the Certificate.
<more to change CA to CI where appropriate>
_______________________________________________
Policyreview mailing list
<mailto:Policyreview at cabforum.org> Policyreview at cabforum.org
<https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_l
istinfo_policyreview&d=CwICAg&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&
r=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=gSpKiZiIdAJzxq9a88_HscBTw9cL
kE8YDBEzaQxJHuk&s=JiNpdPG91ZZfD2LKBTN6J3Reniaqm3tdjimPSQfp4kU&e>
https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_li
stinfo_policyreview&d=CwICAg&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r
=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=gSpKiZiIdAJzxq9a88_HscBTw9cLk
E8YDBEzaQxJHuk&s=JiNpdPG91ZZfD2LKBTN6J3Reniaqm3tdjimPSQfp4kU&e=
NOTICE: Protiviti is a global consulting and internal audit firm composed of
experts specializing in risk and advisory services. Protiviti is not
licensed or registered as a public accounting firm and does not issue
opinions on financial statements or offer attestation services. This
electronic mail message is intended exclusively for the individual or entity
to which it is addressed. This message, together with any attachment, may
contain confidential and privileged information. Any views, opinions or
conclusions expressed in this message are those of the individual sender and
do not necessarily reflect the views of Protiviti Inc. or its affiliates.
Any unauthorized review, use, printing, copying, retention, disclosure or
distribution is strictly prohibited. If you have received this message in
error, please immediately advise the sender by reply email message to the
sender and delete all copies of this message. Thank you.
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160325/ed740d6f/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 657 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160325/ed740d6f/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 711 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160325/ed740d6f/attachment-0003.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Chunghwatelecom201503cabforumV4.pdf
Type: application/pdf
Size: 909523 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160325/ed740d6f/attachment-0001.pdf
More information about the Policyreview
mailing list