[cabfpub] Additional Content in SSL certificates

[Steve Roylance]

Dear CABForum,

 

I've been working on an issue in the Mozilla mailing lists which I think
should be given air time again.   Back in June 2012, just prior to the
effective date of the Baseline Requirements, it was suggested by me that the
Forum reach out to a wider audience of third party providers who created
platforms that had the capability to issue certificates to ensure that they
met BR compliance needs.  Ballot 105 specifically addresses the fact that we
didn't do this by not mandating OCSP services be database based (an example
of another area where we should all be striving to meet best practice)

 

Whilst the focus of the discussion in that thread is actually something else
(human error in the use of a space in the Common Name), a particular side
issue highlights the fact that additional information is added to SSL
certificates in order to support WS-Trust services by the Microsoft platform
and not many people know what this is.  GlobalSign and the end customer
concernd (Deutsche Post) meet the BR guidelines as we do know what the OID
is for (it'e part of the WS-Trust serviecs automation introduced in Srever
2008 R2) so we fulfil the needs of Appendix B (4) shown below with ***'s
around this section.
https://www.partnerportal-deutschepost.de/nc/login.html is an example of an
end entity having these Microsoft specific additional items.  This is the
extra ifnromation included:- 

 

Template=1.3.6.1.4.1.311.21.8.3675690.6234259.10436751.12227305.62135.141.95
9321.10252252

Major Version Number=100

Minor Version Number=6

 

>From https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf marked with ***'s

(4) All Certificates 

All other fields and extensions MUST be set in accordance with RFC 5280. The
CA SHALL NOT issue a Certificate that contains a keyUsage flag,
extendedKeyUsage value, Certificate extension, or other data not specified
in this Appendix B ****unless the CA is aware of a reason for including the
data in the Certificate****. 

CAs SHALL NOT issue a Certificate with: 

(a) Extensions that do not apply in the context of the public Internet (such
as an extendedKeyUsage value for a service that is only valid in the context
of a privately managed network), unless: i. such value falls within an OID
arc for which the Applicant demonstrates ownership, or ii. the Applicant can
otherwise demonstrate the right to assert the data in a public context; or 

(b) semantics that, if included, will mislead a Relying Party about the
certificate information verified by the CA (such as including
extendedKeyUsage value for a smart card, where the CA is not able to verify
that the corresponding Private Key is confined to such hardware due to
remote issuance).

 

Is there sufficient impetus to bring back the discission and invite third
parties to provide compliance plans/timelines?   This may also aid our work
on OCSP stapling etc ;-)

 

Kind Regards

 

Steve

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150413/d63ed035/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4256 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150413/d63ed035/attachment.p7s>