Section4 updates #137
Section4 updates #137
Conversation
Sections 4.1 to 4.2.x Pulling in edits from @LarryFrank More in the queue
certificate-policy.md
Outdated
|
|
||
| ## 4.2 Certificate application processing | ||
|
|
||
| ### 4.2.1 Performing identification and authentication functions | ||
| The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with these Requirements and the CA's Certificate Policy and/or Certification Practice Statement. In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant. | ||
| Identification and authentication as specified in Sections 3.2 SHALL occur no more that 30 days prior to the initial certificate issuance. |
There was a problem hiding this comment.
The 30 days and the 825 days in line 645 might not make sense. We added the 30 days + I kept the 825 days from the requirements .
Under the scenarios removing renewal, rekey and modification - the 825 days would only ever apply to OCSP responder certs (which don't have validated subscriber info or validated FQDNs).
There was a problem hiding this comment.
DoD uses the 30 days to control applicant behavior. Where the PKI issues a code that allows for the applicant to go get a certificate after identity verification - it limits the time frame so some applicant can't go get an cert 6 months after doing ID proofing. DoD's current processes - 30 days never comes into play - the cert is issued when the approval is done whether it is manual or automated process. I think the discussion was to make it clear that the 30 days applied to the validity of the "code" used by the applicant and not the age of the data. Seems like a good approach if there is a need to keep the 30 days.
There was a problem hiding this comment.
+1 - removing 30 days for identity verification. opening issue to track and clarify 30 days for authentication
will reapply new changes for #148
|
@konklone merge? easier for additional reviews when merged; reviewed today and minor changes made |
certificate-policy.md
Outdated
| - An application for a CA certificate shall be submitted by an authorized representative of the applicant CA. | ||
|
|
||
| For end entity certificates: | ||
| - A certificate application shall be submitted to the CA by the Subscriber, an authorized organization representative, or an RA on behalf of the Subscriber. |
There was a problem hiding this comment.
My apologies for missing the call to discuss this, but I don't agree with the authorized word here at all for end entity certificates.
What it means to be "authorized" will vary from agency to agency, and isn't something we can control. We do not want to be subject to audit risk if an agency fails to manage its internal policy controls correctly.
We only want to be subject to audit for failing to meet domain validation controls. If an "unauthorized" organization representative with control of a DNS name obtains a certificate from this PKI for that DNS name, then the agency might be sad internally, but it was not a failure of this PKI.
There was a problem hiding this comment.
Frankly, an unauthorized person with control of DNS can get "auto" approval from any ACME enabled CA. But that is a different topic... DoD specifically wants this language. It issues medium-hardware PKI credentials to individuals who are authorized to make these requests. The credentials have a specific attribute that shows the authorization. OR, an RA specifically vets the individual. And "submission" doesn't mean the request is automatically approved. In a manual process - someone (aka an RA) needs to verify the authority.
There was a problem hiding this comment.
If DoD wants this language and wants their audits to verify this behavior, then DoD should include it in the CPS of their issuing CA, rather than the root's CP.
There was a problem hiding this comment.
I would still recommend to DoD, as a colleague, that they not put it in their CPS, but rather just make it an operating principle. But if you really want your 3rd party audits to validate whether agency internal authorization procedures were followed, policy associated with the specific issuing CA would be appropriate.
There was a problem hiding this comment.
The DoD issuing CA will put the specific of the process in the CPS (as should any CA that operates under this policy.) It will state how the "authority" is determined. But to be allowed to do that in the CPS, there needs to be enabling text in the CP. If there isn't something that indicates that an "authorized organization representative" is allowed then the CPS could be judged non-complaint with the CP - and fail the audit.
There was a problem hiding this comment.
it's not DoD or civilian - it's a we statement. "we"..."we"...
I'm going to draft remove the full portion of: "an authorized organization representative". I don't know what an organization is in this context and by definition except "organization=U.S. Government".
There was a problem hiding this comment.
I get that it is "we" - but in the manual process - it is not the subscriber (device) or the RA - "authorized organization representative" is what "we" call a "PKI Sponsor" on Common/FBCA CP, DoD CP. And that IS who submits the requests. The CA (directly or via an RA) needs to determine who is "authorized" - DoD does this today and needs to continue to be able to do it for the foreseeable future in the MANUAL process. My concern - WHEN we write the CPS to say that is what we are going to do - will it be judged non-compliant. If the answer is YES - NON-COMPLIANT, then the phrase needs to REMAIN. As a policy geek who does "compliance analysis" for DoD, I would argue that it is NOT complaint as the CP says one of two entities and you are now saying a third. And, yes, the "organization is "US Government" - all the authorized organizatio0n representatives" will be Civ, Mil or contractors working for part of the US Government. I for one will recommend a critical comment on this issue when it comes around for review - so we can decide how to fix it now or do it in adjudication.
Section 3.2.2 says the CA verifies "and the authenticity of the Applicant Representative's certificate request" - that is the "authorized organization representative". In DoD, the PROCESS is for the RA to work with the organization directly to determine that the PERSON who submitted the request was authorized to do so. I suspect every other organization which does manual NPE cert issuance has a very similar process.
There was a problem hiding this comment.
It's a bit simpler for an answer. I - for one - am against mixing terms that aren't defined and want to stay away from "Sponsor".
But you pointed out the answer = align with 3.2.2. So instead of "authorized organization representative" which has no direct correlation to any other terms yet used - why not use "Applicant representative"?
There was a problem hiding this comment.
That works for me - as long as we have some way for a person to submit the request...
There was a problem hiding this comment.
done! Applicant representative...(now I need to go change my architecture diagrams to say "applicant representative" 😄 )
|
|
||
| 1. A certificate request, which may be electronic; and | ||
| 2. An executed Subscriber Agreement or Terms of Use, which may be electronic. | ||
|
|
||
| The CA SHOULD obtain any additional documentation the CA determines necessary to meet these Requirements. | ||
| The certificate request SHALL contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct. |
There was a problem hiding this comment.
For DV end entity certs, we should not need to obtain a certificate from the Applicant that all of the information contained therein is correct.
There was a problem hiding this comment.
This is a CAB Forum Baseline Requirement in Section 4.1.2, last paragraph (v 1.4.9 - although it exists in previous versions I am verifying against the latest in progress red-lines).
The only thing we changed was MUST to SHALL because govt tends to use SHALL over MUST per RFC 2119. MUST and SHALL are interchangeable and for readability we will go through and replace all musts with shalls.
This statement is in every CP I notionally reviewed while comparing / confirming alignment (including LE CP, Amazon trust services CP, etc).
There was a problem hiding this comment.
Got it, so for DV it sounds like it's basically a NOOP (since there is no other information validated in the cert). I can understand how this works as boilerplate language.
| Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with this CP. One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 3.3.1, provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically. | ||
| - properly formed | ||
| - accurate | ||
| - meets the requirements for the type of certificate requested: a device Domain Validation SSL end entity certificate, a device Organizational Validation SSL end entity certificate, a CA Certificate, or a Certificate Status Server (OCSP) signing certificate |
There was a problem hiding this comment.
I know we've discussed the merits of issuing EV certificates. But separately, has there been explicit discussion about supporting OV certificates? They provide even less value than EV certificates, whether customers want them or not.
There was a problem hiding this comment.
EV provides no actual value to the relying party as far as I can tell - hard to be "less" than NONE! There has been discussion. I believe we came to the conclusion that (while DoD would like to have OU=DoD in its certs) the effort to do it under the CA/B forum rules isn't worth the perceived benefit.
There was a problem hiding this comment.
- EV is already out of scope
- It's OV and DV
- Yes, we've had explicit discussions
Without debating the merits of OV versus DV as it applies to general public or commercial practices:
- It's a very simple answer: We have missions that want / need SUBJECT information in the certificates that explicitly assert C=US and O=U.S. Government
It all ties together with the certificate profiles and the modifications (aligned with baseline requirements) to prohibit or require subject information in the certs. Asserting C (country) and asserting O (along with the one other required attribute for 'when O, then S/L etc') as explicit values triggers the OV policy OID - which does not preclude automated, when properly constrained to US Government through policy and technical controls.
- When you look at Section 7.1.6 for baseline requirements + subject information certificate profile requirements: it's very explicit - to assert O (organizationName), you can't assert the DV policy OID.
- this topic has been discussed in the CA/B forum's policy working group, the March CA/B Forum F2F, and on the listserves; Taiwan brought it up in relation to the additional attributes (S/L) too specific to govt entities
- to larry's point, we dropped the OU (OU=Agency) from the profiles
And the benefits are not on the security of the TLS transaction directly - yes, DV/OV/EV doesn't do anything different for a TLS handshake. It's solely that for operational and informational purposes - including for mission partners - we want to assert a C=US, O=U.S. Government.
It's a government special snowflake scenario that applies to more than just US Government. Rather than request special dispensation or exceptions to the requirements, exceptions which are hard to maintain and create too many permutations for the broader efforts in web pki, we will align.
[The order in which we're writing and identifying technical / operational design elements does have logic associated! Section 3 has not been touched yet which will assert / document under what authority and procedures we assert C and restricted subject information aligned with the verification requirements.]
There was a problem hiding this comment.
'when O, then S/L etc') as explicit values triggers the OV policy OID - which does not preclude automated, when properly constrained to US Government through policy and technical controls.
OK, that makes sense, given our organizational control over .gov and .mil -- would there be any additional work on an issuing CA's end to assert the C and O fields and the OV OID beyond regular DV-level validation?
There was a problem hiding this comment.
Section 3.2.2.1
Dependent on what we assert for the CP for Section 3, but in particular 3.2.2.1 and 3.2.2.3 which has circular references / dependencies.
All the statements with restrictions are to help tie back to US public law, executive branch (or leg/judicial) public policy, systems and technical controls.
There was a problem hiding this comment.
A couple methods that jump out in 3.2.2.3 where we could auto-OV
A third party database that is periodically updated and considered a Reliable Data Source;
So in theory we could use the .gov domain list and its Type field to do this to distinguish between federal and non-federal .gov services.
As stated earlier I have serious concerns with hinging our audits on that list's quality with how it's managed at present. However, if it was the difference between OV certs being fully automated with no additional work on top of DV and not, then it would be worth maturing that process on DotGov's side.
There was a problem hiding this comment.
@konklone I think we're in agreement on this one. thumbs up?
certificate-policy.md
Outdated
|
|
||
| The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate's approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements. | ||
| The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than 825 days prior to issuing the Certificate. |
There was a problem hiding this comment.
I know we can reuse validation information for 825 days, but should we allow it? This could result in a certificate in use whose actual validation was performed up to 1629 days in the past. I think we should discuss a reasonable self-imposed cap on validation information, such as 90 days.
There was a problem hiding this comment.
From DoD's perspective - the entire game is nonsensical - The validation is not done in the past - the documentation used is old. But, frankly, in DoD, it NEVER changes - so putting any "expiration" date on the documentation just generates work with no actual increase in the goodness of the asserted identity.
There was a problem hiding this comment.
Well there is an expiration date on the documentation regardless (the maximum being 825 days), but isn't it more important to think of this from an attacker scenario?
Whether DoD hostnames tend to change frequently under proper operation isn't super relevant -- the purpose of the expiration date is to validate frequently enough to make attacks more difficult.
Trying to model this -- is the threat that an attacker obtains a copy of the private key associated with the original validation, but does not get/maintain control over the hostname in question? And that they could then cause the CA to issue them a fresh certificate with a new longer expiration date up to 825 more days in the future?
There was a problem hiding this comment.
Actually, your scenario has nothing to do with the expiration of the authorization document - that is the reason for not allowing REKEY - use of a currently valid certificate to get a new one - having a copy of the current key has NO bearing on the approval of a new certificate when the criteria is verifying that the requestor has current (valid) documentation that demonstrates continued control of the DNS space.
There was a problem hiding this comment.
Got it, so this is not reusing technical validation data, but documents relating to whether the applicant is authorized? Or is it some other sort of document?
If it's the former, my comments above about removing "authorization"-related content from the root CP, in favor of including in the issuing CA's policies, apply. And, since we're not allowing rekey (thank you for connecting that, that makes sense), then removing authorization documents from scope would leave no reason to allow any reuse of data or documentation at all.
There was a problem hiding this comment.
removed authorization from previous "who can submit" comments.
In this scenario, authorization can be domain authorization. Reuse of data still applies to domain authorization.
How about 825 days for the data to be used / reused, and the certificate validity expiration cannot extend past 825 days from the date of the identity validation?
There was a problem hiding this comment.
How about 825 days for the data to be used / reused, and the certificate validity expiration cannot extend past 825 days from the date of the identity validation?
So if we perform technical validation on day 0, then we reuse that data 300 days later, a certificate issued by reusing that validation data can only be valid for up to 525 days?
If so, that sounds reasonable and addresses my concern about allowing the potential for certificates being in use 1,650 days after their initial validation.
👍
certificate-policy.md
Outdated
|
|
||
| ### 4.2.2 Approval or rejection of certificate applications | ||
| CAs SHOULD NOT issue Certificates containing a new gTLD under consideration by ICANN. Prior to issuing a Certificate containing an Internal Name with a gTLD that ICANN has announced as under consideration to make operational, the CA MUST provide a warning to the applicant that the gTLD may soon become resolvable and that, at that time, the CA will revoke the Certificate unless the applicant promptly registers the Domain Name. When a gTLD is delegated by inclusion in the IANA Root Zone Database, the Internal Name becomes a Domain Name, and at such time, a Certificate with such gTLD, which may have complied with these Requirements at the time it was issued, will be in a violation of these Requirements, unless the CA has verified the Subscriber's rights in the Domain Name. The provisions below are intended to prevent such violation from happening. | ||
| This Certificate Policy is restricted to be applicable to, and technically constrained, for DotMil and DotGov assets under direct authority of the US Federal Government. All certificate applications submitted by entities not affiliated with the US Federal Government SHALL be rejected. |
There was a problem hiding this comment.
I would strongly recommend keeping the CP/CPS free of a commitment to limit .gov and .mil domains to federal-only. While we may operate our CAs with the intention of limiting to federal, issuing to a state/local/tribal .gov (with proper domain validation etc.) should not be an audit-risking event.
Honestly -- as the incoming owner of the dataset from which this distinction would be drawn, I have to insist that we not put our audits on the line over the integrity and accuracy of that data. It's had errors in the very recent past, and probably has some now. We'll be doing a cleanup and want that data to be accurate, but I don't see the ROI in elevating that dataset to be critical to the ongoing public trust of this PKI.
There was a problem hiding this comment.
Entirely on the .GOV side - "state" entities in DoD/.MIL (Army and Air National Guard) are considered "federal" for this exercise. I don't know if it matters to anyone but us.
There was a problem hiding this comment.
@LarryFrank I had a definition of federal - i need this .MIL definition of federal? I generally try to tie back to U.S.C. or other public law or policy.
There was a problem hiding this comment.
If you want a law - Title 10. The Fed considers the National Guards to be a part of the "total" force" - the NGs routinely operate in both camps (State and Federal). DoD has a National Guard Bureau which coordinates with Departments of the Army and Air Force which is where the state guard organizations fit. The guard technically belongs to the state until federalized. But are funded directly by the Fed. What TLD they use is a mis-mash. Some use "ng.mil", some "army.mil" others use .com, org, and some state .gov).
There was a problem hiding this comment.
Per discussion - will remove and change:
All certificate applications submitted by entities not affiliated with the US Federal Government SHALL be rejected.
CAs SHALL NOT issue Certificates containing any Fully Qualified Domain Names that are not under the gTLDs for DotGov or DotMil.
This Certificate Policy is restricted to be applicable to, and technically constrained, for DotMil and DotGov assets. CAs SHALL reject all certificate applications containing any FQDNs that are not under the gTLDs for DotGov and DotMil.
commit incoming...
certificate-policy.md
Outdated
| CAs SHOULD NOT issue Certificates containing a new gTLD under consideration by ICANN. Prior to issuing a Certificate containing an Internal Name with a gTLD that ICANN has announced as under consideration to make operational, the CA MUST provide a warning to the applicant that the gTLD may soon become resolvable and that, at that time, the CA will revoke the Certificate unless the applicant promptly registers the Domain Name. When a gTLD is delegated by inclusion in the IANA Root Zone Database, the Internal Name becomes a Domain Name, and at such time, a Certificate with such gTLD, which may have complied with these Requirements at the time it was issued, will be in a violation of these Requirements, unless the CA has verified the Subscriber's rights in the Domain Name. The provisions below are intended to prevent such violation from happening. | ||
| This Certificate Policy is restricted to be applicable to, and technically constrained, for DotMil and DotGov assets under direct authority of the US Federal Government. All certificate applications submitted by entities not affiliated with the US Federal Government SHALL be rejected. | ||
|
|
||
| CAs SHALL NOT issue Certificates containing any Fully Qualified Domain Names that are not under the gTLDs for DotGov or DotMil. |
There was a problem hiding this comment.
DotGov and DotMil aren't gTLDs.
There was a problem hiding this comment.
I keep going back and forth on this based on ICANN rules. The difference between gTLD and sTLD...(circa 2015 rule changes?) So DotGov and DotMil are sTLD which are a sub-category of gTLD?
Do we need to make that distinction? Want me to change to sTLD?
I'm trying to ensure the gTLD rules are inherited and we align with the both the letter AND the spirit of the requirements. There are specifics for ccTLD versus gTLD (for example)
There was a problem hiding this comment.
I'm sorry, you were correct -- sTLDs are considered a subcategory of gTLDs:
certificate-policy.md
Outdated
| Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation. | ||
| Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation. Issuance of a CA certificate by the Root CA SHALL require written authorization by the Policy Authority. | ||
|
|
||
| All end entity certificates for Domain Validation SSL and Organizational Validation SSL SHALL assert a Certificate Transparency (CT) Signed Certificate Timestamp (SCT) via the x509v3 certificate extension. The Issuing CA SHALL submit a precertificate to a minimum of two Certificate Transparency Logs. Information included in the end entity certificates SHALL NOT be redacted prior to submission to the Certificate Transparency Logs. At a minimum, the Issuing CA SHALL request and include two SCTs in the x509v3 certificate extension: |
There was a problem hiding this comment.
Is two SCTs going to be enough? For longer certificates, Chrome has required up to 5 SCTs.
There was a problem hiding this comment.
For EV (up to 5 SCTs).
Minimum of two, no maximum specified as required.
There was a problem hiding this comment.
No, that's not current policy. Chrome defines "CT Qualified" as a range of 2 to 5 SCTs, depending on the lifetime of the certificate.
(Since life times have been limited to 825 days going forward, for new certificates 4 would be the maximum.)
Though the document mentions that EV certificates all need to be CT qualified, the document is defining Chrome's entire CT Qualified definition. This is what Symantec certs are held to, for example.
Until the policy changes, we should expect that SCTs will range higher than 2 depending on length.
Of course, if we limited our CAs to issuing certs shorter than 15 months, then we could expect to get away with 2 SCTs. ;)
There was a problem hiding this comment.
The "requirement" document I found (May 2016?) is (at best) confusing. I read it as being only applicable to EV - with no CT requirements for anything other than EV. Whether Google decides to use the same qualification table for OV and/or DV is left to the user to guess.
There was a problem hiding this comment.
@LarryFrank I was briefly confused myself, because it discusses EV in the second paragraph, but that's only to mention that EV certificates have to meet the definition in this document. The document is careful not to limit its scope to EV certificates.
I reached out to Chrome representatives and confirmed that the May 2016 document is their broad definition of CT Qualified, applies to Symantec, and is the current policy that would apply to any subsequent CT requirements for issued certificates. (While we could probably recommend edits to make it even more clear, the document as written does match this interpretation.)
They obviously may (and I'd guess probably will) revise it before the April 2018 deadline and to get into greater alignment with whatever Mozilla goes with. But it is current policy, and there's no reason to think that certificate life time wouldn't continue to be correlated with a required number of SCTs.
There was a problem hiding this comment.
Okay, this is valid.
We put 2 as the minimum, but should clarify that 2 is ONLY a minimum based on the validity period of the cert. I read it as up to 3 (27 months / 825 days) and 4 would never be "required" based on the maximum lifetime of 825 days now; but this is an issue with switching months to days between the two sources.
There was a problem hiding this comment.
Ah, right. We should make a suggestion to Chrome to move their requirements to days in the next version of the policy, especially so that 825 days is crystal clear as to where it fits in.
There was a problem hiding this comment.
@lachellel I think this is an outstanding change to say "minimum of two" or something like that?
There was a problem hiding this comment.
Oh no, I see 29260ec now. 👍
certificate-policy.md
Outdated
|
|
||
| All end entity certificates for Domain Validation SSL and Organizational Validation SSL SHALL assert a Certificate Transparency (CT) Signed Certificate Timestamp (SCT) via the x509v3 certificate extension. The Issuing CA SHALL submit a precertificate to a minimum of two Certificate Transparency Logs. Information included in the end entity certificates SHALL NOT be redacted prior to submission to the Certificate Transparency Logs. At a minimum, the Issuing CA SHALL request and include two SCTs in the x509v3 certificate extension: | ||
| - One SCT from a Google operated CT log | ||
| - One SCT from non-Google operated CT log |
There was a problem hiding this comment.
Given the flux of the CT ecosystem, and Mozilla's impending CT policy that may not look like this, should we leave the details to a document that's incorporated by reference?
There was a problem hiding this comment.
Apparently, we will get to redo this policy fairly often anyway as the CA/B forum and various browsers just make stuff up. The technical parts are harder than changing the policy and should be no harder than a "referenced" document.
There was a problem hiding this comment.
No, let's not do another incorporation by reference please? The incorporation by reference is where we are with FPKI. Documents that need to be updated, can get out of date, can impart unnecessary overhead to maintain and version etc. PILES of referenced documents. 👎
[I think I just described most cross-referencing issues for anyone in the world?]
The policy has to be reviewed and updated every 365 days at a minimum ("annually" but I changed to 365 days to be explicit).
|
(I put ":+1:" comments to indicate that 3 particular threads are resolved, and will do so going forward.) |
not under dotmil and dotgov
rewrote some of the CT requirements per comments Will open more comments - identified issues in logic (for CT policy)?
|
|
||
| ### 4.2.3 Time to process certificate applications | ||
| Certificate applications SHALL be processed and a certificate issued within 30 days of identity verification. |
There was a problem hiding this comment.
Need to remove this 30 days too...
There was a problem hiding this comment.
i update for no stipulation here...the 30 days is on the authentication / authorization secrets in Section 3.
time to process applications is an SLA & can be covered in the CPS and in Subscriber agreements as needed.
| - At least one of the Certificate Transparency Logs SHALL be a CT Log operated by Google. | ||
| - At least one of the Certificate Transparenty Logs SHALL be a CT Log NOT operated by Google. | ||
|
|
||
| The Issuing CA SHALL include at least the same number and variety of SCTs in the x509v3 certificate extension for the end entity certificate issued. |
There was a problem hiding this comment.
I have a question and am using a phone a friend chit:
- If I submit a precert and include SCTs in the x509v3 extension, there is no requirement for the real cert to also be posted to any CT Logs (that I can find)?
- Is there any requirement for the Issuing CA that is a SHALL statement (i.e. SHALL also submit the certificate post-issuance to at least one CT Log)?
[We can define a requirement - but the technical enforcement is on the SCT presence in the protocols, and for x509v3 it's from the precert submission.]
There was a problem hiding this comment.
If I submit a precert and include SCTs in the x509v3 extension, there is no requirement for the real cert to also be posted to any CT Logs (that I can find)?
Correct. It would be redundant.
Is there any requirement for the Issuing CA that is a SHALL statement (i.e. SHALL also submit the certificate post-issuance to at least one CT Log)?
Nope.
There was a problem hiding this comment.
sweet @jsha - thanks!
I don't want to tell someone how to tie their shoes, only that they have to wear shoes of a particular type. It seemed redundant to require (shall) the submission because then it becomes an auditable event.
removed authorized organization
no stipulation authentication not identity; subscriber agreement can state expectations or SLAs as needed in govt
|
All comments have been addressed except the 825 days. Suggest merge for fuller review and to get the PRs sync'd into master; and opening an issue for 825 days? |
Some updates not added pending comments
@LarryFrank
fixes #89 fixes #71 fixes #70 fixes #66 fixes #62 fixes #60 fixes #59 fixes #57 fixes #55 fixes #53 fixes #50 fixes #49 fixes #48 fixes #47 fixes #37 fixes #13
a lot of issues will be closed