555156 - Add ANF root certificate

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task, P5)

Description

[Isabel Fabregas]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)
Build Identifier: 

ANF Autoridad de Certificación (http://www.anf.es) is currently approved by the public administration to issue qualified certificates in the European Union and it is the process of being approved in other countries (Ecuador and Panama), so Mozilla users in these areas will improve their user experience when relating with government or with other citizens using Mozilla applications.

The CA certificate data is add in the "additional information" field of this bug.

This CA certificate issues certificates with the following usages (Extended Key Usages):
Server Authentication =1.3.6.1.5.5.7.3.1
Client Authentication =1.3.6.1.5.5.7.3.2
Secure E-mail EKU=1.3.6.1.5.5.7.3.4
Code Signing EKU=1.3.6.1.5.5.7.3.3
Time stamping EKU=1.3.6.1.5.5.7.3.8
OCSP EKU=1.3.6.1.5.5.7.3.9

The Certificate Practice Statement can accessed in the following URL:
http://www.anf.es/anf/ssl/pdf/DPC_ANF_Server_CA_1.3.6.1.4.1.18332.1.9_v_1.0.pdf   
The criteria for issuing certificates are:

Physical presence of the requester on a registration authority aproved by ANF Autoridad de Certificación. Registration authority checks that the documentation provided by the requester matches its identity and prepares a copy for the Certification Authority. In a second step a team of lawyers checks the documentation provided by the registration authority and if it is right and enough the certificate is issued.




 



Reproducible: Always




-----BEGIN CERTIFICATE-----
MIIHjDCCBnSgAwIBAgIDATRLMA0GCSqGSIb3DQEBBQUAMIHZMQswCQYDVQQGEwJF
UzESMBAGA1UECAwJQmFyY2Vsb25hMUcwRQYDVQQHDD5CYXJjZWxvbmEgKHNlZSBj
dXJyZW50IGFkZHJlc3MgYXQgaHR0cHM6Ly93d3cuYW5mLmVzL2FkZHJlc3MvKTEo
MCYGA1UECgwfQU5GIEF1dG9yaWRhZCBkZSBDZXJ0aWZpY2FjacOzbjEXMBUGA1UE
CwwOQU5GIENsYXNlIDEgQ0ExEjAQBgNVBAUTCUc2MzI4NzUxMDEWMBQGA1UEAwwN
QU5GIFNlcnZlciBDQTAeFw0wOTExMzAyMzAwMDBaFw0yMTExMzAyMzAwMDBaMIHZ
MQswCQYDVQQGEwJFUzESMBAGA1UECAwJQmFyY2Vsb25hMUcwRQYDVQQHDD5CYXJj
ZWxvbmEgKHNlZSBjdXJyZW50IGFkZHJlc3MgYXQgaHR0cHM6Ly93d3cuYW5mLmVz
L2FkZHJlc3MvKTEoMCYGA1UECgwfQU5GIEF1dG9yaWRhZCBkZSBDZXJ0aWZpY2Fj
acOzbjEXMBUGA1UECwwOQU5GIENsYXNlIDEgQ0ExEjAQBgNVBAUTCUc2MzI4NzUx
MDEWMBQGA1UEAwwNQU5GIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAL/qSKeaiDlrLEhABwSTfPe4LX6lN+Jh1iH8kDfLaT5eizffW287
2LbDiECQ9J0MXBBSsbPlX5EQ5v2ogBRf04u9XL0PI5IJN+Ny0maUC1x0lC9e8k7Y
A8azzlalHNl7/U8HTNS32l8pTXXyH1XPMiMcRgknHUXs8Yw0id57FqdDXoor6ZRD
Htc+k21viT287rHIt//JfeNfDW93ePUqLo3Ei5iXMLFGWgtjcNR4x4azf/8nQqqf
im5toZTK7IcCHNZUS/28iZumYzhmjBaJiZfDUOj2QgGnd30QGZID6F1FyBXFhxsN
kfLGOZx788AKmfjug29+QncRjsMfHHIvPRsCAwEAAaOCA1kwggNVMB0GA1UdDgQW
BBS+O/a0MbdzJEg5xVcTlHWqn4E/LDCCAQoGA1UdIwSCAQEwgf6AFL479rQxt3Mk
SDnFVxOUdaqfgT8soYHgpIHdMIHaMQswCQYDVQQGEwJFUzESMBAGA1UECBMJQmFy
Y2Vsb25hMUgwRgYDVQQHDD9CYXJjZWxvbmEgKHNlZSBjdXJyZW50IGFkZHJlc3Mg
YXQgaHR0cHM6Ly93d3cuYW5mLmVzL2FkZHJlc3MvICkxJzAlBgNVBAoTHkFORiBB
dXRvcmlkYWQgZGUgQ2VydGlmaWNhY2lvbjEXMBUGA1UECxMOQU5GIENsYXNlIDEg
Q0ExEzARBgNVBAUTCkctNjMyODc1MTAxFjAUBgNVBAMTDUFORiBTZXJ2ZXIgQ0GC
AwE0SzAMBgNVHRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAxBgorBgEEAYGPHCoG
BCMbIWh0dHBzOi8vd3d3LmFuZi5lcy9BQy9BQ1RBUy83ODkyMzAYBgorBgEEAYGP
HBMBBAobCDgwMS0zNDAwMIHrBgNVHSAEgeMwgeAwgd0GCisGAQQBgY8cAQkwgc4w
LQYIKwYBBQUHAgEWIWh0dHBzOi8vd3d3LmFuZi5lcy9BQy9kb2N1bWVudG9zLzCB
nAYIKwYBBQUHAgIwgY8agYxBbnRlcyBkZSBhY2VwdGFyIGVzdGUgY2VydGlmaWNh
ZG8sIGNvbXBydWViZToKLUNvbmRpY2lvbmVzLCBsaW1pdGFjaW9uZXMgeSB1c29z
IGF1dG9yaXphZG9zIHNlZ3VuIENQIGEgbGEgcXVlIHNlIHNvbWV0ZS4KLUVzdGFk
byBkZSB2aWdlbmNpYTA4BggrBgEFBQcBAQQsMCowKAYIKwYBBQUHMAGGHGh0dHA6
Ly93d3cuYW5mLmVzL0FDL1JDL29jc3AwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cHM6
Ly93d3cuYW5mLmVzL0FDL0FORlNlcnZlckNBLmNybDAroCmgJ4YlaHR0cHM6Ly9j
cmwuYW5mLmVzL0FDL0FORlNlcnZlckNBLmNybDAWBgNVHRIEDzANgQtpbmZvQGFu
Zi5lczAWBgNVHREEDzANgQtpbmZvQGFuZi5lczANBgkqhkiG9w0BAQUFAAOCAQEA
H1iREHc3b80kDhnqmC2pQWLXysEPRLQ30j74Hi/Bt6DDRz9aX+E+3zMLeh3I5oxi
0DD+WiWdbi2I+krvcJ9CWXAcbRCG61dGyxiOuiSK38SNUugksd5ouSMlOKigQR3v
TZCK45MNSaI7/bOI1x/3qvC2tM1GLLZGbagq3G2wc8o7isZd5SkRGpG+V+VHR6FF
xBaez/46Quazx+I4LLCNvt+sXrFFMONbZZIMq6r1I56gvTSgCgTuvAgh6HK2kYMK
qWmKHQ/W3xMxPmbrOV5m7K+zUGrQqZdghOkoFXeg+OHu86CX97G/e7J+KfLYvyF0
K64LM+tcOGIGYDrhAswmmw==
-----END CERTIFICATE-----

Comment 1

[Kathleen Wilson]

Accepting this bug, and starting the Information Gathering and Verification
phase:
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

Comment 2

[Kathleen Wilson]

Attachment: ANF Root Cert

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 4

[Kathleen Wilson]

I'd like to call attention to one particular item, because I have never seen this happen before. Maybe someone who sees this will have an idea what would cause it...

Manually import the root certificate (attached to this bug) into Firefox or Thunderbird, then view the cert from the Cert Manager and click on Details. The Certificate Hierarchy shows a long list of “ANF Server CA” root certificates.

Comment 5

[Kaspar]

Attachment: Patch for preventing a CERT_GetCertChainFromCert loop

(In reply to comment #4)
> The Certificate Hierarchy shows a long list of “ANF Server CA” root
> certificates.

It's another case where CERT_GetCertChainFromCert() goes into a loop (which is terminated after 20 iterations thanks to the fix from bug 477186).

Looking at the cert's properties, this is due to a partly "broken" way of how the authorityKeyIdentifier is encoded, which has the following value:

        Name: Certificate Authority Key Identifier
        Key ID:
            be:3b:f6:b4:31:b7:73:24:48:39:c5:57:13:94:75:aa:
            9f:81:3f:2c
        Issuer:
            Directory Name: "CN=ANF Server CA,serialNumber=G-63287510,OU=ANF
                Clase 1 CA,O=ANF Autoridad de Certificacion,L=Barcelona (see
                current address at https://www.anf.es/address/ ),ST=Barcelona
                ,C=ES"
        Serial Number: 78923 (0x1344b)

Some RDNs of the authorityCertIssuer ("Directory Name") field have a different ASN.1 encoding than the one in the issuer DN field, unfortunately: CN, OU, O and ST are encoded as PrintableString, while they appear as UTF8String in the issuer DN.

One might argue that this an encoding error in the certificate and do nothing about it, but I think a small change to modification certdb.c:cert_IsRootCert() would make sense: if we have a match for the keyIdentifier, then consider this a sufficient check for determining whether it's a root certificate or not (and do not insist on additional checks for authorityCertIssuer/authorityCertSerialNumber - note that the primary purpose of the AKID extension is to provide "a means of identifying the public key corresponding to the private key used to sign a certificate", not to indicate if it's a root cert or not).

I'm attaching a patch implementing this change. Nelson, should a separate (NSS) bug be filed for this?

Comment 6

[Kathleen Wilson]

Kaspar, Thank you for your quick response in figuring this out and recommending the solution. I greatly appreciate it! 

I have filed bug #556792 for the patch.

Comment 7

[Kathleen Wilson]

Carlos, Please see Comment #3 and provide your response to the Initial Information Gathering document that has been attached.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

> One might argue that this an encoding error in the certificate and do 
> nothing about it,

That would be my recommendation.  I don't believe we should be quick to 
change Mozilla software to compensate for every error made by every CA.
Make the CA correct its own error.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Alternate ANF root certificate

Here's a slightly different ANF root certificate that works in Firefox 
without any modifications to firefox and doesn't cause the loop previously
reported.  Try it.  You'll like it.  :)

Comment 10

[Kathleen Wilson]

Thanks Nelson, that cert is much better. Can I just use your attachment as the root cert?  Or does the CA need to do something to fix it on their end?

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

No, don't use that cert. 

I just realized that I did exactly the wrong thing when I made that cert.  
I changed the AKID to match the issuer name.  I should have changed the 
issuer name to match the AKID.  d'oh!  If I had done it the right way,
ANF's existing root cert would become a perfectly valid roll-over cert.
It would be able to co-exist with the other fake root cert without any 
duplicate issuer name/serial number problem.  That may actually be a 
reasonable solution.  I'll do that, but probably not until the coming weekend.

Of course, the most reasonable solution would be for this CA to issue a 
root CA cert that wasn't flawed in this way.

Comment 12

[Isabel Fabregas]

(In reply to comment #11)
> No, don't use that cert. 
> I just realized that I did exactly the wrong thing when I made that cert.  
> I changed the AKID to match the issuer name.  I should have changed the 
> issuer name to match the AKID.  d'oh!  If I had done it the right way,
> ANF's existing root cert would become a perfectly valid roll-over cert.
> It would be able to co-exist with the other fake root cert without any 
> duplicate issuer name/serial number problem.  That may actually be a 
> reasonable solution.  I'll do that, but probably not until the coming weekend.
> Of course, the most reasonable solution would be for this CA to issue a 
> root CA cert that wasn't flawed in this way.

You are completely right, the problem described in last comments is caused by a bad use of extension AuthorityKeyIdentifier. This certificate has passed a lot of test and nobody before had realized. 
We have reissued our CA certificate for solving this problem, the new certificate used the same public key and serial number. Below you can find the new certificate in PEM format.

-----BEGIN CERTIFICATE-----
MIIGnTCCBYWgAwIBAgIDATRLMA0GCSqGSIb3DQEBBQUAMIHZMQswCQYDVQQGEwJF
UzESMBAGA1UECAwJQmFyY2Vsb25hMUcwRQYDVQQHDD5CYXJjZWxvbmEgKHNlZSBj
dXJyZW50IGFkZHJlc3MgYXQgaHR0cHM6Ly93d3cuYW5mLmVzL2FkZHJlc3MvKTEo
MCYGA1UECgwfQU5GIEF1dG9yaWRhZCBkZSBDZXJ0aWZpY2FjacOzbjEXMBUGA1UE
CwwOQU5GIENsYXNlIDEgQ0ExEjAQBgNVBAUTCUc2MzI4NzUxMDEWMBQGA1UEAwwN
QU5GIFNlcnZlciBDQTAeFw0wOTExMzAyMzAwMDBaFw0yMTExMzAyMzAwMDBaMIHZ
MQswCQYDVQQGEwJFUzESMBAGA1UECAwJQmFyY2Vsb25hMUcwRQYDVQQHDD5CYXJj
ZWxvbmEgKHNlZSBjdXJyZW50IGFkZHJlc3MgYXQgaHR0cHM6Ly93d3cuYW5mLmVz
L2FkZHJlc3MvKTEoMCYGA1UECgwfQU5GIEF1dG9yaWRhZCBkZSBDZXJ0aWZpY2Fj
acOzbjEXMBUGA1UECwwOQU5GIENsYXNlIDEgQ0ExEjAQBgNVBAUTCUc2MzI4NzUx
MDEWMBQGA1UEAwwNQU5GIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAL/qSKeaiDlrLEhABwSTfPe4LX6lN+Jh1iH8kDfLaT5eizffW287
2LbDiECQ9J0MXBBSsbPlX5EQ5v2ogBRf04u9XL0PI5IJN+Ny0maUC1x0lC9e8k7Y
A8azzlalHNl7/U8HTNS32l8pTXXyH1XPMiMcRgknHUXs8Yw0id57FqdDXoor6ZRD
Htc+k21viT287rHIt//JfeNfDW93ePUqLo3Ei5iXMLFGWgtjcNR4x4azf/8nQqqf
im5toZTK7IcCHNZUS/28iZumYzhmjBaJiZfDUOj2QgGnd30QGZID6F1FyBXFhxsN
kfLGOZx788AKmfjug29+QncRjsMfHHIvPRsCAwEAAaOCAmowggJmMB0GA1UdDgQW
BBS+O/a0MbdzJEg5xVcTlHWqn4E/LDCCAQkGA1UdIwSCAQAwgf2AFL479rQxt3Mk
SDnFVxOUdaqfgT8soYHfpIHcMIHZMQswCQYDVQQGEwJFUzESMBAGA1UECAwJQmFy
Y2Vsb25hMUcwRQYDVQQHDD5CYXJjZWxvbmEgKHNlZSBjdXJyZW50IGFkZHJlc3Mg
YXQgaHR0cHM6Ly93d3cuYW5mLmVzL2FkZHJlc3MvKTEoMCYGA1UECgwfQU5GIEF1
dG9yaWRhZCBkZSBDZXJ0aWZpY2FjacOzbjEXMBUGA1UECwwOQU5GIENsYXNlIDEg
Q0ExEjAQBgNVBAUTCUc2MzI4NzUxMDEWMBQGA1UEAwwNQU5GIFNlcnZlciBDQYID
ATRLMAwGA1UdEwQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMDEGCisGAQQBgY8cKgYE
IxshaHR0cHM6Ly93d3cuYW5mLmVzL0FDL0FDVEFTLzc4OTIzMBgGCisGAQQBgY8c
EwEEChsIODAxLTM0MDAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRw
Oi8vd3d3LmFuZi5lcy9BQy9SQy9vY3NwMGMGA1UdHwRcMFowK6ApoCeGJWh0dHBz
Oi8vd3d3LmFuZi5lcy9BQy9BTkZTZXJ2ZXJDQS5jcmwwK6ApoCeGJWh0dHBzOi8v
Y3JsLmFuZi5lcy9BQy9BTkZTZXJ2ZXJDQS5jcmwwFgYDVR0SBA8wDYELaW5mb0Bh
bmYuZXMwFgYDVR0RBA8wDYELaW5mb0BhbmYuZXMwDQYJKoZIhvcNAQEFBQADggEB
ALXGx7xG+kJcE8GUdTNWvy+nB3PsN+NDdOr5Zk9ejX/w5nnDTfXZOKXMykP0U4CG
v7zQEV2QxMJAR+vFh5PBtnhemq6H9WIQWUxMbQa+mRMVs7P6HHJ+4CIhAVg1OGii
5Pjh8PA2UJHgtHfcY4QzkmC4yxby0mM7TFw1OuesAlPFHIEBd8ccER9UMO9UjyX6
iSeUNKMPFE9v6XPZGGLn7gjoyYN7yDObfESafBqQtdJxid899BxPTlHgyWu2qgse
2TAP02PV7XD0wYPtBkWaqOq0iTf9WjdH75F5pzX/8Nww7Q0UZ9t8WuCPbTP+PJ4V
M8PDLQ5dqnwNjjGWTYv/BdU=
-----END CERTIFICATE-----

Comment 13

[Isabel Fabregas]

(In reply to comment #3)
> Created an attachment (id=436539) [details]
> Initial Information Gathering Document
> The attached document summarizes the information that has been gathered and
> verified.
> The items highlighted in yellow indicate where further information or
> clarification is needed. Please review the full document for accuracy and
> completeness.

Below I provide more information for the item highlighted:

Organizational type: Private corporation

Primary market/customer base: Enterprises or government agencies and employees of these entities.

The root CA certificate URL: http://www.anf.es/anf/ssl/cer/ANF_Server_CA.cer

 


http://www.anf.es/anf/ssl/cer/ANF_Server_CA.cer

Comment 14

[Kaspar]

It's good to see that the CA has reissued the cert and fixed the AKID extension (the certificatePolicies extension has been removed as well, which makes sense - but there are actually still some strange things in there, such as https CDPs or an OCSP responder URI).

(In reply to comment #10)
> Thanks Nelson, that cert is much better. Can I just use your attachment as the
> root cert

For the records: I would strongly discourage to "edit" root certs specifically for NSS and distribute them subsequently (see also bug 556792 comment 10). This would set a bad precedent; it results in self-signed certificates with broken signatures, with the additional drawback that there is no longer a single "thumbprint" (SHA-1 or whatever) to identify a particular root cert. I.e., the fingerprints of what appears to be the same root cert will differ when checking it with, let's say say, the Firefox cert manager on the one hand and the Windows cert store on the other hand.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

In response to the last paragraph of comment 14,
In RFC 3280 and 5280, the authors make a big point about trust anchors being
a special different sort of thing.  They _CAN_ and _MAY_ be represented as 
self-signed certificates, but need not be.  They don't have to be signed at 
all.  

The only reason that I have any misgivings at all about editing root certs 
is that there is still some NSS software that occasionally includes the root
cert in lists of certs that it makes, which lists of certs tend to get sent 
out by SSL servers, or SSL clients (with signatures) or in signed emails.  
If we could take the time to make sure that NSS _NEVER_ sends out root CA 
certs as part of cert chains, then I would have no more reservations about
us editing root CA certs in nssckbi.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

I haven't looked at the new root cert yet.  Hopefully it has a different 
serial number than the old one.

Comment 17

[Isabel Fabregas]

(In reply to comment #16)
> I haven't looked at the new root cert yet.  Hopefully it has a different 
> serial number than the old one.

The new root cert has the same serial number than the old one. This CA cert is a new one that will replace the one that we have been using for 6 years, but at the moment we haven't used it with real users so now we can be very flexible making changes. We will start issuing certificates before August 2010, so at this moment it will not be possible to make changes.
If it is needed to change the serial number it is possible to do it, but it would be better to keep the same serial number in order to save work.

Comment 18

[Kaspar]

(In reply to comment #15)
> In RFC 3280 and 5280, the authors make a big point about trust anchors being
> a special different sort of thing.

Yes, I know. But beyond stating that NSS can deal with self-issued, non self-signed certs as trust anchors (something I never disputed), what's the point you're trying to make? Are you seriously suggesting that in the future, if an extension in a self-signed cert creates a problem for NSS, then that cert can/should be edited before it is added to nssckbi? (Instead of either asking the CA to reissue the cert and/or fix code in NSS?)

> The only reason that I have any misgivings at all about editing root certs 
> is that there is still some NSS software that occasionally includes the root
> cert in lists of certs that it makes, which lists of certs tend to get sent 
> out by SSL servers, or SSL clients (with signatures) or in signed emails.  

You'll run into similar problems when exporting to PKCS#12 files, e.g. I still fail to see what the advantage of using a customized cert as an NSS trust anchor would be, really. All publicly distributed root certificates issued by commercial CAs in the last 15 years or so have a proper self-signature, which gives you the additional option of being able to perform a simple check for possible data corruption/tampering. What would be gained by creating NSS-customized versions of such trust anchors, compared to the chaos which could potentially arise when these certs are "leaked" to the outside world?

> If we could take the time to make sure that NSS _NEVER_ sends out root CA 
> certs as part of cert chains, then I would have no more reservations about
> us editing root CA certs in nssckbi.

You would probably be better off by defining a completely new type of object in the cert db - namely that of a trust anchor. This would also save you from using heuristics during chain building (cf. cert_IsRootCert) to determine whether a particular cert is a "root" (= trust anchor) or not.

Comment 19

[Franck Leroy]

Hello

The Root certificates includes an AKI that is not compliant to RFC 5280 :
4.2.1.1.  Authority Key Identifier
[...]
The identification MAY be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or the issuer name and serial number.


ID de la clé=be 3b f6 b4 31 b7 73 24 48 39 c5 57 13 94 75 aa 9f 81 3f 2c
Émetteur du certificat :
     Adresse d'annuaire :
          CN=ANF Server CA
          SERIALNUMBER=G63287510
          OU=ANF Clase 1 CA
          O=ANF Autoridad de Certificación
          L=Barcelona (see current address at https://www.anf.es/address/)
          S=Barcelona
          C=ES
Numéro de série du certificat=01 34 4b

So you have to choose beetween keyIdentifier or authorityCert.

An AKI is not mandatory in a root certificate; rfc 5280:
There is one exception;
   where a CA distributes its public key in the form of a "self-signed"
   certificate, the authority key identifier MAY be omitted.

Regards
Franck Leroy

Comment 20

[Kaspar]

(In reply to comment #19)
> The Root certificates includes an AKI that is not compliant to RFC 5280 :

> So you have to choose beetween keyIdentifier or authorityCert.

Can we avoid going through this discussion here? Read e.g. bug 384459 if you're interested in more details. Bottom line: it's probably one of the common mis{read,understand}ings of RFCs 2459/3280/5280. The text in that section always said "The *identification* may be based on either..." (emphasis added), not "This *extension* may either...". If the RFC authors really wanted it to make it an XOR, they could have used an ASN.1 CHOICE for the syntax - but they never did. The only additional requirement for the AKID content is the following:

    -- authorityCertIssuer and authorityCertSerialNumber shall both
    -- be present or both be absent

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 17, and for Kathleen's benefit, If the first root cert 
that was submitted for Firefox to include (the one in comment 0 above) is 
in widespread use, and users have already manually imported it into their 
browsers to make certs issued by this CA work in their browser, then it 
will not be acceptable for Mozilla to now take a newer root CA cert WITH 
THE SAME ISSUER NAME AND SAME SERIAL NUMBER but not otherwise identical 
and include it in Firefox.  

If the world gets into a state where there are two different certs in use 
with the same issuer name and same serial number, Firefox will give a LOT
of errors to its users about those different certs with duplicated issuer
names and serial numbers.  

If that previous copy of the root has been given out to more than (say) 10
users, then you must put a NEW serial number into your new root certificate
for it to be acceptable to Firefox.

In reply to comment 19: I agree completely.

In reply to comment 20: Kaspar, as you know, the ASN.1 syntax for certs comes from ITU X.509.  It appears that, as you say, the ITU X.509 authors did not
intend for the keyIdentifier to be mutually exclusive with the authority Cert. But the IETF RFCs exist to define a PROFILE, which is a subset of the full 
set defined by X.509, a subset that is acceptable to the IETF.  That subset 
is defined such that those two fields ARE mutually exclusive, IMO.

IINM, RFC 5280 also indicates that a root CA cert should not have a AKID at 
all.  I would strongly prefer that any new root CA cert from this CA company
not include any AKID extension at all.

Comment 22

[Kaspar]

(In reply to comment #21)
> It appears that, as you say, the ITU X.509 authors did not
> intend for the keyIdentifier to be mutually exclusive with the authority Cert.

No, that's what I'm saying. I wrote "the *RFC* authors...", and I meant the RFC authors (the PKIX WG), not the ITU people. I you look at the evolution of RFC 2459 (e.g. at http://tools.ietf.org/html/draft-ietf-pkix-ipki-part1-02, where the AKID section first appeared), then it becomes clear that the PKIX WG never had the intention of disallowing the presence of both keyIdentifier and (authorityCertIssuer, authorityCertSerialNumber) in that extension.

Again: IMO, it's one of the common mis{read,understand}ings of RFCs 2459/3280/5280. The text (of that cert PROFILE, yes) says: "The identification may be based on...". That NSS chose to implement this as a mutually exclusive option should be considered an accident in history.

> IINM, RFC 5280 also indicates that a root CA cert should not have a AKID at 
> all.

It says in section 4.2.1.1.:

   The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction.  There is one exception;
   where a CA distributes its public key in the form of a "self-signed"
   certificate, the authority key identifier MAY be omitted.

This can hardly be read as "a self-signed certificate SHOULD not include an authorityKeyIdentifier extension".

Comment 23

[Kathleen Wilson]

Thanks to all of you for your help with this.

Carlos, Please respond to Comment 21: If that previous copy of the root has been given out to more than (say) 10 users, then you must put a NEW serial number into your new root certificate for it to be acceptable to Firefox.

Comment 24

[Isabel Fabregas]

(In reply to comment #23)
> Thanks to all of you for your help with this.
> Carlos, Please respond to Comment 21: If that previous copy of the root has
> been given out to more than (say) 10 users, then you must put a NEW serial
> number into your new root certificate for it to be acceptable to Firefox.

This new certificate hasn't still be in use with real users, we have only passed some test with the Spanish government. As you have found a new problem not detected in previous tests we have fixed this problem in the same certificate (with equal SerialNumber and Public Key). So at the moment no users have a copy of this ROOT certificate, as soon as we get the approval from Mozilla and other entities we will start to use this new Root CA with our customers.

Comment 25

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Please review the full document for accuracy and completeness. The items highlighted in yellow indicate where further information or clarification is needed.

Comment 26

[Kaspar]

Comment on attachment 436650 [details] [diff] [review]
Patch for preventing a CERT_GetCertChainFromCert loop

Marking obsolete, further discussions have taken place in bug 556792.

Comment 27

[Kathleen Wilson]

Removing dependency on bug 556792.

Carlos, please see Comment #25. We may proceed when you review the Updated Information Gathering Document for accuracy, and provide the information/clarification as per the highlighted sections of the document.

Comment 28

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 436519 [details]
ANF Root Cert

Is this the root cert that is being requested?
Or has a newer one been issued?

Comment 29

[Nelson Bolyard (seldom reads bugmail)]

Attachment: YA Alternate ANF Root

The cert in the first attachment to this bug should act as a roll-over cert
to this one, which is a real root (with fake signature). 
This is for my test.

Comment 30

[Nelson Bolyard (seldom reads bugmail)]

Attachment: ANF Rollover cert

YA test cert, should roll-over to YA Alternate ANF Root

Comment 31

[Isabel Fabregas]

Hi nelson,

Let me introduce myself, I have recently joined the company ANF AC, and one of my tasks to check the status of approval of the certificate of ANF AC.

To respond to your request in order to solve the problem of of “ANF Server CA” root certificates in Mozzilla. 

•	Is this CA operated by a private or public corporation, government agency, academic institution or consortium, NGO ?





"ANF Certification Authority, is a nongovernmental organization that enjoys full political and economic independence. According to the current Law on Electronic Signatures and Directive 1999/93/EC, is a Certification Service Provider in the EU authorized to issue certificates and servicing of electronic certification.
 "

•	Which types of customers does this CA serve?
Are there particular vertical market segments in which it operates?

“AC ANF PKI is an Open System Electronic certification. Revocation lists are freely available, as is open and free distribution of electronic verification devices. There is no restriction of logged in user, not by professional profile, or by geographical area”

(In reply to comment #25)
> Created attachment 443163 [details]
> Updated Information Gathering Document
> 
> Please review the full document for accuracy and completeness. The items
> highlighted in yellow indicate where further information or clarification is
> needed.

Comment 32

[Kathleen Wilson]

(In reply to comment #31)
> Hi nelson,
> 
> Let me introduce myself, I have recently joined the company ANF AC, and one of
> my tasks to check the status of approval of the certificate of ANF AC.
> 

Please review attachment #443163 [details] and provide all of the information that is requested as per the items highlighted in yellow.  For details about the information that is needed, see https://wiki.mozilla.org/CA:Information_checklist

Comment 33

[Isabel Fabregas]

Hi,

In the summary 555156-InfoGathering.pdf of Add ANF root certificate (55156), you indicate in the AUDIT that we must send a letter from an auditor (who meets the policy requirements)that states that they have
reviewed the practices as outlined in the CP/CPS for these roots, and that the CA does indeed follow these practices and
meets the requirements of one of:
 ETSI TS 101 456
 ETSI TS 102 042
 WebTrust Principles and Criteria for Certification Authorities

So, we attached the first one AUDIT_ETSI_101_456.pdf

Comment 34

[Isabel Fabregas]

Attachment: letter of AUDIT_ETSI_101_456

We publish a statement from an auditor (who meets the policy requirements) of ETSI 101 456

Comment 35

[Kathleen Wilson]

Thank you for the audit statement. Does the auditor have a website and/or verifiable qualifications? Please provide verifiable information showing that this auditor meets the requirements of #10 and #11 of 
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Comment 36

[Isabel Fabregas]

Yes It 's honesty and objective and an independent part


(In reply to comment #35)
> Thank you for the audit statement. Does the auditor have a website and/or
> verifiable qualifications? Please provide verifiable information showing
> that this auditor meets the requirements of #10 and #11 of 
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Comment 37

[Isabel Fabregas]

Hi kathleen wilson, See attached the SSL of ANF Autorithy Certification PC_SSL_Sede_v1.1.pdf (English Spanish)

Comment 38

[Isabel Fabregas]

Attachment: Certificate Policy Certificate SSL (Spanish)

Comment 39

[Kathleen Wilson]

In regards to the auditor...
Is http://www.inledis.com the correct url for the auditor?
What is the organizational relationship between Inledis and ANF?

In regards to the CP/CPS documents, please provide the names and corresponding URLs of the relevant documents (as available on your website) for the pending page http://www.mozilla.org/projects/security/certs/pending/#ANF

Comment 40

[Isabel Fabregas]

Dear Kathleen,

In relation to the open procedure Bugzilla ID: 555156 Bugzilla Summary: Add ANF root certificate, inform you that we are developing the attending relevant document all queries. 

As for the relationship between ANF Certification Authority (ANF AC) and Engineering Company Legality Digital, SL (INLEDIS), we reported the following: 

1 / There is no shareholding relationship (independent relationship) between ANF Certification Authority e INLEDIS. 
2 / relationship with INLEDIS is based in the following: 

a) INLEDIS is the company that ANF AC hired in 2009, to conduct the audit following the Trust and CAB Web guides / FORUM (Audit released in January 2010). 
b) ANF AC in the month of May 2010 expanded the relationship with INLEDIS signing an agreement of collaboration, so the services of INLEDIS can be used by 
ANF AC customers, and therefore including services INLEDIS in the portfolio of ANF AC. 

In 2010 ANF AC hired a new business services audit. As outlined at the beginning of this writing, our response to your request Bugzilla ID: 555156 will provide information that addresses each of 
issues made by you and a copy of the last audit. 

We appreciate your interest our application, we expect information and documentation in I will refer briefly attend properly open procedure. 

Sincerely, 



(In reply to comment #39)
> In regards to the auditor...
> Is http://www.inledis.com the correct url for the auditor?
> What is the organizational relationship between Inledis and ANF?
> 
> In regards to the CP/CPS documents, please provide the names and
> corresponding URLs of the relevant documents (as available on your website)
> for the pending page
> http://www.mozilla.org/projects/security/certs/pending/#ANF

Comment 41

[Moisés Amador]

Dear Kathleen,

I am Moises Amador, from ANF Autoridad de Certificación. One of my current tasks is to manage international approvals and certifications.

On behalf of ANF Autoridad de Certificación, let me apologize for a year and a half of silence.
In the latest months we have improved our infrastructure, platform, products and services, and we have obtained various certifications such as WebTrust, ISO 9001 and ISO 27001.

Partly due to these changes, important data of the CA has been modified, such as reference URLs and public documents, which I will forward to you in the near future.

Besides updating this information, we would like to know any revelant details needed to complete the final part of our inclusion into the Mozilla project Root CA store.

Comment 42

[Kathleen Wilson]

Dear Moisés,

Since it has been so long, and it sounds like much of the information has changed, perhaps it will be most expedient to start fresh with the current CA Information Template, https://wiki.mozilla.org/File:CAInformationTemplate.pdf
It corresponds to the checklist of needed information
https://wiki.mozilla.org/CA:Information_checklist
Please fill in the information and attach it to this bug.

Also, please see the recent CA Communications: 
https://wiki.mozilla.org/CA:Communications
and provide responses to the 2012 and 2013 communications in this bug.

Comment 43

[Moisés Amador]

Attachment: Updated Information Gathering Document

Comment 44

[Kathleen Wilson]

Thank you for completing the information gathering document. That is very helpful.

Regarding test cert -- I only need a URL to a website whose SSL cert chains up to this root. It can be a test website, or a real website; whichever is easiest for you.

2) EV treatment -- I see that you have a current EV audit statement. Do you want to include EV-enablement in this request?

3) I cannot find the "CP SSL Certificates (English)" document on the website. I was able to find the other documents, and the Spanish version of this document. Please send me the correct URL for the English version of the document.

Comment 45

[Moisés Amador]

Our answers:

2) EV treatment -- I see that you have a current EV audit statement. Do you want to include EV-enablement in this request?

Our idea was to include this statement in a second phase, since the issuance of SSL EV certificates will be made from a another Root CA (ANF Global Root CA). Should we include this Root CA now, in the same process, to have both accreditations at the same time? 

3) I cannot find the "CP SSL Certificates (English)" document on the website. I was able to find the other documents, and the Spanish version of this document. Please send me the correct URL for the English version of the document.

The English versions of our main documents have been updated at the http://www.anf.es/en website. Please download them again, as you probably have previous versions of CPS and Certificate Policies.

Comment 46

[Kathleen Wilson]

Attachment: Updated CA Information Document

A couple of items still to be resolved - they are highlighted in yellow in the attached document.

Comment 47

[Kathleen Wilson]

(In reply to Moisés Amador from comment #45)
> Our idea was to include this statement in a second phase, since the issuance
> of SSL EV certificates will be made from a another Root CA (ANF Global Root
> CA). Should we include this Root CA now, in the same process, to have both
> accreditations at the same time? 

If the EV Root is ready (and test website available), it can be added to this request. Otherwise, we can just proceed with the current root inclusion request and you can open another request for the other root later.

Comment 48

[Moisés Amador]

Hi,

The website with the certificate SSL:
kerberosns.com

The website with the certificate SSL EV:
anf.kerberosns.com

Comment 49

[Moisés Amador]

Attachment: Information Gathering Document

Information Gathering Document "ANF Global Root CA"

Comment 50

[Moisés Amador]

Finally ANF Autoridad de Certificación has decided that the Root CA "ANF Global Root CA" is both the issuing SSL certificates as EV SSL. I add a new document about "ANF Global Root CA". Please, check it, thanks.

Comment 51

[Kathleen Wilson]

Need to clarify...  Is this request for inclusion of the following 3 root certs?
http://www.anf.es/es/certificates_download/ANF_Server_CA.cer
http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA1.cer
http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer

If yes, please provide the urls to 3 different test websites, with the SSL certs chaining up to each of these root certs.

For the root certs that you would like to have EV-enabled, please have the test website use an EV cert, and perform the testing described here: https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 52

[Kathleen Wilson]

Also, please choose one EV OID for each root cert that you would like to be EV-enabled.

Comment 53

[Moisés Amador]

Attachment: Information Gathering Document Updated

Comment 54

[Moisés Amador]

Finally ANF Autoridad de Certificación has decided that the Root CA "ANF Global Root CA" with SHA256 is the only issuing SSL certificates as EV SSL. I add a new document about "ANF Global Root CA".
ANF ​​Server CA issue SSL certificates, but without EV.

The URL of the EV SSL certificate issued by ANF Global Root CA:
https:/kerberosns.com/cloud

For root ANF Global Root CA's EV OID are:
1.3.6.1.4.1.18332.55.1.1.2.12
1.3.6.1.4.1.18332.55.1.1.2.22
1.3.6.1.4.1.18332.55.1.1.5.12
1.3.6.1.4.1.18332.55.1.1.5.22
1.3.6.1.4.1.18332.55.1.1.6.12
1.3.6.1.4.1.18332.55.1.1.6.22

Comment 55

[Kathleen Wilson]

Please clarify... Which of the following root certificates(s) are you hoping to get included?
1. ANF Server CA (http://www.anf.es/es/certificates_download/ANF_Server_CA.cer)
2. ANF Global Root CA SHA1 (http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA1.cer)
3. ANF Global Root CA SHA256 (http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer)

Comment 56

[Moisés Amador]

(In reply to Kathleen Wilson from comment #55)
> Please clarify... Which of the following root certificates(s) are you hoping
> to get included?
> 1. ANF Server CA
> (http://www.anf.es/es/certificates_download/ANF_Server_CA.cer)
> 2. ANF Global Root CA SHA1
> (http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA1.cer)
> 3. ANF Global Root CA SHA256
> (http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer)

Only these:

- ANF Server CA (http://www.anf.es/es/certificates_download/ANF_Server_CA.cer)
- ANF Global Root CA SHA256 (http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer)

Comment 57

[Kathleen Wilson]

(In reply to Moisés Amador from comment #56)
> Only these:
> 
> - ANF Server CA
> (http://www.anf.es/es/certificates_download/ANF_Server_CA.cer)

Please provide the URL to a website (may be a test website) whose SSL cert chains up to this root.



> - ANF Global Root CA SHA256
> (http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer)

Provided website for testing: https://kerberosns.com/cloud 
I have imported the "ANF Global Root CA SHA256" root cert into my Firefox browser, and I have OCSP set to hard-fail.
I get the following OCSP error when I try to browse to thise website:
An error occurred during a connection to kerberosns.com. The OCSP server found the request to be corrupted or improperly formed. (Error code: sec_error_ocsp_malformed_request) &f=regular

Please see https://wiki.mozilla.org/CA:Recommended_Practices#OCSP

Comment 58

[Moisés Amador]

(In reply to Kathleen Wilson from comment #57)

> > - ANF Global Root CA SHA256
> > (http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer)
> 
> Provided website for testing: https://kerberosns.com/cloud 
> I have imported the "ANF Global Root CA SHA256" root cert into my Firefox
> browser, and I have OCSP set to hard-fail.
> I get the following OCSP error when I try to browse to thise website:
> An error occurred during a connection to kerberosns.com. The OCSP server
> found the request to be corrupted or improperly formed. (Error code:
> sec_error_ocsp_malformed_request) &f=regular

It has already been fixed, please, go again.

On the other hand, I followed all the steps in
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

But file "test_ev_roots.txt" achievement not generate correctly and causes errors.
Can you help me build it?

Thanks

Comment 59

[Kathleen Wilson]

Attachment: test_ev_roots.txt

Comment 60

[Kathleen Wilson]

I'm not getting the EV treatment with https://kerberosns.com/cloud either. 

For an example of a test that works, you can try testing with the Firmaprofesional information in Bug #962740. Once you get that working (showing the green EV treatment) on your system, then change the test_ev_roots.txt information to have your info (the attached file) and close and restart NightlyDebug to test yours. (be sure to restart the browser whenever you change test_ev_roots.txt).

See https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F for ideas about what to check.

Comment 61

[Moisés Amador]

Attachment: EV Testing Result

Comment 62

[Moisés Amador]

Comment on attachment 8384578 [details]
EV Testing Result

EV treatment successfully tested

Comment 63

[Kathleen Wilson]

Trying to test, but I keep getting OCSP errors when I set OCSP to hard fail:
An error occurred during a connection to kerberosns.com. 
The OCSP server has no status for the certificate. 
(Error code: sec_error_ocsp_unknown_cert)


Few other questions:

What URL should I use for the test website for the "ANF Server CA" root?

What is the status of an audit according to the CA/Browser Forum's Baseline Requirements criteria?

SSL CP, section 4.2.2.1: The IRM shall check the documentation by consulting the whois database, verifying that the domain is registered, by consulting valid registrars. A copy of the whois query is attached to the validation act.
Is the IRM always an employee of ANF? Where is it documented who an IRM can be for issuance of SSL certs?

Comment 64

[Moisés Amador]

(In reply to Kathleen Wilson from comment #63)
> Trying to test, but I keep getting OCSP errors when I set OCSP to hard fail:
> An error occurred during a connection to kerberosns.com. 
> The OCSP server has no status for the certificate. 
> (Error code: sec_error_ocsp_unknown_cert)

Try it again now please, now it's fine.

> Few other questions:
> 
> What URL should I use for the test website for the "ANF Server CA" root?

https://anf.kerberosns.com/en/

> What is the status of an audit according to the CA/Browser Forum's Baseline
> Requirements criteria?

Approved: https://cert.webtrust.org/ViewSeal?id=1626

> SSL CP, section 4.2.2.1: The IRM shall check the documentation by consulting
> the whois database, verifying that the domain is registered, by consulting
> valid registrars. A copy of the whois query is attached to the validation
> act.
> Is the IRM always an employee of ANF? Where is it documented who an IRM can
> be for issuance of SSL certs?

CPS, section 1.3.1.4 Issuance Report Managers
These are staff attached to ANF AC's Legal Department.

CPS, section 5.2.1.8 Issuance reports and certificates revocation manager
They are required to have worked at least one year in a related role.

Comment 65

[Moisés Amador]

Have you tried the EV SSL certificate?
The error you saw, was corrected by reinstalling the certificate.
If I can help with anything else, please let me know.

Comment 66

[Kathleen Wilson]

(In reply to Moisés Amador from comment #64)
> (In reply to Kathleen Wilson from comment #63)
> > Trying to test, but I keep getting OCSP errors when I set OCSP to hard fail:
> > An error occurred during a connection to kerberosns.com. 
> > The OCSP server has no status for the certificate. 
> > (Error code: sec_error_ocsp_unknown_cert)
> 
> Try it again now please, now it's fine.

Works now.

> 
> > Few other questions:
> > 
> > What URL should I use for the test website for the "ANF Server CA" root?
> 
> https://anf.kerberosns.com/en/

OK.

> 
> > What is the status of an audit according to the CA/Browser Forum's Baseline
> > Requirements criteria?
> 
> Approved: https://cert.webtrust.org/ViewSeal?id=1626

This appears to be a new WebTrust for EV audit statement. Do you also have a new WebTrust for CA audit statement? (the one I have is https://cert.webtrust.org/SealFile?seal=1449&file=pdf)

Also need a WebTrust for BR audit statement. (http://www.webtrust.org/homepage-documents/item72056.pdf)
It can be in the same document as the WebTrust for CA audit statement.



> 
> > SSL CP, section 4.2.2.1: The IRM shall check the documentation by consulting
> > the whois database, verifying that the domain is registered, by consulting
> > valid registrars. A copy of the whois query is attached to the validation
> > act.
> > Is the IRM always an employee of ANF? Where is it documented who an IRM can
> > be for issuance of SSL certs?
> 
> CPS, section 1.3.1.4 Issuance Report Managers
> These are staff attached to ANF AC's Legal Department.
> 
> CPS, section 5.2.1.8 Issuance reports and certificates revocation manager
> They are required to have worked at least one year in a related role.

Thanks.

One more thing...

Previously you listed six EV Policy OIDs, and I asked you to pick one. In the test_ev_roots.txt file you used 1.3.6.1.4.1.18332.55.1.1.2.22. Shall I assume that is the EV Policy OID you want to use?

Comment 67

[Moisés Amador]

(In reply to Kathleen Wilson from comment #66)
> (In reply to Moisés Amador from comment #64)
> > (In reply to Kathleen Wilson from comment #63)
> > > Trying to test, but I keep getting OCSP errors when I set OCSP to hard fail:
> > > An error occurred during a connection to kerberosns.com. 
> > > The OCSP server has no status for the certificate. 
> > > (Error code: sec_error_ocsp_unknown_cert)
> > 
> > Try it again now please, now it's fine.
> 
> Works now.
> 
> > 
> > > Few other questions:
> > > 
> > > What URL should I use for the test website for the "ANF Server CA" root?
> > 
> > https://anf.kerberosns.com/en/
> 
> OK.
> 
> > 
> > > What is the status of an audit according to the CA/Browser Forum's Baseline
> > > Requirements criteria?
> > 
> > Approved: https://cert.webtrust.org/ViewSeal?id=1626
> 
> This appears to be a new WebTrust for EV audit statement. Do you also have a
> new WebTrust for CA audit statement? (the one I have is
> https://cert.webtrust.org/SealFile?seal=1449&file=pdf)
> 
> Also need a WebTrust for BR audit statement.
> (http://www.webtrust.org/homepage-documents/item72056.pdf)
> It can be in the same document as the WebTrust for CA audit statement.

New WebTrust for CA audit statement:

https://cert.webtrust.org/SealFile?seal=1625&file=pdf

> > > SSL CP, section 4.2.2.1: The IRM shall check the documentation by consulting
> > > the whois database, verifying that the domain is registered, by consulting
> > > valid registrars. A copy of the whois query is attached to the validation
> > > act.
> > > Is the IRM always an employee of ANF? Where is it documented who an IRM can
> > > be for issuance of SSL certs?
> > 
> > CPS, section 1.3.1.4 Issuance Report Managers
> > These are staff attached to ANF AC's Legal Department.
> > 
> > CPS, section 5.2.1.8 Issuance reports and certificates revocation manager
> > They are required to have worked at least one year in a related role.
> 
> Thanks.
> 
> One more thing...
> 
> Previously you listed six EV Policy OIDs, and I asked you to pick one. In
> the test_ev_roots.txt file you used 1.3.6.1.4.1.18332.55.1.1.2.22. Shall I
> assume that is the EV Policy OID you want to use?

Finally we choose the EV OID:
1.3.6.1.4.1.18332.55.1.1.2.22

Thanks,

Comment 68

[Kathleen Wilson]

Thanks.

I'm still not finding the BR audit statement.

https://wiki.mozilla.org/CA:CertificatePolicyV2.1
"Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. Note that the CA's first Baseline Requirements audit may be a Point in Time audit."

http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
section 11: WebTrust "Principles and Criteria for Certification Authorities 2.0" or later and "SSL Baseline Requirements Audit Criteria V1.1" (as applicable to SSL certificate issuance) in WebTrust Program for Certification Authorities;

http://www.webtrust.org/homepage-documents/item72056.pdf

Comment 69

[Moisés Amador]

We are taking the necessary steps and we will soon have a favorable report.
When I have this, I'll introduce you.

Just a question: 
Did this audit would be the last step to be accepted in Mozilla?
Please, if any other requirement are necessary, Can you tell us?

thanks

Comment 70

[Moisés Amador]

Attachment: BR audit

BR audit

Comment 71

[David E. Ross]

(In reply to Moisés Amador from comment #69)
> Just a question: 
> Did this audit would be the last step to be accepted in Mozilla?
> Please, if any other requirement are necessary, Can you tell us?
> 
> thanks

After Kathleen Wilson reviews the content of the audit report and determines that ANF Autoridad de Certificación complies with Mozilla policies, your request will be subjected to a public review-and-comment period of approximately two weeks.  You will be expected to respond to any comments during that period.  

After that, installation of your root certificate should occur with the next following release of Mozilla products.  That is, no special installation will occur; instead, installation occurs within the normal cycle of product releases.

Comment 72

[Moisés Amador]

Hello,

Is there anything left for us?, Or just have to wait for our request will be subjected to a public review-and-comment period of approximately two weeks?

regards,

Comment 73

[Moisés Amador]

Hello,

Is there any pending action on our part?

regards,

Comment 74

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 75

[Kathleen Wilson]

I'll try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 76

[Kathleen Wilson]

Please update this bug with your responses to the recent CA Communication,
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014

Comment 77

[Moisés Amador]

(In reply to Kathleen Wilson from comment #76)

1.- A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct. 

On page mentioning:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/
Do not appear because there appear only those that are already accredited by Mozilla.
We appear in:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/
There appear correctly:
WebTrust audit:
https://cert.webtrust.org/SealFile?seal=1625&file=pdf
Auditing WebTrust EV:
https://cert.webtrust.org/SealFile?seal=1626&file=pdf

2.- A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement. 

On page mentioning:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/
Do not appear because there appear only those that are already accredited by Mozilla.
We appear in:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/
There appears correctly:
Baseline Audit Requirements:
https://bugzilla.mozilla.org/attachment.cgi?id=8401262

3.- A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix. 

We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.

4.- A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page. 

5.- A) The information is on this page:
http://www.anf.es/es/certificados-de-ca-intermedias.html

Comment 78

[Kathleen Wilson]

I am now opening the first public discussion period for this request from ANF Autoridad de Certificación to include the “ANF Server CA” and “ANF Global Root CA” root certificates, turn on the websites trust bit for both, and enable EV treatment for the “ANF Global Root CA” certificate.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

The discussion thread is called “ANF Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of ANF must promptly respond directly in the discussion thread to all questions that are posted.

Comment 79

[Kathleen Wilson]

The first public discussion period for this request is now over.

A second public discussion period will be needed after the following action items are completed.

ACTION ANF: State (in this bug) ANF’s plan for remediation of all of the issues noted in the discussion.

ACTION ANF: Get re-audited according to https://wiki.mozilla.org/CA:BaselineRequirements and to confirm that the problems noted in the discussion have been resolved.

ACTION ANF: Provide new annual audit statements with audit scope that includes all of the root certificates in the inclusion request.

Comment 80

[Moisés Amador]

I am updating this bug with the last audits and fixed mistakes in order to accomplish all the requirements to start the second public discussion.

The three required actions have been done, in base of recommendations in the Google Groups Discussion.

The SSL and SSL EV Certificates have been reissued.
The new URI are:

SSL: https://www.kerberosns.com/booking_calendar/
SSL EV: https://ssl.anf.es/

- The Root to be included is ANF Global Root CA SHA256 http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer
- The SSL Certificate is now issued to a Private Company.
- The SSL EV Certificate is compilant with EV Guidelines, in particular with 9.2.6, the Subject Registration Number Field.
- The SAN Extension contains only valid dnsName. 
- The CRLDP is right encoded. https://www.anf.es/crl/ANF_High_Assurance_EV_CA1_SHA256.crl
- The OCSP Responder have now a 2048-bit keypair and contain the OCSPNoCheck extension.

The new Audit reports can be readed in the webtrust website:
Principles and Criteria for CA 2.0 https://cert.webtrust.org/SealFile?seal=1833&file=pdf
Principles and Criteria for CA EV 1.4.5 https://cert.webtrust.org/SealFile?seal=1834&file=pdf

Thanks,

Comment 81

[Moisés Amador]

In adittion to the last comment, the Seal #1833 contains also the Webtrust SSL BR with Network security. From the page 15 the english version.

Comment 82

[Kathleen Wilson]

Attachment: 555156-CAInformation.pdf

I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information.

Comment 83

[Moisés Amador]

The attached document has been reviewed and the information is complete and accurate.
About the troubles shown in http://certificate.revocationcheck.com/ssl.anf.es were caused by the order in which the server sent the chain. Formerly was ssl -> Root -> CA, and this application is not sorting by the Subject and Issuer DN. This issue is fixed and no longer show errors.

Now is showing a warning in the CRL that corresponds to OCSP, concerning last-modified and expires HTTP headers. The RFC5019 is about OCSP not CRL and in the RFC 5280 or the update 6818 is no reference to HTTP Cache to renew the Local CRL, and refers to the extension "nextUpdate".
Also is showing the text: "Bad signature on embedded certificate"  but there is no explicit error. The other verifications are right and the OCSP responder downloaded with the page has right signature.
LDAP CRLDP is right encoded and compliance with RFC 5280.


Please try again the test to continue with the inclusion process.

Comment 84

[Moisés Amador]

Dear Kathleen, have you any update about the last information sent?

Comment 85

[Kathleen Wilson]

Attachment: 555156-CAInformation-Complete.pdf

Comment 86

[Kathleen Wilson]

I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 87

[Moisés Amador]

Thanks Kathleen, we will be waiting for.

Comment 88

[Kathleen Wilson]

I am now opening the second public discussion period for this request from ANF to include the “ANF Global Root CA” root certificate, enable the Websites trust bit, and enable EV treatment. 

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Second Discussion of ANF Root Inclusion Request".

Please actively review, respond, and contribute to the discussion.

A representative of ANF must promptly respond directly in the discussion thread to all questions that are posted.

Comment 89

[Kathleen Wilson]

The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical]. 
I am not aware of instances where ANF has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
ANF appears to provide a service relevant to Mozilla users. ANF is a private Certification Authority, recognized and accredited by the Spanish Government as a Certificate Services Provider (CSP). ANF AC has accredited more than 1000 Registry Authorities throughout Spain to issue qualified user identity certificates. ANF CA also issues certificates for SSL with and without Extended Validation. 

This request is to include the "ANF Global Root CA" root certificate, enable the Websites trust bit, and enable EV treatment. 
	 
Root Certificate Name: ANF Global Root CA
O From Issuer Field: ANF Autoridad de Certificacion
Trust Bits: Websites
EV Policy OID: 1.3.6.1.4.1.18332.55.1.1.2.22
Root Certificate Download URL: 	http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer

Certificate Summary: This root has eight internally-operated subordinate CAs which sign end-entity certificates for individuals and organizations.

* The primary documents are the CPS and SSL CP, which are provided in Spanish and English.

Document Repository: http://www.anf.es/en/
SSL CP: https://www.anf.es/es/pdf/PC_SSL_Sede_EV_EN.pdf
CPS: https://www.anf.es/es/pdf/DPC_ANF_AC_EN.pdf

Inclusion Policy Section 18 [Certificate Hierarchy]
The "ANF Global Root CA" certificate has the following internally-operated sub-CAs:
- ANF High Assurance EV CA1 (SHA1 and SHA256): Issues technical certificates for authentication services SSL, SSL EV, Encryption and Code Signing.
- ANF High Assurance AP CA1 (SHA1 and SHA256): Issues end-entity certificates for Public Administrations.
- ANF Global CA1 (SHA1 and SHA256): Issues certificates for the management and administration of the PKI of ANF AC.
- ANF Assured ID CA1 (SHA1 and SHA256): Issues end-entity in accordance with the provisions of Electronic Signature Law 59/2003.
Externally Operated SubCAs: None. None planned.
Cross Signing: None. None planned.

Inclusion Policy Section 7 [Validation]. 
ANF appears to meet the minimum requirements for subscriber verification, as follows:

* SSL Verification Procedures: According to section 4.2.2.1 of the SSL CP, domain control validation is done by consulting the whois database, and verifying that the domain is registered by consulting valid registrars. A copy of the whois query is attached to the validation act. Additional EV SSL verification procedures are described in section 4.2.2.3 of the SSL CP.

Email Verification Procedures: 	Not requesting Email trust bit.

Code Signing Subscriber Verification Procedure: 	Not applicable; Mozilla is no longer enabling the code signing trust bit for root certs.

Certificate Revocation
CRL URLs: https://www.anf.es/crl/ANF_Global_Root_CA_arl.crl
https://www.anf.es/crl/ANF_High_Assurance_EV_CA1_SHA256.crl
NextUpdate for End-entity CRLs: 7 days
OCSP URL: http://ocsp.anf.es/spain/AV

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by Auren, according to the WebTrust criteria.
Standard Audit: https://cert.webtrust.org/SealFile?seal=1833&file=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=1833&file=pdf
EV Audit: https://cert.webtrust.org/SealFile?seal=1834&file=pdf

Based on this assessment I intend to approve this request from ANF to include the "ANF Global Root CA" root certificate, enable the Websites trust bit, and enable EV treatment.

Comment 90

[Ryan Sleevi]

Kathleen, apologies that I missed the public comment period.

I cannot find evidence that ANF has completed the requested tasks from the first comment period. Nor can I understand how their auditor will have accepted their roots - or their policy document - as compliant to the Baseline Requirements.

Based on both https://www.anf.es/es/pdf/DPC_ANF_AC_EN.pdf and http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer , it can be clearly demonstrated that ANF has not adhered to the Baseline Requirements.

The aforementioned root has a number of subjectAltNames not permissible by the Baseline Requirements, Version 1.3.1, Section 7.1.4.2.1, which are requirements which apply to all certificates. Further, the encoding of the dNSName subjectAltName is, as previously mentioned, incorrect (it's a URL). Of course, there's no reason for CA certificates to even include subjectAltNames to begin with.

Similarly, this certificate fails to adhere to 7.1.4.2.2's requirements with respect to the encoding of the certificate name: the localityName contains a URL (not permitted by the BRs).

ANF does not appear to have responded, as requested in https://bugzilla.mozilla.org/show_bug.cgi?id=555156#c79 , to the issues summarized at https://groups.google.com/d/msg/mozilla.dev.security.policy/cNgy1_rkv6A/zwm4NcliSX8J

Given the state of the root requested, and as documented in the CPS, I would strongly encourage Mozilla to reject this request outright, as this root cannot comply with Mozilla's requirements. Should ANF wish to request inclusion, with a new root certificate, I would strongly encourage Mozilla to require a new auditor, given that these issues are themselves documented by ANF within their CP and trivial to determine as non-compliant. As the auditor failed to detect these very basic issues, I do not believe we, the community, can be reasonably assured of any of the auditor's necessary checks.

If I've missed something very basic, and this is merely an information gathering snafu, I apologize. But I'm basing off the summary of information gathered at https://bugzilla.mozilla.org/show_bug.cgi?id=555156#c89 and cannot find evidence to support ANF's inclusion from it.

Comment 91

[Kathleen Wilson]

In addition to Comment #90...

We recently added two tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Output for Test1:
ERROR: DNSName is not FQDN

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
Using certificate chain from 'https://ssl.anf.es/'

Using certificate from local file 'ANFGlobalRootCA.pem'

    /OU=Certificado Servidor Seguro SSL EV/SN=DIAZ VILCHES/GN=FLORENCIO/emailAddress=[e-mail]/L=BARCELONA/ST=BARCELONA/C=es/CN=webtest.anf.es/O=ANF AUTORIDAD DE CERTIFICACION ASOCIACION/serialNumber=G63287510/name=FLORENCIO DIAZ VILCHES/businessCategory=Business Entity/1.3.6.1.4.1.311.60.2.1.3=es
        Notice ...
        Warning ...
        Error
            1.3.6.1.4.1.311.60.2.1.3 must be PrintableString
            Unknown Extension: 1.3.6.1.4.1.18332.10.1
            Unknown Extension: 1.3.6.1.4.1.18332.10.2
            Unknown Extension: 1.3.6.1.4.1.18332.10.3
            Unknown Extension: 1.3.6.1.4.1.18332.10.4
            Unknown Extension: 1.3.6.1.4.1.18332.19
            Unknown Extension: 1.3.6.1.4.1.18332.47.1
            BR certificates may not contain email type alternative names
~~

Please add a comment in this bug when the errors have been resolved.

Comment 92

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #91)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/

Comment 93

[Auren]

Dear Mozilla Community, 

This is an unofficial statement from the Auditor Team  in AUREN in order to clarify certain points discussed on this thread:

Mr. Ryan Sleevi noted in this thread some “issues” regarding the Baseline Requirements version 1.3.1, in order to clarify them from our point of view, it’s important to remark two previous considerations:

-First of all, note that our audit report was issued on January 2015 (i.e. report is more than one year old) and the above BR version was not published until September 2015. On our audit report date the BR version published was the 1.2.3 version.

-Secondly, our “BR audit” was conducted based on the “WebTrustSM/TM for Certification Authorities WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2.0  Based on: CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates – Version 1.1.6 AND Network and Certificate Systems Security Requirements – Version 1.0”. This Principles and Criteria published by CPA Canada states: “The CA/Browser Forum may periodically publish updated versions of the SSL Baseline Requirements and Network and Certificate Systems Security Requirements. The auditor is not required to consider these updated versions until reflected in the subsequently updated audit criteria.” However we, as auditors, try to evaluate the frequent changes of the CA/B Forum documents in order to conduct our audits in a more up-to-date vision, although we are not required to.

Regarding the issues noted by Mr. Ryan Sleevi:

- “[…] fails to adhere to 7.1.4.2.2's requirements with respect to the encoding of the certificate name: the localityName contains a URL (not permitted by the BRs)”. 

o The Section 7.1.4.2.2 regarding the localityName states “Contents: If present, the subject:localityName field MUST contain the Subject’s locality information as verified under Section 3.2.2.1.”. The root certificate mentioned has the following content “L = Barcelona (see current address at http://www.anf.es/es/address-direccion.html )”, so it contains the Subject’s locality as required. Regarding the encoding, RFC 5280 permits UTF8String for X520LocalityName as is encoded in this certificate. Perhaps we have missed something, but we consider this format it’s acceptable (because it’s not prohibited) although a localityName indicating just “Barcelona” will be better.

- “[…] root has a number of subjectAltNames not permissible by the Baseline Requirements, Version 1.3.1, Section 7.1.4.2.1, which are requirements which apply to all certificates. Further, the encoding of the dNSName subjectAltName is, as previously mentioned, incorrect (it's a URL). Of course, there's no reason for CA certificates to even include subjectAltNames to begin with.”

o Regarding the last sentence, although may be no apparent reason for CA certificates to include subjectAltName, this is not forbidden by BR. As example, other CAs included in Mozilla also includes SAN on its root certificate similar to ANF.

o Regarding the number of subjectAltNames not permissible by the BR, this was discussed in Cabforum by other CA in Spain due there are requirements for “sede electronica” certificates (SSL) to include in SAN more fields than the dNSName or iPAddress and as far as we remember this approach was accepted.
Regarding the encoding of the dNSName we can accept this is a minor audit errata that in any case does not affect the security or operations of ANF due the use of SAN in a CA certificate so we could classify it as non-material.

In any case we have opened a Non Conformity in our Internal Audit Management System in order to take Corrective actions in the future, by example including the use of new automated tools including those listed by Ms. Kathleen Wilson, to improve our audit process. (Note that failures are related with the fact that auditors are human beings, and are mitigated by the audit process, controls, and tools we are continuously improving, in this case the above mentioned tools in this thread were not available one year ago). 

Due the comments above in order to clarify the issues noted, we consider that the comment of Mr. Ryan Sleevi stating that “I do not believe we, the community, can be reasonably assured of any of the auditor's necessary checks” it’s not based on evidence. 

We as auditors have the procedures, qualified personal and skills to perform those audits, as we’re doing the last 10 years in this and our former jobs. Any of our audit engagements involves a multidisciplinary team of qualified professionals doing thousands of verifications, and could not be discarded by such a minor errata. (By example, it’s like we state that we should not use Mozilla, Microsoft, Google or Apple products because we found the included a minor bug in their software, and we cannot trust their programmers anymore.)

We are proud of being a part in the process of verify CAs as auditors, and we are prepared to participate openly and respectfully in this community when required, but we believe we deserve some respect to our work. Note that change of auditor does not guarantee in any case that the coming audit reports would be “perfect”, as you should know any audit process has ALLWAYS an inherent risk of missing an issue, as auditors are human and there is not perfect process or full security.

We have audited the Statements performed by the ANF Autoridad de Certificacion Management and its controls regarding its operations as Certification Authority in accordance with WebTrust requirements for the Certification Authorities, with the WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security and with WebTrust Program for Certification Authorities – Extended Validation. 

Our audit was conducted (one year ago) in accordance with standards for assurance engagements established by the CPA Canada and, accordingly, included (1) obtaining an understanding of ANF’s certificate life cycle management practices and procedures (including SSL and EV), including its relevant controls over the issuance, renewal and revocation of certificates; (2) selectively testing transactions executed in accordance with disclosed certificate life cycle management practices; (3) testing and evaluating the operating effectiveness of the controls; and (4) performing such other procedures as we considered necessary in the circumstances.

For all the above, we are sure that our audit provides a reasonable basis for our opinion and in our opinion, ANF AC management’s assertion, is fairly stated, in all material aspects, in accordance with the above mentioned WebTrust criteria. 

In any case we thank you the community, Mr. Ryan Sleevi and Ms. Kathleen Wilson for helping us to improve our audit process, and agree that all the issues should be considered and solved. 

Kind Regards, 
The Audit Team 
Auren

Comment 94

[Ryan Sleevi]

(In reply to Auren from comment #93)
> -Secondly, our “BR audit” was conducted based on the “WebTrustSM/TM for
> Certification Authorities WebTrust Principles and Criteria for Certification
> Authorities – SSL Baseline with Network Security – Version 2.0  Based on:
> CA/Browser Forum Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates – Version 1.1.6 AND Network and Certificate
> Systems Security Requirements – Version 1.0”. This Principles and Criteria
> published by CPA Canada states: “The CA/Browser Forum may periodically
> publish updated versions of the SSL Baseline Requirements and Network and
> Certificate Systems Security Requirements. The auditor is not required to
> consider these updated versions until reflected in the subsequently updated
> audit criteria.” However we, as auditors, try to evaluate the frequent
> changes of the CA/B Forum documents in order to conduct our audits in a more
> up-to-date vision, although we are not required to.

(In reply to Auren from comment #93)
> -Secondly, our “BR audit” was conducted based on the “WebTrustSM/TM for
> Certification Authorities WebTrust Principles and Criteria for Certification
> Authorities – SSL Baseline with Network Security – Version 2.0  Based on:
> CA/Browser Forum Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates – Version 1.1.6 AND Network and Certificate
> Systems Security Requirements – Version 1.0”. This Principles and Criteria
> published by CPA Canada states: “The CA/Browser Forum may periodically
> publish updated versions of the SSL Baseline Requirements and Network and
> Certificate Systems Security Requirements. The auditor is not required to
> consider these updated versions until reflected in the subsequently updated
> audit criteria.” However we, as auditors, try to evaluate the frequent
> changes of the CA/B Forum documents in order to conduct our audits in a more
> up-to-date vision, although we are not required to.

From Page 14 of the CPS

"ANF AC is set to the current version of the Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates, published onhttps://www.cabforum.org. In the event of any inconsistency
between this document and requirements, requirements have priority over this document."

From Section 2.2 of the Baseline Requirements v1.3.1 (and previously, Section 8.3 of the Baseline Requirements, v1.1.6)

"The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version."


> Regarding the issues noted by Mr. Ryan Sleevi:
> 
> - “[…] fails to adhere to 7.1.4.2.2's requirements with respect to the
> encoding of the certificate name: the localityName contains a URL (not
> permitted by the BRs)”. 

Section 9.2 of Baseline Requirements (v1.1.6)

"CAs SHALL NOT include a Domain Name in a Subject attribute except as specified in Sections 9.2.1
and 9.2.2 below"

Section 7.1.4.2 of Baseline Requirements (v.1.3.1)

"CAs SHALL NOT include a Domain Name or IP Address in a Subject	attribute except as specified in Sections 3.2.2.4 or 3.2.2.5"


> o The Section 7.1.4.2.2 regarding the localityName states “Contents: If
> present, the subject:localityName field MUST contain the Subject’s locality
> information as verified under Section 3.2.2.1.”. The root certificate
> mentioned has the following content “L = Barcelona (see current address at
> http://www.anf.es/es/address-direccion.html )”, so it contains the Subject’s
> locality as required. Regarding the encoding, RFC 5280 permits UTF8String
> for X520LocalityName as is encoded in this certificate. Perhaps we have
> missed something, but we consider this format it’s acceptable (because it’s
> not prohibited) although a localityName indicating just “Barcelona” will be
> better.

X.520 08/2005 (for which RFC 5280 is based upon) and work such as RFC 1617 make it clear what the intent for this field was. The parenthetical information "(See current address at ...)" does not represent a geographical locality, but instead represents a comment relating to that identifier. As such, it certainly falls outside the intent and documented form of this name. I'm surprised we're haggling over this intent.

> - “[…] root has a number of subjectAltNames not permissible by the Baseline
> Requirements, Version 1.3.1, Section 7.1.4.2.1, which are requirements which
> apply to all certificates. Further, the encoding of the dNSName
> subjectAltName is, as previously mentioned, incorrect (it's a URL). Of
> course, there's no reason for CA certificates to even include
> subjectAltNames to begin with.”
> 
> o Regarding the last sentence, although may be no apparent reason for CA
> certificates to include subjectAltName, this is not forbidden by BR. As
> example, other CAs included in Mozilla also includes SAN on its root
> certificate similar to ANF.
> 
> o Regarding the number of subjectAltNames not permissible by the BR, this
> was discussed in Cabforum by other CA in Spain due there are requirements
> for “sede electronica” certificates (SSL) to include in SAN more fields than
> the dNSName or iPAddress and as far as we remember this approach was
> accepted.
> Regarding the encoding of the dNSName we can accept this is a minor audit
> errata that in any case does not affect the security or operations of ANF
> due the use of SAN in a CA certificate so we could classify it as
> non-material.

It is not the place of the auditor to determine whether or not violations are "minor", and thus "acceptable".

It is the place of the auditor to determine compliance with the stated requirements, for which ANF is, by your own admission, non-compliant.

It is not a minor audit errata. It is a failure to abide by RFC 5280 and X.509, and thus a critical failure on the part of AUREN to instill confidence in the audit. Such practices by auditors have lead to an entire section of Mozilla dedicated to trying to clean up such mistakes - https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix

Item 4 of Appendix B of Baseline Requirements 1.1.6 "All other fields and extensions MUST be set in accordance with RFC 5280"

7.1.2.4 of Baseline Requirements 1.3.1 "All other fields and extensions MUST be set in accordance with RFC 5280"

> Due the comments above in order to clarify the issues noted, we consider
> that the comment of Mr. Ryan Sleevi stating that “I do not believe we, the
> community, can be reasonably assured of any of the auditor's necessary
> checks” it’s not based on evidence. 

I've provided you specific sections to demonstrate the failure to adhere to the Baseline Requirements and to Mozilla policy. Further evidence can likely be provided if warranted - I merely stopped when the failures were too bad to warrant further time investment.

Comment 95

[Enric Castillo]

First of all, I would to comment that all the errors said by Ryan Sleevi have been found in the Root Certificate, and in the Introduction of the BR 1.3.3 (Section 1.1), these requirements doesn't apply to the Root Certificate, only to certificates intended to be used for authenticating servers accessible
through the Internet. The root certificate is not issued to authenticate servers through internet, then BR is not applicable.

Secondly, the issues of the first discussion were clarified in the Comment #80 and Comment #83. They are checked by this test and is no showing more such errors.

On the other hand and emphasizing what was said by Auren, the Locality field contains the localitiy information ("Barcelona") in addition to a url that mantains updated these information. The root certificates have a life of 20 years, and as in any business, a move may occur. In this case, the Root Certificate should be revoked? Is not easier to maintain it updated with these URL? Note that adding a URL is not against the Webtrust and BR guidelines, and is only used in Root and CA certificates because these long life. In SSL and SSL EV certificates, the Locality field only contains the City.

The issue related to add more fields than the dNSName or iPAddress in SANs, is as said for Auren, a requirement in the Spanish Law to issue "Sede Electrónica" certs, that are similar to a SSL certificate but for goverment pages. This was discussed in Cabforum previously.

About the tests required in Comment #91, the errors that is showing crt.sh are about propietary extensions that are compilance with BR, according with Section 7.1.2.4, because are within the ANF oid arch, and also are described in CPS and CP.
cert-checker.allizom.org is not working right and we are not able to test our SSL Website with this tool.


In conclusion, we think that our SSL and SSL EV certificates are Webtrust, Webtrust EV and BR compilance, and the Root Certificate meets the necessary requirements and we request the inclusion of this root certificate.


Thanks,

Comment 96

[Ryan Sleevi]

(In reply to Enric Castillo from comment #95)
> First of all, I would to comment that all the errors said by Ryan Sleevi
> have been found in the Root Certificate, and in the Introduction of the BR
> 1.3.3 (Section 1.1), these requirements doesn't apply to the Root
> Certificate, only to certificates intended to be used for authenticating
> servers accessible
> through the Internet. The root certificate is not issued to authenticate
> servers through internet, then BR is not applicable.

This is deeply troubling, but equally simple.

If your root will not be used to authenticate servers through the Internet, then it does not provide a service relevant to typical users of Mozilla software products, and should not be included, per the CA Certificate Inclusion Policy.

Now, you may object to this, but that highlights precisely the point - that the root absolutely is used to authenticate servers through the Internet, because it is the root for all such certificates you issue. And while the attempt to use the Introduction is at least a meaningful response to the concerns raised, it entirely ignores that term "Root CA" appears within the Baseline Requirements v1.3.3 24 times, that the Baseline Requirements extensively sets forth requirements of Roots (4.3.1, 6.1.1.1, 6.1.5, 6.1.7, and painfully obviously, Section 7.1.2.1)

It is very clear, and unambiguous, that such policies apply.

> The issue related to add more fields than the dNSName or iPAddress in SANs,
> is as said for Auren, a requirement in the Spanish Law to issue "Sede
> Electrónica" certs, that are similar to a SSL certificate but for goverment
> pages. This was discussed in Cabforum previously.

This fails to respond to any of the concerns in any meaningful way.

Perhaps an easier way:
- Do you believe your Root CA certificate complies with RFC 5280?
- If so, can you please respond to the technical issues presented.
- If not, can you please explain how your CA hierarchy was successfully audited to comply with Baseline Requirements and with Mozilla policy?

I would suggest that, per Item 4 of the Mozilla CA Inclusion Policy, Mozilla carefully consider the significance and scope of the non-compliance, and the response from the CA indicating that they do not believe compliance is necessary. Further, I would suggest that, based on teh replies, there is question whether Item 13 is met.

Given https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/yzbAbgjvAAAJ , it does not appear that ANF meets the criteria. Nor, given the scope of the issues highlighted, that the audit from AUREN should be accepted. It should be considered, given the replies and the justification, whether requesting a new, independent audit from a competent party, which can detect and highlight these issues (which may be obscuring more serious issues in issuance practices), be identified.

Comment 97

[Ryan Sleevi]

To be sure: I have confirmed that the certificate presented in Comment #80 still fails to comply with the Baseline Requirements, and still fails to resolve the issues previously reported as resolved. This now represents several opportunities for the CA to resolve this, and repeated claims that they have. This should be reason for concern.

Comment 98

[Erwann Abalea]

(In reply to Ryan Sleevi from comment #94)
> (In reply to Auren from comment #93)
[...]
> > o The Section 7.1.4.2.2 regarding the localityName states “Contents: If
> > present, the subject:localityName field MUST contain the Subject’s locality
> > information as verified under Section 3.2.2.1.”. The root certificate
> > mentioned has the following content “L = Barcelona (see current address at
> > http://www.anf.es/es/address-direccion.html )”, so it contains the Subject’s
> > locality as required. Regarding the encoding, RFC 5280 permits UTF8String
> > for X520LocalityName as is encoded in this certificate. Perhaps we have
> > missed something, but we consider this format it’s acceptable (because it’s
> > not prohibited) although a localityName indicating just “Barcelona” will be
> > better.
> 
> X.520 08/2005 (for which RFC 5280 is based upon) and work such as RFC 1617
> make it clear what the intent for this field was. The parenthetical
> information "(See current address at ...)" does not represent a geographical
> locality, but instead represents a comment relating to that identifier. As
> such, it certainly falls outside the intent and documented form of this
> name. I'm surprised we're haggling over this intent.

For what it's worth, X.520 defines localityName as:
-----
6.3 Geographical attribute types

These attribute types are concerned with geographical positions or regions with which objects are associated.

[...]
6.3.2 Locality Name

The Locality Name attribute type specifies a locality. When used as a component of a directory name, it identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way.
-----

There's little to no place for a comment or a URL here ("geographical area", "physically located").

Comment 99

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #91)
> In addition to Comment #90...
> 
> We recently added two tests that CAs must perform and resolve errors for...

Just FYI that discussion about these new tests is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/yzbAbgjvAAAJ

Comment 100

[Marc Arderius]

Attachment: Independent Auditor’s report Webtrust (EY)

Comment 101

[Marc Arderius]

Attachment: Independent Auditor’s report Webtrust-SSL Baseline Requirements (EY)

Comment 102

[Marc Arderius]

Attachment: Independent Auditor’s report Webtrust-Extended Validation (EY)

Comment 103

[Kathleen Wilson]

The audit statements are also here:
https://cert.webtrust.org/SealFile?seal=2083&file=pdf
https://cert.webtrust.org/SealFile?seal=2089&file=pdf
https://cert.webtrust.org/SealFile?seal=2090&file=pdf

Comment 104

[Kathleen Wilson]

I'm still seeing lint testing errors...

https://crt.sh/?id=10666406&opt=cablint
SHA-256(Certificate) 	E3268F6106BA8B665A1A962DDEA1459D2A46972F1F2440329B390B895749AD45
SHA-1(Certificate) 	26CAFF09A7AFBAE96810CFFF821A94326D2845AA
CA/B Forum lint
Powered by certlint
	    INFO: CA certificate identified 
    INFO: No checks for DirectoryName 
  NOTICE: CA certificates without Digital Signature do not allow direct signing of OCSP responses 
   ERROR: CA certificates must set keyUsage extension as critical 
   ERROR: DNSName is not FQDN 
 WARNING: CA certificates should not include subject alternative names 
 WARNING: Name has deprecated attribute emailAddress 

https://crt.sh/?id=10666406&opt=x509lint
SHA-1(Certificate) 	26CAFF09A7AFBAE96810CFFF821A94326D2845AA
X.509 lint
Powered by x509lint
	   ERROR: Invalid type in SAN entry

Comment 105

[Erwann Abalea]

(In reply to Kathleen Wilson from comment #104)
> I'm still seeing lint testing errors...
> 
> https://crt.sh/?id=10666406&opt=cablint
[...]
>    ERROR: CA certificates must set keyUsage extension as critical 

This error is obviously wrong, the certificate does have a critical KeyUsage extension.

>    ERROR: DNSName is not FQDN 

[...]

> https://crt.sh/?id=10666406&opt=x509lint

> 	   ERROR: Invalid type in SAN entry

I guess it's the previous "DNSName is not FQDN" error, which is true. "www.anf.es" would have perfectly fit in a dnsName, "http://www.anf.es" doesn't.

Comment 106

[Ryan Sleevi]

Kathleen requested I comment on this, given the previous concerns.

I remain concerned that the Root Certificate being requested for inclusion does not comply with the profile for certificates outlined in RFC 5280 or the Baseline Requirements. I do not believe it would benefit Mozilla users or the broader community to include this certificate.

While I can understand that auditors attempting to 'skirt' the goal and intent of the rules may try to argue that ANF had already signed this root certificate prior to the time under audit, the absence of technical compliance here should have prevented this root from ever having undergone a successful audit (per ceremony), and thus forever raised qualifications. I'd be happy to discuss this point with CPA Canada (as overseers of the WebTrust brand) and their auditor (E&Y Spain) to better understand their perspectives on this, but I believe it's a significant enough matter to reject-and-escalate.

Before including this root in a Mozilla product, I would recommend that the following corrective actions be taken:
1) Mozilla Root Program Maintainers discuss with CPA Canada and E&Y Spain on this matter, to understand the auditors view of the assertions being made, in light of the obvious non-compliance.
  a) The ANF Global Root CA does not conform to RFC 5280 - https://crt.sh/?id=10666406&opt=x509lint
  b) The ANF High Assurance EV CA1 does not conform to RFC 5280 - https://crt.sh/?id=8600858&opt=x509lint
2) ANF be required to generate new certificates that conform to the technical profile of RFC5280
  a) Mozilla must make a decision as to whether or not to accept to encoding violation within the Locality (as pointed out in https://bugzilla.mozilla.org/show_bug.cgi?id=555156#c98 )
  b) If Mozilla decides to ignore that violation, which I advise against, then it would allow ANF to generate new certificates using the same encoded subject name and the existing keypair, allowing the 'new' certificate to be used in lieu of the existing bugged certificates.
  c) ANF be required to increase the 'notBefore' by one second over the greatest of the notBefore of the existing certificates. This is to ensure Mozilla and NSS clients "prefer" the newest certificate
  d) ANF be required to encode all X.509 v3 extensions in a manner that complies with both RFC 5280 and the Baseline Requirements' profiles for certificates.
  e) ANF be required to encode the CRL distribution point and OCSP responder URL using an "HTTP" endpoint. As their schemes are currently HTTPS, both Microsoft and Mozilla products will fail to be able to ever check revocation, as revocation checking using HTTPS is not performed (as it would otherwise create a circulate dependency).

I want to unequivocally state that I am opposed to this inclusion at present, believe it represents significant technical and security risk to Mozilla users, and believe that these matters are serious enough to escalate to CPA Canada as quality issues that would be appropriate for the revocation of the WebTrust seal.

Comment 107

[Enric Castillo]

Dear all,

First of all I want to apologize. ANF Autoridad de Certificación, as a European CA, have been suffering a lot of changes because the new eIDAS regulation (910/2014) and the new national laws and regulations adapted to eIDAS. We've should change lot of parts, including RA, VA and CA to allow new requirements and new fields on the certificates. We wished that all this process finish with the last Webtrust Audit, that includes these changes, but later of eIDAS changes the Spanish Goverment changed the natural person, legal person, and public employee. Because the different public administrations (national, regional, local, etc) each with a different technology - some of them obsolete - we are recently finishing with it. As you now, eIDAS also affect to SSL and SSL EV certificates, and we must be compliant first of all with eIDAS because we are also audited by the goverment.

This is why whe don't update your requirements on the bug, but all were solved before and during the audit with help of EY.

Now, regarding your comments, all of them are based on the old root and ca certificate, and the ssl certificates issued by them.

I'm attaching the renewed root and CA certificates. We made a certificate renewal without re-key to mantain the same hierarchy. The certificates issued with the old CA certificate should be valid and nonrevoked, but all the new certificates will be issued by the renewed certificates.

We are doing the last tests to the SSL certificate and tomorrow I'll publish the new uri here.


Thanks and sorry for the inconvinience. I hope that now we can finish with the inclusion.

Comment 108

[Enric Castillo]

Attachment: ANF_Global_Root_CA_SHA256_2036.cer

Comment 109

[Enric Castillo]

Attachment: ANF_High_Assurance_EV_CA1_SHA256_2036.cer

Comment 110

[Enric Castillo]

Dear all,

I'm attaching the new SSL EV Certificate. It has the policies and QC Statements according with Webtrust and with eIDAS.
It can be also viewed in https://ssl.anf.es

We've verified with https://certificate.revocationcheck.com/ssl.anf.es and is not retrieving errors. Just saying that the OCSP signer does not contain the Extended Key Usage for OCSP Signing and does not contain the OCSP No Check extension, but I done a request with Openssl and the OCSP Signer is right. I'll attach both OCSP Signers also.

How can we force crt.sh to read the new certificate to verify it with this tool?

Thanks,

Comment 111

[Enric Castillo]

Attachment: SSL EV Certificate

Comment 112

[Enric Castillo]

Attachment: CA OCSP Signer

Comment 113

[Enric Castillo]

Attachment: Root OCSP Signer

Comment 114

[Gervase Markham [:gerv]]

(In reply to Enric Castillo from comment #110)
> How can we force crt.sh to read the new certificate to verify it with this
> tool?

Upload it to any of the Certificate Transparency logs that crt.sh reads.

Gerv

Comment 115

[Enric Castillo]

Attachment: Root OCSP Responder

This is the right responder of the new root ca.

Comment 116

[Enric Castillo]

Thanks, we are checking the OCSP responder error and uploading the CA Cert to a CT Log and we will update the bug after the issue is solved.

Comment 117

[Aaron Wu]

Hi Enric,

Please also perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

Please let me know if you have any question, thank you!


Kind regards,
Aaron

Comment 118

[Enric Castillo]

Dear Aaron,

After several months working on new eIDAS regulation and preparing the new trust services, we are back on this with all the requirements accomplished.

I'm attaching the BR Self Assessment. Please check it to continue with the inclussion process.


Thanks,

Comment 119

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 120

[Kathleen Wilson]

(In reply to Enric Castillo from comment #118)
> 
> I'm attaching the BR Self Assessment. Please check it to continue with the
> inclussion process.
> 


The BR Self Assessment was not attached. So this request is still on hold, waiting for the CA to attach their BR Self Assessment.

https://wiki.mozilla.org/CA/BR_Self-Assessment

Comment 121

[Andrew Ayer]

This morning on CABF's servercert-wg mailing list, Tim Hollebeek reported a misissued certificate chaining to ANF Global Root CA, as well as CPS non-compliance: https://cabforum.org/pipermail/servercert-wg/2019-May/000849.html

Comment 122

[Ryan Sleevi]

Another example, which is quite problematic: https://crt.sh/?id=1723124144&opt=ocsp,zlint,x509lint,cablint and issued 2019-07-30

I would recommend this be rejected with prejudice, and the CA be required to create a new hierarchy, with clear disclosures about the nature of these incidents and how the new hierarchy addresses them.

Comment 123

[Pablo Díaz]

Dear sirs,

ANF AC's Certification Practices Statement is fully compliant with the Baseline Requirements and is constructed in accordance with RFC 3647. CA Contact person can be found in section 1.5.2. of the same: https://anf.es/pdf/Certification_Practices_Statement_ANFAC_v26.pdf

The certificate Ryan Sleevi points out, issued by error, has already been revoked. ANF AC has established controls to prevent non BR compliant test certificates (max validity period of 30 day and including OID 2.23.140.2.1) and has no other valid wrong constructed test certificates.

As we will not continue with the inclusion request of this hierarchies, I personally asked to close this Bug #555156 as WONTFIX, but it hasn't been closed yet. ANF AC proceded to the issuance of a new hierarchy, as indicated, fixing all errors and tested with all the tools indicated by Mozilla. We will open a new Inclusion Request Bugzilla bug.

Please close this Bug #555156.

Comment 124

[Ryan Sleevi]

(In reply to Pablo Díaz from comment #123)

ANF AC has established controls to prevent non BR compliant test certificates (max validity period of 30 day and including OID 2.23.140.2.1) and has no other valid wrong constructed test certificates.

https://crt.sh/?q=77754817eced33241b540d6ef3db4f1a3c0529f2646fad1d0e87c0ab6585e2f8 as mentioned in Comment #121 is also misissued and not revoked.

For posterity, the most recent audits, from 3/23/2018 until 3/22/2019, is

• https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/CSQA-Attestation-ANF-2019-digitally-signed.pdf.aspx?lang=it-IT

Kathleen: I'll leave you to close as WONTFIX per Comment #123, and also clarify any follow-up requirements for future inclusion requests, regarding these incidents or the selection of auditors for the new infrastructure, if one should be created.

Comment 125

[Kathleen Wilson]

(In reply to Pablo Díaz from comment #123)

Please close this Bug #555156.

Closing the request as WONTFIX. I am also going to close the existing Root Inclusion Case in the CCADB, in order to avoid future confusion.

Pablo, when you are ready with the new CA hierarchy and corresponding documentation, please create a new Root Inclusion Case and corresponding Bugzilla Bug as described here:
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

Comment 126

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #124)

the selection of auditors for the new infrastructure, if one should be created.

I have noted in the CCADB that this auditor provided clean audits even though this CA was having problems with BR-compliance during the audit period.

Comment 127

[Pablo Díaz]

(In reply to Ryan Sleevi from comment #122)

the CA be required to create a new hierarchy, with clear disclosures about the nature of these incidents and how the new hierarchy addresses them.

I attach the preliminary report of incidents and the measures that have been taken to prevent them from happening again. I hope it is of the level of detail required and I wait to any observation or indication to clarify any aspect or to apply any further measures.

(In reply to Kathleen Wilson from comment #125)

Pablo, when you are ready with the new CA hierarchy and corresponding documentation, please create a new Root Inclusion Case and corresponding Bugzilla Bug as described here: https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

Please see bug 1585951. The new hierarchies requested in bug 1585951 are clean.

Comment 128

[Pablo Díaz]

Attachment: Preliminary Incident Report

Comment 129

[Ryan Sleevi]

Pablo: Thanks for providing these.

Part of my concern, that I want to highlight because it still appears, is the confusion on ANF's respect as to what constitutes a test certificate. Regarding Incident #1, on Page 1 of Comment #128, ANF notes the language from the BRs "not containing a CABF OID (2.23.140.2.1) in a critical extension". However, later on, on Page 3 of that report as to measures already taken, ANF notes "and include the OID 2.23.140.2.1 in a certificatepolicies extension, marked as critical"

There's a huge problem with that, and it should be immediately obvious to anyone familiar with PKI: the intent of the BRs is that the /extension OID/ itself is the CABF OID, and the extension is marked critical. Not that the OID appears anywhere in some extension (such as certificatePolicies). Anyone familiar with PKI should recognize that, by including a critical extension whose OID is not supported in a client application, a well-conforming client application should reject that certificate from being trusted. i.e. if you put it as the extension OID, and mark it critical, the certificate will be rejected. However, ANF's proposed solution would absolutely make this a valid TLS certificate, if placed only in certificatePolicies - and that would be huge!

That's why I continue to share concern about ANF's understanding of the requirements here, because the function and purpose of the 'critical' field in an extension, which is explicitly to indicate that a client should fail if it does not handle that particular extension OID, should be intimately familiar to any CA, as it's one of the key components to PKI's flexibility and trust model.

Now, as it relates to the other part, the issuance of test certificates, I want to encourage you to review Mozilla's past CA communications for their program, which hopefully provides clarity to a host of issues or questions of interpretation. Any CA applying should review these (and perhaps it's an opportunity to make this clear), since they contain the collective set of clarifications and expectations. Mozilla provides these at https://wiki.mozilla.org/CA/Communications , and I want to draw your attention to the March 2016 communication, which was made during ANF's pending application here. You can read the full communication here, but of particular interest is Action #6 - which tries to make it clear the expectations regarding "Test Certificates" (i.e. even those with the critical OID, as noted above).

What it lacks is some of the contemporaneous context for why that matter was added, it's important to note that this was shortly after Symantec misissued a large number of certificates, which they claimed were test certificates. This incident was one of the several critical incidents that ultimately led to the removal of trust. While that context was not included in the CA communication, it's important at least with respect to understanding the expectations to review the past CA communications, to understand what is expected.

Comment 130

[Pablo Díaz]

Ryan: I deduce from your answer that the report provided meets the level of detail required and you do not request further clarification than the one regarding the OID/extension. Otherwise we wait for further indications. I proceed to answer what you highlighted:

(In reply to Ryan Sleevi from comment #129)

There's a huge problem with that, and it should be immediately obvious to anyone familiar with PKI: the intent of the BRs is that the /extension OID/ itself is the CABF OID, and the extension is marked critical. Not that the OID appears anywhere in some extension (such as certificatePolicies). Anyone familiar with PKI should recognize that, by including a critical extension whose OID is not supported in a client application, a well-conforming client application should reject that certificate from being trusted. i.e. if you put it as the extension OID, and mark it critical, the certificate will be rejected.

In the beginning we were going to apply the measure as you indicated in your comment. However, taking the philosophy of learning from other cases that may have happened in the community, we considered it appropriate to investigate test certificates from some other CA included that have had Mozilla’s approval in order to ensure the measures to be taken.

In a request for inclusion that I found by Microsoft, Wayne Thayer reported some unrevoked certificates with BR violations, to which Microsoft replied that although they were misissued, these certificates included the test OID: “nearly all the certs listed meet the requirements for Test Certificate as listed in Section 1.6.1 of the BRs, including the presence of the “Test” OID (2.23.140.2.1) in a critical extension ”. We reviewed these test certificates, constructed exactly in the way we indicated in our incident report, with the OID included in certificate policies, and said extension marked as critical. Subsequently, at no time was anything highlighted or said by Mozilla to indicate that this was incorrect, that we have been able to find. Moreover, the 3 week discussion period passed successfully (as recently as last August) and it was recommended for inclusion. I am not in favor of pointing other CAs. But you said this was something that no one familiar with PKI would do.

We have proceeded to rectify the measure adopted and OID 2.23.140.2.1 of a test certificate is now entered in an OID extension that it is itself the CABF OID, and the extension is marked critical.

However, ANF's proposed solution would absolutely make this a valid TLS certificate, if placed only in certificatePolicies - and that would be huge!

While the OID has to be in an independent critical extension, which I affirm ANF AC has already applied, there is another aspect you totally overlooked in the report of measures applied. ANF AC indicates that the issuance of said test certificates will be derived to a specific test hierarchy for such purposes, not publicly trusted, therefore, not submitted under the BR.

In this forum Dean Coclin indicates that “The CA/B Forum Baseline Requirements only apply to certificates which chain to publicly trusted roots. This is made clear in the preamble of the document. The BRs do not apply to certificate issuance from non publicly trusted hierarchies.”
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/3NdZkcftqtU/TiRnrvZFBgAJ

I want to encourage you to review Mozilla's past CA communications for their program, which hopefully provides clarity to a host of issues or questions of interpretation. Any CA applying should review these (and perhaps it's an opportunity to make this clear), since they contain the collective set of clarifications and expectations. Mozilla provides these at https://wiki.mozilla.org/CA/Communications , and I want to draw your attention to the March 2016 communication, which was made during ANF's pending application here. You can read the full communication here, but of particular interest is Action #6 - which tries to make it clear the expectations regarding "Test Certificates" (i.e. even those with the critical OID, as noted above).

I have not been able to find any reference to critical OID in Action #6. It indicates that test certificates issued under a hierarchy included in Mozilla must also comply with Mozilla’s Root Policy, and also refers to its section 9 (not existing anymore). In Mozilla’s Root Policy I also have not been able to find any reference to test certificates, and no clarification of the critical OID/extension. But as I specified before, we have applied the measures so that OID 2.23.140.2.1 of a test certificate is now introduced in an OID extension that it is itself the CABF OID, and the extension is marked critical.

Thank you for the Mozilla's past CA communications information pages. ANF AC will proceed to read all the communications that Mozilla has made in the past for its program in order to clarify aspects and expectations, and not hinder the process.

Comment 131

[Ryan Sleevi]

Ryan: I deduce from your answer that the report provided meets the level of detail required and you do not request further clarification

In general, it's a bad idea to make assumptions. It's certainly true that, because ANF is not a trusted CA, the burden of effort is shifted to the CA to demonstrate that they meet and exceed the minimum expectations, as they are now working from a trust deficit. It is easier to simply reject a CA when the answers are not detailed as to how they were caused or the remediations.

Regarding Microsoft, thanks for highlighting this. I've raised it for Microsoft at https://www.mail-archive.com/[e-mail]/msg12793.html It is as deeply (now more deeply) concerning for Microsoft to have had this interpretation, and so I appreciate you highlighting the unfortunate precedent that was overlooked.

Please also be aware of the CA/Browser Forum discussions, such as https://cabforum.org/pipermail/servercert-wg/2019-October/001189.html - which seek to codify many requirements.

In general, if anything is confusing, out of expectation, or seems more permissive, it is important to raise these as concerns.

Comment 132

[Pablo Díaz]

(In reply to Ryan Sleevi from comment #131)

In general, it's a bad idea to make assumptions.

My answer might have not been was clear, your interpretation is incorrect. It was not an assumption nor an affirmation, it was an implicit query. That is precisely why I then added: Otherwise we wait for further indications. I expected a confirmation or that you told me if there was any further aspect that we should detail about the incident report provided.

It's certainly true that, because ANF is not a trusted CA, the burden of effort is shifted to the CA to demonstrate that they meet and exceed the minimum expectations, as they are now working from a trust deficit. It is easier to simply reject a CA when the answers are not detailed as to how they were caused or the remediations.

Permanently, we are invited to read the forums, wikis and mailings to acquire a comprehensive knowledge about what we are expected to accomplish and to take into account other cases and incidents that have occurred in the community. Obviously, as I have shown, we are doing so.

We follow Mozilla's approval criteria in a similar event, whose criteria I understand should serve as guidance on how to act. And, what could be a Mozilla reviewing error (as you acknowledge) is subsequently charged to ANF AC.

ANF ​​AC applies a measure following the criteria of Mozilla in a similar case. Mozilla took as valid the explanation given by Microsoft and the case was approved. Then ANF AC is blamed for it as a very serious error. Not to mention that you totally ignored, that the incident report provided specifies that test certificates will be derived to a NON-publicly trusted hierarchy and, therefore, not subject to the Baseline Requirements.

Regarding Microsoft, thanks for highlighting this. I've raised it for Microsoft at https://www.mail-archive.com/[e-mail]/msg12793.html It is as deeply (now more deeply) concerning for Microsoft to have had this interpretation, and so I appreciate you highlighting the unfortunate precedent that was overlooked.
In general, if anything is confusing, out of expectation, or seems more permissive, it is important to raise these as concerns.

If I am not wrong, I consider that in this forum you indicate an inconsistency in the BRs, which indicates conditions to the construction of test certificates and subsequently associates them with a domain validation method which is not allowed anymore. Therefore, you indicate that Test certificates are not allowed under the BRs because there is nothing in the BRs that authorizes them. Specifically: “there's nothing in the BRs that authorize this Test Certificate” or “they were explicitly forbidden from use.” However, you report errors on our incident report of bad construction of Test certificates as if they were to be issued under a public hierarchy. This also creates confusion.

Despite the inconsistency, ANF AC would be in accordance with your indication in that forum, since, again, we indicate that test certificates are now derived to a private hierarchy for these purposes, not subject to the BRs.

(In reply to Ryan Sleevi from comment #122)

the CA be required to create a new hierarchy, with clear disclosures about the nature of these incidents and how the new hierarchy addresses them.

ANF AC proceeded to the creation of the new hierarchy in bug 1585951, and has proceeded to report the incidents described in this bug about the previous hierarchy, including the measures taken.

We remain at complete disposal of the community in case further explanations or clarification of aspects are required.