Re: Certigna Root Inclusion Request

[Frank Hecker]

Ian G wrote:

The policy says, we need published information, *eg* the CPS.

Not, "CPS must be published."


Yes, exactly. We typically use the CPS and/or CP because almost all CAs 
publish those documents; however there is no requirement that the 
information published by the CA be in the form of a CPS or CP.


Speaking personally, I think think that it is good practice for CAs to 
publish a CPS. If a CA has private information relating to detailed 
internal processes that it does not wish to make public, I suggest that 
it put such material in a separate "CA operations manual" that is 
internal-only.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Frank Hecker]

David E. Ross wrote:

On 2/10/2009 12:06 PM, Frank Hecker wrote:
If you cannot publish the CPS because it contains private information, I 
suggest as an alternative that you provide some sort of official 
Certigna document that summarizes the portions of the CPS that are of 
most interest to us (i.e., those relating to validation of subcriber 
information).



However, not only should they provide some alternative documentation but
also that documentation should be considered during the required audit.


My assumption was that if the material in the document was based on the 
CPS then it would have been covered in the audit, since presumably the 
audit was based on what was in the CPS.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Public CPS Requirement [Was: Certigna Root Inclusion Request]

[Frank Hecker]

Eddy Nigg wrote:

On 02/10/2009 10:06 PM, Frank Hecker:

If you cannot publish the CPS because it contains private information, I
suggest as an alternative that you provide some sort of official
Certigna document that summarizes the portions of the CPS that are of
most interest to us (i.e., those relating to validation of subcriber
information).


That would be a precedent too which I wouldn't recommend. We really want 
to know what was audited, don't we?


See my comment to David Ross.

Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Frank Hecker]

Kyle Hamilton wrote:

I'm asking this because I think a template which includes a statement
of requirements would be an exceedingly good thing for people
undertaking reviews for Mozilla CA program inclusion -- and would open
up the process to people who have less interior working knowledge of a
CA.  This would also allow people who are otherwise untrained, but who
want to take an interest in their security, to understand what the
reviews entail and what Mozilla's priorities are.


We have the CA checklist as a template for information gathering:

  https://wiki.mozilla.org/CA:Information_checklist

and also some similar stuff on the "how to apply" page:

  https://wiki.mozilla.org/CA:How_to_apply

Is this the sort of thing you were thinking of?

Frank

P.S. These are on a wiki, so if you or anyone else wants to modify these 
pages to make them more useful for newbies, please feel free.


--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Kyle Hamilton]

That's a very good question.  The most important part of the answer to
it would have to be: don't discount what they say.

However, I have a suggested strategy for reviewers: don't limit your
review to only those trust bits that are initially requested.  This
way, if there is an amendment to the bug which requests additional
bits to be set, then we don't have to waste our time doing an entire
new review of the CP/CPS/public information to figure out if those new
trust bits are also appropriate.

For each type of trust bit requested, what are the minimum
requirements for inclusion?

TLS server: must perform at a minimum domain control verification
email: must perform at a minimum email account control/access verification
software: must perform legal identity verification?

EV: Must perform corporate legal identity verification, must have
policy OID for embedding, must have a different audit, cannot use
MD5...

(come to think of it, I think I'll read the EV document again and
figure out all the "must" clauses.)

I'm asking this because I think a template which includes a statement
of requirements would be an exceedingly good thing for people
undertaking reviews for Mozilla CA program inclusion -- and would open
up the process to people who have less interior working knowledge of a
CA.  This would also allow people who are otherwise untrained, but who
want to take an interest in their security, to understand what the
reviews entail and what Mozilla's priorities are.

(for example:

Please identify the section of the public documentation which
addresses each point below:

SERVER: Performs domain control verification
How does the CA perform this?  (if not performed, answer "N/A"; if not
described, answer "Unspecified")
SERVER: Performs domain control change revocation
How does the CA perform this?
EMAIL: Performs email account control/access verification
How does is it performed?

...and so on.)

-Kyle H

On Tue, Feb 10, 2009 at 3:38 PM, Ian G  wrote:
> On 10/2/09 23:02, Eddy Nigg wrote:
>>
>> On 02/10/2009 09:42 PM, Frank Hecker:
>>>
>>> And in any case, I don't see people being as much concerned about having
>>> more Mozilla-employed people involved, but as getting more community
>>> feedback. And I don't have any good answers there because it depends on
>>> having more people willing to volunteer their time.
>>
>> I too think that one person dedicated to CA matters should be
>> sufficient. Perhaps there are some from other CAs and/or otherwise
>> knowledgeable in this field willing to spend ONE hour per week as a
>> contribution to Mozilla? Yes, I'm looking at you!
>
>
> I thought about that too, but discarded it.  Certainly some CA input is
> useful, but the danger is that it becomes overbearing and selfserving, and
> could lead to some form of tit-for-tat war between the CAs (assuming that
> there are multiple rounds of reviews, which we would probably all agree is a
> good thing).
>
> The real problem is, how do we get independent people to stick around and
> comment?
>
>
>
> iang
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Eddy Nigg]

On 02/11/2009 01:38 AM, Ian G:


I thought about that too, but discarded it. Certainly some CA input is
useful, but the danger is that it becomes overbearing and selfserving,
and could lead to some form of tit-for-tat war between the CAs (assuming
that there are multiple rounds of reviews, which we would probably all
agree is a good thing).



It's perhaps an opportunity for me to explain why I'm here and why I 
think others - specially representatives and employees of CAs - should 
too. Of course I also represent StartCom at times when it's relevant - 
my signature clearly shows my affiliation. As such, StartCom is also a 
member at various other open source and open standards projects, 
therefore my participation here isn't unique per se.


Personally I believe that CAs have an interest that policies for 
inclusions at the browsers are upheld. Also I believe that people 
working at CAs have the best knowledge in reviewing and advising on 
these matters. For example, I viewed the contributions made by Rob & 
Robin of Comodo and other CAs as entirely positive. The experience and 
knowledge Kathleen brought with her as an ex-employee of a CA just 
confirms that knowing about the inner procedures, actual practices and 
some real-world experience at a CA is almost necessity. Myself didn't 
had to make too many reviews either in order to realize that my 
contribution is rather important to the overall inclusion process - I'm 
just sorry that I didn't started with it earlier.


Tit-for-tat wars aren't really relevant when there are no deficiencies. 
If there are deficiencies, they must be dealt with accordingly and it 
doesn't matter if it's a CA (or employee of a CA) participating here or 
not. The same policy and same rules apply for all CAs equally. :-)
Important is, and because of the sensitivity, that the judgment and 
final decisions are made by the responsible person Mozilla assigned for 
this task. This has been Frank and at times Gerv so far.


A similar situation applies to code and other contributions too. There 
are various commercial organizations contributing code, patches and 
services to Mozilla, some of which obviously serves their own interests 
too - sometimes it's even exclusive. Those contributors are most capable 
in leading development and contributing towards the various projects and 
components. There are module owners, reviewers and drivers - sometimes 
those positions are even held by contributors which work at commercial 
organizations not affiliated with Mozilla. Because of that, I think that 
the participation of CAs and their employees as community members is no 
precedence and highly useful in my opinion.



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Ian G]

On 10/2/09 21:06, Frank Hecker wrote:


I acknowledge your comment that ETSI TS 102 042 does not require the CPS
to be published. However we depend on public documents to document the
exact claims that CAs make and whether these meet our policy
requirement. So this causes a problem for us when we do not have access
to CPSs and related documents.

If you cannot publish the CPS because it contains private information, I
suggest as an alternative that you provide some sort of official
Certigna document that summarizes the portions of the CPS that are of
most interest to us (i.e., those relating to validation of subcriber
information).



I had to re-read the policy and think about this a few times.  Yes, I 
think that is it.


The policy says, we need published information, *eg* the CPS.

Not, "CPS must be published."  So there are two reasons not to enforce 
publication of the CPS:  one is that ETSI (allegedly) doesn't require 
it.  Another is that the CPS pretty much always has things in it like 
"and then we use this private practices statement to achieve X."  Or, it 
doesn't say that, but either way, the auditor is faced with 2 sets of 
documents, one of which is private, one public.  Both valid and 
verifiable.  The auditor loves secret documents, that's bread & milk.


Then there are reasons to enforce publication.  One is, we can only 
verify -- as an *enduser* -- what we can read.  Another is that an 
"opinion" rendered over a secret document has to be taken with a large 
dose of salt.  Just exactly how much room is there for manoeuvre?


Given these complications, I think the policy is about right.  It is 
useful to promote publication of documents, it is quite useful to state 
clearly that Mozilla only relies on public documents, and it is very 
useful to state what information is needed.


But it is not particularly useful to try and draw a line in the sand 
based on the title of some document.




iang



PS: with a nod to David's point that a new document provided (as an 
extract?) might not be representative / outside an audit scope.  Where 
to draw the line?

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Ian G]

On 10/2/09 23:02, Eddy Nigg wrote:

On 02/10/2009 09:42 PM, Frank Hecker:

And in any case, I don't see people being as much concerned about having
more Mozilla-employed people involved, but as getting more community
feedback. And I don't have any good answers there because it depends on
having more people willing to volunteer their time.


I too think that one person dedicated to CA matters should be
sufficient. Perhaps there are some from other CAs and/or otherwise
knowledgeable in this field willing to spend ONE hour per week as a
contribution to Mozilla? Yes, I'm looking at you!



I thought about that too, but discarded it.  Certainly some CA input is 
useful, but the danger is that it becomes overbearing and selfserving, 
and could lead to some form of tit-for-tat war between the CAs (assuming 
that there are multiple rounds of reviews, which we would probably all 
agree is a good thing).


The real problem is, how do we get independent people to stick around 
and comment?




iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Public CPS Requirement [Was: Certigna Root Inclusion Request]

[Eddy Nigg]

On 02/10/2009 10:06 PM, Frank Hecker:

If you cannot publish the CPS because it contains private information, I
suggest as an alternative that you provide some sort of official
Certigna document that summarizes the portions of the CPS that are of
most interest to us (i.e., those relating to validation of subcriber
information).


That would be a precedent too which I wouldn't recommend. We really want 
to know what was audited, don't we?



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[David E. Ross]

On 2/10/2009 12:06 PM, Frank Hecker wrote:
> Yannick LEPLARD wrote:
>> Unfortunately, CPS are not published (they described internal technical and
>> organizational measurements)
> 
> I acknowledge your comment that ETSI TS 102 042 does not require the CPS 
> to be published. However we depend on public documents to document the 
> exact claims that CAs make and whether these meet our policy 
> requirement. So this causes a problem for us when we do not have access 
> to CPSs and related documents.
> 
> If you cannot publish the CPS because it contains private information, I 
> suggest as an alternative that you provide some sort of official 
> Certigna document that summarizes the portions of the CPS that are of 
> most interest to us (i.e., those relating to validation of subcriber 
> information).
> 
> Frank
> 


THANK YOU!!  That was indeed the point of my earlier comment.

However, not only should they provide some alternative documentation but
also that documentation should be considered during the required audit.

-- 
David E. Ross


Go to Mozdev at  for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications.  You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Application of client certificates on a US government website

[Kyle Hamilton]

On Tue, Feb 10, 2009 at 11:52 AM, Frank Hecker
 wrote:
> Speaking to Anders's point about provisioning, I think the largest
> deployment of client certificates in the US government is probably the DoD
> PKI implementation, where they solved the provisioning problem in a brute
> force manner by giving everybody hardware tokens. In other cases you'd have
> to give some people some incentive to participate; the PTO might be a good
> place to do so because there's a community of people (e.g., patent and
> trademark lawyers) who regularly interact with the PTO and are motivated to
> get in compliance with whatever security measures the PTO puts into place.

The US court system (http://uscourts.gov/) requires usernames and
passwords for attorneys to be able to upload electronic case
documents.  (Oh, yeah, and they also require electronic document
submission by those entities capable of it.)  These are provisioned in
the same kind of time-consuming "physically mail out a PIN" manner as
the USPTO's sign-up process.

The USPTO effort is unique as far as I can tell because it invites
anyone who wants to submit a patent application to take part in it.

> Maybe for a restricted community like tax preparers, but I think the chances
> of any nationwide certificate use by all taxpayers are very low given the
> failure of past efforts (like those of the USPS) to establish a general US
> government-to-citizen PKI.

The USPS effort was unfunded -- to be perfectly honest, the USPS is
the perfect agency to be able to do higher-level identity validations
(their representatives are everywhere), but their main purpose is so
different from the identity verification requirements of a
government-to-citizen PKI that if the US government wanted it to
happen, the US government needed to funnel money into the program to
make it work.

-Kyle H
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Eddy Nigg]

On 02/10/2009 09:42 PM, Frank Hecker:

And in any case, I don't see people being as much concerned about having
more Mozilla-employed people involved, but as getting more community
feedback. And I don't have any good answers there because it depends on
having more people willing to volunteer their time.


I too think that one person dedicated to CA matters should be 
sufficient. Perhaps there are some from other CAs and/or otherwise 
knowledgeable in this field willing to spend ONE hour per week as a 
contribution to Mozilla? Yes, I'm looking at you!



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Eddy Nigg]

On 02/10/2009 09:32 PM, Frank Hecker:

Eddy Nigg wrote:

I would support a review requirement by the community of at least two
individuals which independently review the CA.


Do you mean two people besides Kathleen?


Yes, that's my idea...


That may be difficult to
achieve; I think there were a number of requests where you were the only
community person who commented.



...which isn't really the perfect state either. Personally I feel that 
I'm dominating the list at times, specially during reviews and comments 
periods. I'd very much prefer to have my findings independently 
confirmed by at least another person.


> I guess we could compare this to the problem of patches sitting in
> the queue for lack of review and superreview.

Yes, that's a good and reasonable comparison.

> Personally I would like
> to see at least some additional review of CA requests, whether that
> be by Eddy or you or whoever. But I'm also not really happy about
> stretching out discussion of CA requests for multiple weeks just
> because no one besides Kathleen has time to look at things,
> especially given the backlog of requests we have.

Well, currently it's not likely that this would happen - and if it 
would, you'd know about it. But of course that would be the theoretical 
price to pay for such a requirement.



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Eddy Nigg]

On 02/10/2009 10:19 PM, Frank Hecker:

Email validation isn't too difficult to implement, however we have
seen various times that this isn't done sufficiently or correctly.


Note that the official Mozilla policy doesn't attempt to dictate exactly
what mechanisms a CA uses to verify ownership of email addresses, it
simply requires that "the CA takes reasonable measures" to verify this.


Correct. I haven't attempted to dictate about how to do it, but we've 
seen cases where it's not done at all.


However some (affected) CAs turned directly to me for advice in the past 
concerning email validation and I provided my suggestions and advice. 
Some of them might still be subscribed to this list btw.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Frank Hecker]

Eddy Nigg wrote:

On 02/10/2009 04:25 PM, Yannick LEPLARD:


RA operators must obtain guarantee than the e-mail address is owned by 
the

requester.
It's difficult in fact to make such controls.


Email validation isn't too difficult to implement, however we have seen 
various times that this isn't done sufficiently or correctly.


Note that the official Mozilla policy doesn't attempt to dictate exactly 
what mechanisms a CA uses to verify ownership of email addresses, it 
simply requires that "the CA takes reasonable measures" to verify this.


We can quibble about whether particular measures are "reasonable" or 
not. However traditionally the major concerns we've had were with CAs 
that did not have any CPS or CP language at all about verifying email 
addresses.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RES: Application of client certificates on a US government website

[Bruno Ribeiro]

The client-side processing of digital signatures is the major problem, I
think. And the main barrier against the adoption of PKI. Key stores are far
from a standardization. CryptoAPI, CNG, Mozilla, JAVA KS, CSP, PKCS#11, etc.


Bruno de Paula Ribeiro
Analista de Sistemas
(11) 4501 1886

Certisign Certificadora Digital
certisign.com.br



-Mensagem original-
De: dev-tech-crypto-bounces+bribeiro=certisign.com...@lists.mozilla.org
[mailto:dev-tech-crypto-bounces+bribeiro=certisign.com...@lists.mozilla.org]
Em nome de Anders Rundgren
Enviada em: terça-feira, 10 de fevereiro de 2009 17:39
Para: mozilla's crypto code discussion list
Assunto: Re: Application of client certificates on a US government website

Nelson B Bolyard wrote:
>>Kyle Hamilton wrote
>> Hey, I just ran into the first application of client certificate
>> authentication requirement on a public US government website that I've
>> seen.


>I played with it a bit.
>As far as I can tell, it is not doing SSL client authentication, per se',
>at least not using the browser's built-in SSL client auth capabilities.
>The page https://sas.uspto.gov/authenticate/AuthenticateUserLocalEPF.html
>downloads some Javascript which in turn downloads a Java applet named
>EntrustTruePassClient.  This looks for a file on your local disk with
>a file name ending in .epf. The page says:
>> NOTE : DIGITAL CERTIFICATES provided by USPTO have a file name that ends
in ".epf".
>I gather that it also contains your private key.  What it does, exactly,
>after that is unknown to me.  I lost interest after seeing that it's not
>doing SSL client auth.

You are probably right.  May I as a person living in a country where
at least 20% of the adult population use "soft certificates" for on-line
banking and e-government services provide some facts why this
situation is far from being unique?

Soft certificates may be a piece of junk but they are at least available.

However, provisioning of soft certificates is close to N/A since
there is no standard and the stuff that's available is below any
reasonable quality; you cannot even set a PIN policy, not to
mention how different these schemes appear to users!

In Safari the user will have to select between medium or strong
keys and in Vista/IE you must typically put the issuer in the trusted
site-list in order to get a ActiveX control to work.

Therefore Java applets is a good choice since it make authentication
an application, taking care of the missing pieces, policy and
provisioning and it works in most browsers and OSes.

In case you feel that this is not what you want, may I suggest
that we start by identifying what's lacking and see if there is any
way we could fix it?

Regards
Anders
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Frank Hecker]

Yannick LEPLARD wrote:

Unfortunately, CPS are not published (they described internal technical and
organizational measurements)


I acknowledge your comment that ETSI TS 102 042 does not require the CPS 
to be published. However we depend on public documents to document the 
exact claims that CAs make and whether these meet our policy 
requirement. So this causes a problem for us when we do not have access 
to CPSs and related documents.


If you cannot publish the CPS because it contains private information, I 
suggest as an alternative that you provide some sort of official 
Certigna document that summarizes the portions of the CPS that are of 
most interest to us (i.e., those relating to validation of subcriber 
information).


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RES: Application of client certificates on a US government website

[Bruno Ribeiro]

PKI implementation is running well here in the Brazilian government. We have
laws and a national PKI (ICP-Brasil) already supporting digital signatures.
The next step is to officially implement a long-term digital signature
schema, based on RCF 3126.

I think that our government structure strongly contribute for this. The
policies and laws here are more centralized. It doesn't differs
significantly among the states of the federation.

Regards.

Bruno de Paula Ribeiro
Analista de Sistemas
(11) 4501 1886

Certisign Certificadora Digital
certisign.com.br


-Mensagem original-
De: dev-tech-crypto-bounces+bribeiro=certisign.com...@lists.mozilla.org
[mailto:dev-tech-crypto-bounces+bribeiro=certisign.com...@lists.mozilla.org]
Em nome de Frank Hecker
Enviada em: terça-feira, 10 de fevereiro de 2009 17:53
Para: dev-tech-crypto@lists.mozilla.org
Assunto: Re: Application of client certificates on a US government website

Kyle Hamilton wrote:
> Hey, I just ran into the first application of client certificate
> authentication requirement on a public US government website that I've
> seen.

As Nelson write, this isn't really SSL client auth per se, but I agree 
it is interesting.

> Personally, I think this is a huge step forward.  While it's still a
> niche market, the fact that a US government organization is willing to
> do this suggests that others might in the future.

Speaking to Anders's point about provisioning, I think the largest 
deployment of client certificates in the US government is probably the 
DoD PKI implementation, where they solved the provisioning problem in a 
brute force manner by giving everybody hardware tokens. In other cases 
you'd have to give some people some incentive to participate; the PTO 
might be a good place to do so because there's a community of people 
(e.g., patent and trademark lawyers) who regularly interact with the PTO 
and are motivated to get in compliance with whatever security measures 
the PTO puts into place.

> (I'm thinking I'd
> eventually like to see this with the Internal Revenue Service. ;) )

Maybe for a restricted community like tax preparers, but I think the 
chances of any nationwide certificate use by all taxpayers are very low 
given the failure of past efforts (like those of the USPS) to establish 
a general US government-to-citizen PKI.

Frank

-- 
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Hongkong Post Root Inclusion Request

[Frank Hecker]

Michael Ströder wrote:

Nelson B Bolyard wrote:



Does this CA also implement OCSP?  Can we justify this on the grounds
that we do implement OCSP, and that OCSP will effectively displace CRLs
as the preferred revocation channel?


I'd say no. Use of OCSP should not be made mandantory.


I agree, especially for the non-EV case. Use of CRLs is going to 
continue to be widespread for some time to come, so I think we really 
have no choice but to invest in better CRL support (including putting 
Mozilla funding into this if needed).


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Application of client certificates on a US government website

[Frank Hecker]

Kyle Hamilton wrote:

Hey, I just ran into the first application of client certificate
authentication requirement on a public US government website that I've
seen.


As Nelson write, this isn't really SSL client auth per se, but I agree 
it is interesting.



Personally, I think this is a huge step forward.  While it's still a
niche market, the fact that a US government organization is willing to
do this suggests that others might in the future.


Speaking to Anders's point about provisioning, I think the largest 
deployment of client certificates in the US government is probably the 
DoD PKI implementation, where they solved the provisioning problem in a 
brute force manner by giving everybody hardware tokens. In other cases 
you'd have to give some people some incentive to participate; the PTO 
might be a good place to do so because there's a community of people 
(e.g., patent and trademark lawyers) who regularly interact with the PTO 
and are motivated to get in compliance with whatever security measures 
the PTO puts into place.



(I'm thinking I'd
eventually like to see this with the Internal Revenue Service. ;) )


Maybe for a restricted community like tax preparers, but I think the 
chances of any nationwide certificate use by all taxpayers are very low 
given the failure of past efforts (like those of the USPS) to establish 
a general US government-to-citizen PKI.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Frank Hecker]

Ian G wrote:
I think -- personal & likely biased opinion only -- you might get more 
value by looking inside the foundation and asking them to expand the 
resources available on the CA desk.


Right now between Kathleen, myself, and Johnathan Nightingale (e.g., his 
CAB Forum activities) we have probably close to one full-time-equivalent 
person working on CA stuff in general for MoFo/MoCo/etc. I think we 
could increase that somewhat, and I hope we will, but I don't see an 
immediate prospect to have, for example, 2 or more FTEs working on CA 
stuff. So I think that on the Mozilla side we're going to be resource 
constrained on this for some time to come.


And in any case, I don't see people being as much concerned about having 
more Mozilla-employed people involved, but as getting more community 
feedback. And I don't have any good answers there because it depends on 
having more people willing to volunteer their time.


Frank

P.S. For what it's worth, this problem is not unique to this area. 
They're having a discussion right now over in mozilla.governance about 
there not being a large number of module owners and peers who are 
independent of Mozilla (i.e., not employees or contractors of MoCo, 
MoFo, etc.).


--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Application of client certificates on a US government website

[Anders Rundgren]

Nelson B Bolyard wrote:
>>Kyle Hamilton wrote
>> Hey, I just ran into the first application of client certificate
>> authentication requirement on a public US government website that I've
>> seen.


>I played with it a bit.
>As far as I can tell, it is not doing SSL client authentication, per se',
>at least not using the browser's built-in SSL client auth capabilities.
>The page https://sas.uspto.gov/authenticate/AuthenticateUserLocalEPF.html
>downloads some Javascript which in turn downloads a Java applet named
>EntrustTruePassClient.  This looks for a file on your local disk with
>a file name ending in .epf. The page says:
>> NOTE : DIGITAL CERTIFICATES provided by USPTO have a file name that ends in 
>> ".epf".
>I gather that it also contains your private key.  What it does, exactly,
>after that is unknown to me.  I lost interest after seeing that it's not
>doing SSL client auth.

You are probably right.  May I as a person living in a country where
at least 20% of the adult population use "soft certificates" for on-line
banking and e-government services provide some facts why this
situation is far from being unique?

Soft certificates may be a piece of junk but they are at least available.

However, provisioning of soft certificates is close to N/A since
there is no standard and the stuff that's available is below any
reasonable quality; you cannot even set a PIN policy, not to
mention how different these schemes appear to users!

In Safari the user will have to select between medium or strong
keys and in Vista/IE you must typically put the issuer in the trusted
site-list in order to get a ActiveX control to work.

Therefore Java applets is a good choice since it make authentication
an application, taking care of the missing pieces, policy and
provisioning and it works in most browsers and OSes.

In case you feel that this is not what you want, may I suggest
that we start by identifying what's lacking and see if there is any
way we could fix it?

Regards
Anders
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Frank Hecker]

Eddy Nigg wrote:
I would support a review requirement by the 
community of at least two individuals which independently review the CA.


Do you mean two people besides Kathleen? That may be difficult to 
achieve; I think there were a number of requests where you were the only 
community person who commented.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Frank Hecker]

Nelson B Bolyard wrote:

While I do not wish in any way to question or reduce the value of
Kathleen's evaluation, I wonder if it is right for us to allow CA
applications to be approved in the absence of any real public discussion.


As Ben pointed out, there was opportunity for public discussion, but no 
one took advantage of that opportunity, presumably due to not having time.



In the complete absence of any discussion, positive or negative, does it
seem right to allow CAs to go into the list by default?  Should we have a
quorum requirement, of some sort, requiring pasticipation by at least N
members before allowing approval?


I guess we could compare this to the problem of patches sitting in the 
queue for lack of review and superreview. Personally I would like to see 
at least some additional review of CA requests, whether that be by Eddy 
or you or whoever. But I'm also not really happy about stretching out 
discussion of CA requests for multiple weeks just because no one besides 
Kathleen has time to look at things, especially given the backlog of 
requests we have.


I have more comments on this, but they're probably better made in 
response to other post.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Eddy Nigg]

On 02/10/2009 06:30 PM, Ian G:

a. Time. There is always some element of change between the last audit
and current practice. Audits are "snapshots of the past" not proofs over
the present nor future.


So far correct.


And, there is an expectation that audits are
repeated over time, the new guy has to have something to work with.


Correct, but it's not audited - whatever it is.


Also, factor in 40 week + distro delays, and consider asking CAs to sit
on their hands for a year or so.


No, did anybody suggest that and where?


b. The emphasis of the audit is over whether management has put in place
policies and procedures, sticks to them. Any check over particular
activities is not there to "audit those activities in themselves" but to
provide evidence of the policies and procedures in general as a reliable
guide to the reading public.


No, that statement is basically bullshit :-)

Particular activities are audited including evidence of the specific 
policies and procedures.



d. Having said that, a specific audit criteria may state a check is
needed on X. One would have to go back and read WebTrust to see if it
has a criteria on X==codesigning. That still doesn't change the other
issues, but it may give you something to "rely" on when it comes to
codesigning specifically.


Wrong! If the CPS doesn't mention code signing than it's not audited. No 
samples of those procedures are taken by the auditor either. Audits 
pretty much confirm what the CA claims to do.




That's my view at the moment, I'm looking forward to others!



Audits are very specific and you can forget about the "general" 
references. As such we have precedence in this respect (in particular 
code signing).



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Hongkong Post Root Inclusion Request

[Michael Ströder]

Nelson B Bolyard wrote:
> This is probably a policy question, but: are we willing to accept CAs
> that use CRLs that we cannot parse?

I'd say no.

> Does this CA also implement OCSP?  Can we justify this on the grounds
> that we do implement OCSP, and that OCSP will effectively displace CRLs
> as the preferred revocation channel?

I'd say no. Use of OCSP should not be made mandantory.

Ciao, Michael.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Yannick LEPLARD]

You state ". . . CPS are not published . . . "

Repeatedly, the "WebTrust Program for Certification Authorities"
indicates that the CPS is PUBLISHED.  This means it is made  
available to

the public, to both those who have certificates and those who trust
those certificates.  If you were audited in conformance with WebTrust
criteria, how did you pass the audit without publishing your CPS?



we have ETSI TS 102 042 audits and only CP have to be published.


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Yannick LEPLARD]

We are at the same level than the DCSSI CA that was approved a few  
days ago.


Each CA is looked at independently and each CA has its own CP/CPS,  
audit etc.




I just wanted to explain that DCSSI is the french government CA,
and PRIS/RGS is the new highest level standard for french CAs.

It is ETSI TS 102 042 compliant, and ETSI 101 456 compliant for  
qualified signing certificates.


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Ian G]

On 10/2/09 16:42, :


The initial comment was written on august 2008, and now we have code
signing
certificates, and it appears in our CP/CPS.


To my understanding the audit wasn't performed with those changes.


In general terms, and without commenting at all on the current case, 
here are a few observations.  I think this is another area where there 
is a misunderstanding as to the role of audit.


a.  Time.  There is always some element of change between the last audit 
and current practice.  Audits are "snapshots of the past" not proofs 
over the present nor future.  And, there is an expectation that audits 
are repeated over time, the new guy has to have something to work with. 
 Also, factor in 40 week + distro delays, and consider asking CAs to 
sit on their hands for a year or so.


b.  The emphasis of the audit is over whether management has put in 
place policies and procedures, sticks to them.  Any check over 
particular activities is not there to "audit those activities in 
themselves" but to provide evidence of the policies and procedures in 
general as a reliable guide to the reading public.


E.g., they do what they write, they write what they do.

d.  Having said that, a specific audit criteria may state a check is 
needed on X.  One would have to go back and read WebTrust to see if it 
has a criteria on X==codesigning.  That still doesn't change the other 
issues, but it may give you something to "rely" on when it comes to 
codesigning specifically.


c.  One of the policies and practices that audits look at is generally 
whether CPSs and so forth are updated according to a reliable regime. 
Of course, we can really only do that when we see that change is done, 
so this is actually a positive chance for the next auditor to check the 
progress.  I say this with some relish, because extracting good evidence 
is quite hard when most things are just written because the auditor says 
it is needed, and then ignored forever more..




That's my view at the moment, I'm looking forward to others!

iang

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Eddy Nigg]

On 02/10/2009 04:25 PM, Yannick LEPLARD:


The initial comment was written on august 2008, and now we have code signing
certificates, and it appears in our CP/CPS.


To my understanding the audit wasn't performed with those changes.



Yes it is not defined in our CP but in our internal operational processes
and in our CPS too.
Unfortunately, CPS are not published (they described internal technical and
organizational measurements)


This must be stated in the CPS and publicly disclosed. I'm sorry, but in 
my opinion this is insufficient and will most likely not work.




RA operators must obtain guarantee than the e-mail address is owned by the
requester.
It's difficult in fact to make such controls.


Email validation isn't too difficult to implement, however we have seen 
various times that this isn't done sufficiently or correctly.




- Software private keys are generated on the suscriber computer with a
signed applet


This is interesting! Can you provide us some more information about this 
applet? Can I test it somewhere?




We are at the same level than the DCSSI CA that was approved a few days ago.


Each CA is looked at independently and each CA has its own CP/CPS, audit 
etc.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[David E. Ross]

On 2/10/2009 6:25 AM, Yannick LEPLARD wrote:
> 
> Le 9 févr. 09 à 20:54, Eddy Nigg a écrit :
> 
>> On 02/09/2009 09:35 PM, kathleen95...@yahoo.com 
>> :
>>> Of course. I will await your next post to this discussion.
>>>
>>
>> Just browsing through the various documents and I noticed the following so 
>> far.
>>
>> It seems to me that the code signing bit *should not* be activated, it 
>> should 
>> be reflected in the "Pending" page as well.
> 
> The initial comment was written on august 2008, and now we have code signing
> certificates, and it appears in our CP/CPS.
> 
>>
>>
>> Email validation seems to me ambiguous at least and apparently not defined 
>> in 
>> their CP/CPS. Neither is domain ownership/control validation defined as I 
>> understand.
> 
> Yes it is not defined in our CP but in our internal operational processes
> and in our CPS too.
> Unfortunately, CPS are not published (they described internal technical and
> organizational measurements)
> RA operators must obtain guarantee than the e-mail address is owned by the
> requester.
> It's difficult in fact to make such controls. In practice the name of the
> requester must appear in the left part of the e-mail address... If not, RA
> operators are likely to get proof of possession (the request can be rejected
> in case of doubt). For employees it's easier : the name of the suscriber and
> domain name of the company can be easily checked.
> 
> It's the same for domain ownership/control : 
> RA operators verify the names of owner, administrator... in databases (like 
> whois).
> They visit the website to look at the content, and the request can be 
> rejected 
> if any doubt.
> 
>>
>>
>> Repeated requests for translating the relevant parts have not been complied. 
>> Comments in this respect (bug 393166, comment 15, d) ) have no relevance to 
>> the question asked and your questions in comment 13 have partly not been 
>> answered, in particular 2.d. Besides a general denial in regards of 
>> problematic practices, no details have been provided.
> 
> - Our DV SSL certificates have maximum expiration time of 3 years in the
> future.
> 
> - Software private keys are generated on the suscriber computer with a
> signed applet
> - When the suscriber is using a smartcard, the private key is generated
> onboard.
> 
> 
>> In particular I couldn't find out for how long their certificates are valid 
>> and how S/MIME certificates are provided to the subscriber ("We send the 
>> certificate to the subscriber by mail").
> 
> - Certificates are valid 1, 2 or 3 years.
> 
> - S/MIME certificates are provided to the suscriber by email (not mail,
> sorry). the suscriber must agree with the certificate and send a return
> receipt with certificate eacceptance.
> There is a signed applet for the suscriber to ask for a certificate, and to
> install the issued certificate.
> 
>>
>>
>> Overall I think there is very little information available about this CA (in 
>> English) and I'm hesitant to continue without a more thorough review of 
>> critical aspects.
> 
> We are at the same level than the DCSSI CA that was approved a few days ago.
> On february 2009, the 5th, we obtain the compliance with PRIS/RGS for our
> CAs ( and our CP, CPS  are compliant with the exemplifications CP/CPS  of
> http://www.mozilla.org/projects/security/certs/pending/#DCSSI
>  )
> 
> ( cf :
> http://www.references.modernisation.gouv.fr/outil-de-suivi-des-qualification
> s-et-des-referencements-des-offres-de-certificats
>  )
> 
> 
> Mr Bouchet from LSTI is the lead auditor mandated by the french government 
> for 
> the ETSI and PRIS/RGS audits.
> If case of doubt about our practices, you can obtain more informations from 
> him
> His phone number is : +33 1 30 61 50 60

You state ". . . CPS are not published . . . "

Repeatedly, the "WebTrust Program for Certification Authorities"
indicates that the CPS is PUBLISHED.  This means it is made available to
the public, to both those who have certificates and those who trust
those certificates.  If you were audited in conformance with WebTrust
criteria, how did you pass the audit without publishing your CPS?

-- 
David E. Ross


Go to Mozdev at  for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications.  You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

[Yannick LEPLARD]

Le 9 févr. 09 à 20:54, Eddy Nigg a écrit :On 02/09/2009 09:35 PM, kathleen95...@yahoo.com:Of course. I will await your next post to this discussion.Just browsing through the various documents and I noticed the following so far.It seems to me that the code signing bit *should not* be activated, it should be reflected in the "Pending" page as well.The initial comment was written on august 2008, and now we have code signingcertificates, and it appears in our CP/CPS.Email validation seems to me ambiguous at least and apparently not defined in their CP/CPS. Neither is domain ownership/control validation defined as I understand.Yes it is not defined in our CP but in our internal operational processesand in our CPS too.Unfortunately, CPS are not published (they described internal technical andorganizational measurements)RA operators must obtain guarantee than the e-mail address is owned by therequester.It's difficult in fact to make such controls. In practice the name of therequester must appear in the left part of the e-mail address... If not, RAoperators are likely to get proof of possession (the request can be rejectedin case of doubt). For employees it's easier : the name of the suscriber anddomain name of the company can be easily checked.It's the same for domain ownership/control : RA operators verify the names of owner, administrator... in databases (like whois).They visit the website to look at the content, and the request can be rejected if any doubt.Repeated requests for translating the relevant parts have not been complied. Comments in this respect (bug 393166, comment 15, d) ) have no relevance to the question asked and your questions in comment 13 have partly not been answered, in particular 2.d. Besides a general denial in regards of problematic practices, no details have been provided.- Our DV SSL certificates have maximum expiration time of 3 years in thefuture.- Software private keys are generated on the suscriber computer with asigned applet- When the suscriber is using a smartcard, the private key is generatedonboard.In particular I couldn't find out for how long their certificates are valid and how S/MIME certificates are provided to the subscriber ("We send the certificate to the subscriber by mail").- Certificates are valid 1, 2 or 3 years.- S/MIME certificates are provided to the suscriber by email (not mail,sorry). the suscriber must agree with the certificate and send a returnreceipt with certificate eacceptance.There is a signed applet for the suscriber to ask for a certificate, and toinstall the issued certificate.Overall I think there is very little information available about this CA (in English) and I'm hesitant to continue without a more thorough review of critical aspects.We are at the same level than the DCSSI CA that was approved a few days ago.On february 2009, the 5th, we obtain the compliance with PRIS/RGS for ourCAs ( and our CP, CPS  are compliant with the exemplifications CP/CPS  ofhttp://www.mozilla.org/projects/security/certs/pending/#DCSSI )( cf :http://www.references.modernisation.gouv.fr/outil-de-suivi-des-qualifications-et-des-referencements-des-offres-de-certificats )Mr Bouchet from LSTI is the lead auditor mandated by the french government for the ETSI and PRIS/RGS audits.If case of doubt about our practices, you can obtain more informations from himHis phone number is : +33 1 30 61 50 60-- RegardsYannick LEPLARDDirecteur R&D20, allée de la râperie59650 Villeneuve d'Ascqtél. : 03 20 79 24 09fax. : 03 20 34 20 52www.dhimyotis.frCe mail est signé électroniquement grâce à un certificat Certigna. Il a valeur légale.Pour plus d'informations, rendez-vous sur www.certigna.fr.--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Ian G]

On 10/2/09 14:16, Eddy Nigg wrote:

On 02/10/2009 02:15 PM, Ian G:





I think -- personal & likely biased opinion only -- you might get more
value by looking inside the foundation and asking them to expand the
resources available on the CA desk. Their job is to be independent, and
so far, that's worked out, more or less.


1.) They still may make mistakes.



So, no different to any other part of the business process.



2.) They are not independent.



Again, no different.  Nobody is absolutely independent.

The question is, who would be more independent, in a relative scale?

If you look at it objectively, they have a better chance of being 
independent, and of covering the territory more completely.




(FTR, I've already written off-list emails to them on this subject. I
know some changes have been made, and it takes time.)


Why off-list?



That's off-topic.


iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Eddy Nigg]

On 02/10/2009 02:15 PM, Ian G:

I also don't like this discussion about waiting for some perfect A-list
of tech. We've got the NNTP thing, we've got the ordinary mail, what are
we waiting on now? google-phone? twitter?


Even though I don't care about google groups either (and google can 
fetch any comment thereafter as well and also does so), Johnathan 
explained what we are waiting for...



On to your important question. My views would fall on the "against
change" side for now.


Of course! I wouldn't expect anything else from you...or you wouldn't be 
Ian Grigg.



I think -- personal & likely biased opinion only -- you might get more
value by looking inside the foundation and asking them to expand the
resources available on the CA desk. Their job is to be independent, and
so far, that's worked out, more or less.


1.) They still may make mistakes.
2.) They are not independent.


(FTR, I've already written off-list emails to them on this subject. I
know some changes have been made, and it takes time.)


Why off-list?


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Eddy Nigg]

On 02/10/2009 02:30 PM, Ben Bucksch:

Are you fearing that you are on holiday during that time and can't have
your voice?


We should recommend that people which have reviewed the CAs in question 
say so after the comments period. Otherwise we don't know that somebody 
at least took a look. For example the last CA's comments period was too 
short for me... :-)



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Ben Bucksch]

On 10.02.2009 02:23, Nelson B Bolyard wrote:

I'd post this in the policy working group, if that was operational ... :(

In
our esteemed Kathleen Wilson  wrote:

   

According to https://wiki.mozilla.org/CA:How_to_apply
“If there are no open issues or action items after the first
discussion period, and there is general agreement that you comply with
our policy requirements, then at the Foundation's discretion the
second phase of public discussion may be skipped, the request will be
immediately approved, and the request will move into the inclusion
phase…”
 


I wonder if it is right for us to allow CA
applications to be approved in the absence of any real public discussion.

In the complete absence of any discussion, positive or negative, does it
seem right to allow CAs to go into the list by default?


How do you arrive at "complete absense of any discussion" from the "If 
there are no open issues or action items after the first discussion 
period" and the "general agreement"?
There *was* a discussion period, and in fact there had to be responses, 
otherwise there couldn't be "general agreement". It's just that nobody 
had any problems with it, after the discussion (or right away). Why 
wouldn't you include the CA, then?


Are you fearing that you are on holiday during that time and can't have 
your voice?

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

[Ian G]

On 10/2/09 02:23, Nelson B Bolyard wrote:

I'd post this in the policy working group, if that was operational ... :(



I also don't like this discussion about waiting for some perfect A-list 
of tech.  We've got the NNTP thing, we've got the ordinary mail, what 
are we waiting on now?  google-phone?  twitter?




On to your important question.  My views would fall on the "against 
change" side for now.




While I do not wish in any way to question or reduce the value of
Kathleen's evaluation, I wonder if it is right for us to allow CA
applications to be approved in the absence of any real public discussion.



According to the policy, yes it is right.  Point 1, 2.



In the complete absence of any discussion, positive or negative, does it
seem right to allow CAs to go into the list by default?  Should we have a
quorum requirement, of some sort, requiring pasticipation by at least N
members before allowing approval?



That old Churchill comment:  Democracy is a terrible system, but it 
beats the next best system hands down ... or was it, Democracy is 3 
wolves and a sheep, voting on who to have for dinner :)


More seriously ... democracy works when there is a fight for limited 
resources.  Firstly, there is no limited resource here;  the root list 
can be as long as a list.


Secondly, we have to worry about the quality of the fight.  On the one 
side, if there is to be a fight, we can be sure that the CA will muster 
the friends it needs to carry on the fight.  So numbers won't be an 
issue for them.  Nor "independence" nor "seriousness".  And if they 
don't, then it is because they are stupid or honest, and we aren't in 
the game of punishing people for being stupid or honest.


On the other side, we have a group of people who might comment, 
"independently" and another group of people who might have a bone to 
pick, a fight for the sake of the fight, or a hobby horse.  You might 
recall that (some?) political parties now routinely pay people to fill 
up blog postings with positive/negative remarks.


What we lack is any incentive for people to take on the independent role 
in what passes as a sustainable economic effort.




It bothers me that a CA might get into the list simply because no one
(besides Kathleen) had (or took) the time to seriously evaluation the
application.



I think -- personal & likely biased opinion only -- you might get more 
value by looking inside the foundation and asking them to expand the 
resources available on the CA desk.  Their job is to be independent, and 
so far, that's worked out, more or less.


(FTR, I've already written off-list emails to them on this subject.  I 
know some changes have been made, and it takes time.)




This seems especially problematic given that it appears
to be nigh unto impossible to remove a CA from the list.



Yup, no matter how much work you put into the first application, we need 
a "corrective" after-the-fact measure.  All non-brittle systems need 
some measure of fixing.




iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Application of client certificates on a US government website

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2009-02-09 18:29:
> Hey, I just ran into the first application of client certificate
> authentication requirement on a public US government website that I've
> seen.
> 
> [link] https://sportal.uspto.gov/secure/portal/efs-unregistered
> [/link] has information on the "unregistered submission" process, but
> it also strongly encourages people to register.  The information on
> the "PAIR" system they have indicates that the private,
> not-yet-submitted information will only be accessed or accepted if the
> client computer authenticates via certificate, as well.
> 
> (I don't yet know details about their hierarchy.  I'm working on it,
> though.  However, I think that it's extremely likely that they're
> using a private-label CA for the certificate issuance.)
> 
> Personally, I think this is a huge step forward.  While it's still a
> niche market, the fact that a US government organization is willing to
> do this suggests that others might in the future.  (I'm thinking I'd
> eventually like to see this with the Internal Revenue Service. ;) )

I played with it a bit.
As far as I can tell, it is not doing SSL client authentication, per se',
at least not using the browser's built-in SSL client auth capabilities.

The page https://sas.uspto.gov/authenticate/AuthenticateUserLocalEPF.html
downloads some Javascript which in turn downloads a Java applet named
EntrustTruePassClient.  This looks for a file on your local disk with
a file name ending in .epf. The page says:
> NOTE : DIGITAL CERTIFICATES provided by USPTO have a file name that ends in 
> ".epf".
I gather that it also contains your private key.  What it does, exactly,
after that is unknown to me.  I lost interest after seeing that it's not
doing SSL client auth.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto