headers
Moudrick M. Dadashov | 1 May 2012 01:13
Picon

Re: License fee for running a PKI

Do those "trust centers" need a formal registration/approval by local 
authorities?

Thanks,
M.D.

On 4/30/2012 9:03 PM, Martin Rex wrote:
> Moudrick M. Dadashov wrote:
>> Directive 1999/93/EC:
>>
>> in order to stimulate the Community-wide provision of certification
>> services over open networks, certification-service-providers should be
>> free to provide their services without prior authorisation; prior
>> authorisation means not only any permission whereby the
>> certification-service-provider concerned has to obtain a decision by
>> national authorities before being allowed to provide its certification
>> services, but also any other measures having the same effect;
> In practice, the legal requirements (at least in Germany) for most
> regulated usage scenarios require the use of a "qualified signature"
> or a specific trust center (e.g. Elster, GKVNet).
>
> -Martin
>
>
>> On 4/30/2012 6:58 PM, Martin Rex wrote:
>>> Erik Andersen wrote:
>>>> I have received questions for which I need help to answer. The question is
>>>> as follows
>>>>
>>>> - Is that any government requires payment of fees by electronic signature
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephen Wilson | 1 May 2012 07:19
Picon
Gravatar

Re: License fee for running a PKI


Yes, in Europe, for all parties to fully enjoy the protections of 
qualified e-signatures laws, the CAs have to be accredited under a 
recognised scheme like "tScheme".

I thought the same thing applied in the very first digital signatures 
regime in Utah?  I thought CAs there had to be licensed, and part of 
that was audit by a recognised accounting firm?

A similar scheme technically applies in Hong Kong where the CA 
Recognition Authority is supposed to accredit CAs under the 
E-Tansactions Ordinance.  I say "technically" because participation in 
CARO and all similay systems even in Europe is weak.  There are costs 
involved and the cost-benefit remains uncertain while usage of 
certificates in open commerce remains low.  On the other hand, use of 
certificates in closed commerce is healthy but does not require 
independent homolugation because specific contracts apply.

If there is cause for government endorsement of digital certificates, 
then it follows that a conformance assessment regime is necessary, and 
there would generally be costs associated with participating.  Costs of 
doing business, just like the need for banks, medical establishments, 
airplane manufacturers and so on to be audited under all sorts of rules.

Cheers,

Steve Wilson
Lockstep
http://lockstep.com.au
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Schaad | 1 May 2012 07:32

FW: I-D Action: draft-ietf-pkix-pubkey-caps-06.txt

This update is to address IESG comments.

> -----Original Message-----
> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
> internet-drafts <at> ietf.org
> Sent: Monday, April 30, 2012 3:14 PM
> To: i-d-announce <at> ietf.org
> Cc: pkix <at> ietf.org
> Subject: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-06.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working
> Group of the IETF.
> 
> 	Title           : S/MIME Capabilities for Public Key Definitions
> 	Author(s)       : Jim Schaad
> 	Filename        : draft-ietf-pkix-pubkey-caps-06.txt
> 	Pages           : 25
> 	Date            : 2012-04-30
> 
>    This document defines a set of Secure/Multipurpose Internet Mail
>    Extensions (S/MIME) Capability types for ASN.1 encoding for the
>    current set of public keys defined by the PKIX working group.  This
>    facilitates the ability for a requester to specify information on the
>    public keys and signature algorithms to be used in responses.  An
>    example of where this is used is is detailed in Online Certificate
>    Status Protocol Algorithm Agility (RFC 6277).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
i-barreira | 2 May 2012 09:05

Re: License fee for running a PKI

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

AFAIK, not in the EU.

 

 

Iñigo Barreira
Responsable del Área técnica
i-barreira <at> izenpe.net

945067705

 

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

 

De: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] En nombre de Erik Andersen
Enviado el: lunes, 30 de abril de 2012 17:36
Para: PKIX
Asunto: [pkix] License fee for running a PKI

 

Hi Folks,

 

I have received questions for which I need help to answer. The question is as follows

 

- Is that any government requires payment of fees by electronic signature service providers

 

- If this is the case, what is the frequency of payment and above what is the amount

 

I believe that the first question is: Are there examples where a PKI service provider needs to pay a license fee to the government?

 

Any help is highly appreciated.

 

Erik

 

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
i-barreira | 2 May 2012 11:17

Re: License fee for running a PKI


-----Mensaje original-----
De: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] En nombre de Stephen Wilson
Enviado el: martes, 01 de mayo de 2012 7:20
Para: pkix <at> ietf.org
Asunto: Re: [pkix] License fee for running a PKI

Yes, in Europe, for all parties to fully enjoy the protections of qualified e-signatures laws, the CAs have
to be accredited under a recognised scheme like "tScheme".

Well, not always and not in every EU country

I thought the same thing applied in the very first digital signatures regime in Utah?  I thought CAs there had
to be licensed, and part of that was audit by a recognised accounting firm?

A similar scheme technically applies in Hong Kong where the CA Recognition Authority is supposed to
accredit CAs under the E-Tansactions Ordinance.  I say "technically" because participation in CARO and
all similay systems even in Europe is weak.  There are costs involved and the cost-benefit remains
uncertain while usage of certificates in open commerce remains low.  On the other hand, use of
certificates in closed commerce is healthy but does not require independent homolugation because
specific contracts apply.

If there is cause for government endorsement of digital certificates, then it follows that a conformance
assessment regime is necessary, and there would generally be costs associated with participating. 
Costs of doing business, just like the need for banks, medical establishments, airplane manufacturers
and so on to be audited under all sorts of rules.

Cheers,

Steve Wilson
Lockstep
http://lockstep.com.au

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Phillip Hallam-Baker | 3 May 2012 04:45
Picon

Re: TLS Security Policy Specification

On Mon, Apr 30, 2012 at 10:48 AM, Adam Langley <agl <at> chromium.org> wrote:
> On Fri, Apr 27, 2012 at 2:48 PM, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
>> The approach is slightly broader in principle but as the draft
>> explains, stapling is the only feature for which a certificate based
>> security policy is currently relevant.
>
> Generally, looks good to me.
>
> For the minVersion, using x to mean TLS 1.(x-1) seems unnecessarily
> complex. Why not have x mean TLS 1.x? (i.e. 0 -> TLS 1.0, 1 -> TLS 1.1
> etc?)

The problem is that TLS 1.0 has a version ID of 3,1 because 3,0 was
taken for SSL.

OK so if we never update the major version number it doesn't matter.
But if we did we would have a new policy oid for TLS 2.0 and that
would probably start from identifier {4,0}

> I think the following client behaviour needs to be specified:
>
> 1) what happens when minVersion is greater than what I support? Should
> I abort, or carry on as best I can?

You MUST conclude that there is a policy violation because the site
has said it will support the higher version and it isn't doing that.

What action you then take would be for client policy. I would
recommend abort in that case as it is really very rare for a version
number to go backwards like that... but it is not a compatibility
issue so it is for the client policy to decide.

> 2) what happens when extensions contains a value that I don't know
> about? Should I ignore it?

Ignore it. I will make that explicit.

The only thing that the policy says is that the extension will be
offered. If you don't understand the extension you MUST NOT ask for it
anyway as it would probably break you anyway.

--

-- 
Website: http://hallambaker.com/
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
internet-drafts | 6 May 2012 19:57
Picon
Favicon

I-D Action: draft-ietf-pkix-cmp-transport-protocols-17.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP
	Author(s)       : Tomi Kause
                          Martin Peylo
	Filename        : draft-ietf-pkix-cmp-transport-protocols-17.txt
	Pages           : 14
	Date            : 2012-05-06

   This document describes how to layer the Certificate Management
   Protocol over HTTP.  It is the "CMPtrans" document referenced in RFC
   4210 and therefore updates the reference given therein.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-17.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-17.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
internet-drafts | 7 May 2012 17:17
Picon
Favicon

I-D Action: draft-ietf-pkix-cmp-transport-protocols-18.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP
	Author(s)       : Tomi Kause
                          Martin Peylo
	Filename        : draft-ietf-pkix-cmp-transport-protocols-18.txt
	Pages           : 15
	Date            : 2012-05-07

   This document describes how to layer the Certificate Management
   Protocol over HTTP.  It is the "CMPtrans" document referenced in RFC
   4210 and therefore updates the reference given therein.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-18.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-18.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 1 comment |
headers
Sean Turner | 7 May 2012 18:32

Re: I-D Action: draft-ietf-pkix-cmp-transport-protocols-18.txt

The last two versions of this draft were produced as a result of the 
APPSDIR review.

spt

On 5/7/12 11:17 AM, internet-drafts <at> ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
>
> 	Title           : Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP
> 	Author(s)       : Tomi Kause
>                            Martin Peylo
> 	Filename        : draft-ietf-pkix-cmp-transport-protocols-18.txt
> 	Pages           : 15
> 	Date            : 2012-05-07
>
>     This document describes how to layer the Certificate Management
>     Protocol over HTTP.  It is the "CMPtrans" document referenced in RFC
>     4210 and therefore updates the reference given therein.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-18.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-18.txt
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/
>
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
housseine@rejouan.com | 10 May 2012 21:56

Question about the "Name Constraints" extension in OpenSSL

Hi All,

I am sorry to bother you but I am kind of stuck in how to setup the minimum and/or maximum for "Name Constraints" in OpenSSL mentioned in this document RFC 5280 , paragraph " 4.2.1.10. Name Constraints "

 

I looked over the net but I couldn't find any thing about the syntax that I can use in openssl config file:

I have the following setup but I need to set the minimum to 0 and I don't know the syntax. Everything I tried failed. 

 

nameConstraints = critical, excluded;URI:.mydomain.com;DNS:mydomain.com 

 

 

Can you please help or can you point me to some one who can help?

 

Thank you very much

Housseine

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 3 comments |

Gmane