Re: Include Renewed Kamu SM root certificate

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 14, 2017 at 5:10 PM, tugba onder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Upon your request, we re-examined the current version of CAB BR (v.1.4.2)
> with our CPS document that describes our way of doing business. We did this
> work under these main headings; Identity Proofing, Technologies, Life Cycle
> Management, Certificate Profiles and Auditing Requirements. We read all
> related titles in CPS and CAB Br 1.4.2. Besides, so as not to miss any
> amendment item stated in section 1.2.2 (Relevant Dates) of CAB BR v1.4.2.
> we have stated Kamu SM approach for each item. The table is in this link:
>
> https://drive.google.com/file/d/0B3Yp-DkgL_W-OTR3cWxuOE84bmM/view?usp=
> sharing
>
>
> As a result, we could not notice any major difference between our
> practices and CAB BR v.1.4.2. The minor differences stated in the table
> will be fixed as soon as possible and be ready for the next audit. We hope
> that our examination meets your request and if there exists any other point
> you want to know please do not hesitate to ask.
>

Fantastic! I really appreciate you taking a second look, and I'm glad the
extent of the misalignment was limited to the previously identified
sections. I think that should be sufficient information to proceed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Include Renewed Kamu SM root certificate

[tugba onder via dev-security-policy]

Hi Ryan,

>My request was one of just taking a few days / a week to re-examine what

>the current BRs are, using your knowledge of your policies and practices, 
>and make sure that all methods are consistent. For example, the 64-bits of 
>entropy, the aligned-with-3.2.2.4.6 method of domain validation, etc. That 
>your auditor did not flag these implies that your auditor did not do that 
>level of analysis, but that's also not surprising given the role/function 
>of auditors (some auditors do this as part of their engagements, some 
>auditors do not, and generally both are seen as complying with the 
>necessary level of professional duty; just the ones that do are better 
>auditors, and the ones that don't may miss stuff that finds them removed as 
>trusted auditors in the future) 

>Because we've seen some CAs argue that "You didn't explicitly say we had to 
>follow X in the BRs", I wanted to avoid that situation, by just making sure 
>Kamu SM warrants that "We've read the BRs 1.4.2, we've examined our 
>policies and practices, we believe they're consistent and apply" (or "We 
>identified items X, Y, Z that we are fixing by doing A, B, C")



Upon your request, we re-examined the current version of CAB BR (v.1.4.2) with 
our CPS document that describes our way of doing business. We did this work 
under these main headings; Identity Proofing, Technologies, Life Cycle 
Management, Certificate Profiles and Auditing Requirements. We read all related 
titles in CPS and CAB Br 1.4.2. Besides, so as not to miss any amendment item 
stated in section 1.2.2 (Relevant Dates) of CAB BR v1.4.2. we have stated Kamu 
SM approach for each item. The table is in this link:

https://drive.google.com/file/d/0B3Yp-DkgL_W-OTR3cWxuOE84bmM/view?usp=sharing  
 

As a result, we could not notice any major difference between our practices and 
CAB BR v.1.4.2. The minor differences stated in the table will be fixed as soon 
as possible and be ready for the next audit. We hope that our examination meets 
your request and if there exists any other point you want to know please do not 
hesitate to ask.


Best regards,
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert BR violation

[Kurt Roeckx via dev-security-policy]

On 2017-03-14 02:19, Peter Bowen wrote:

On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy
 wrote:

On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi  wrote:

Are you saying that there are one or more clients that require DigiCert to 
support Teletext strings?


Can we stop saying Teletext? The X500 series standards are talking about 
Teletex. One letter shorter.

Teletext was invented by the BBC, to deliver pages of text and block graphics 
in the blanking interval on analogue television transmissions. It brought joy 
to millions of people (especially nerds) around the world for several decades 
prior to analogue television going off the air.

Teletex is an ITU standard, intended to supersede Fax but largely forgotten 
because it turns out Internet email is what people actually wanted. Its text 
encoding infested the X.500 series standards and thereby made dozens of people 
miserable.


I thought teletex was there to make people who use reverse solidus
('\'), circumflex ('^'), grave accent ('`'), curly brackets ('{' and
'}') and tilde ('~') sad.


The 102 registration also has a ¤ instead of a $ if I remember 
correctly. But that's just the default and with just a few bytes you can 
switch it to ASCII (registration 6).



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy