headers
Denis Pinkas | 5 Jul 2002 12:14
Picon

Attribute Certification


Request for public comments on Draft ETSI TR 102 044 V0.0.7 (2002-07):

"Identification of requirements for attribute certification"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
technical report to identify a set of requirements that will provide a basis
on which a subsequent standard can build policy requirements for attributes
certified by Attribute Authorities or Certification Authorities either in a
subject's PKCs (Public Key Certificates) or in ACs (Attribute Certificates).

The scope of this document is to extensively investigate on the attribute
certification related topics in order to cover the general use of certified
attributes in the context of electronic signatures, but attributes that can
be used in such a context can also be used for other reasons, e.g.: for
authorisation.

COMMENTS ARE REQUESTED BY 8 TH SEPTEMBER 2002. Details of how to obtain
a copy of this document and submit comments are given towards the end of
this message.

BACKGROUND

The development of policy documents is one of the tasks the ETSI Electronic
Signature and Infrastructure Working Group is progressing within the
European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.
(Continue reading)

Permalink | Reply | 0 comments |
headers
forward | 1 Jul 2002 04:23
Picon
Favicon

about test server


Hi all:
I know this email list is not about SCEP. But I want to know where can I
find a test SCEP CA server.
Thanks very much!

Forward.li

_________________________________________________________
Do You Yahoo!?
Get your free  <at> yahoo.com address at http://mail.yahoo.com
Permalink | Reply | 0 comments |
headers
王炳艳 | 1 Jul 2002 10:10
Picon

Question about RootCA


 I was puzzled by the term "root CA" in rfc2510 (CMP).

 The below paragraph is from 1.2.2. 
    We use the term "root CA" to indicate a CA that is directly trusted
    by an end entity; that is, securely acquiring the value of a root CA
    public key requires some out-of-band step(s). This term is not meant
                                                  ----------------------
    to imply that a root CA is necessarily at the top of any hierarchy,
    ------------------------------------------------------------------
    simply that the CA in question is trusted directly.
    --------------------------------------------------
 If there are two CA certificates,
                cert a                       cert b(signed by cert a)
    Issuer    C=US,OU=TSA,CN=a            C=US,OU=TSA,CN=a

    subject   C=US,OU=TSA,CN=a            C=US,OU=TSA,CN=b

 According to the above statement, certificate b is a "root CA" if there is an 
 end entity trust it.

 Then comes the question about Root CA Key update in Section 2.4.    
    The basis of the procedure described here is that the CA protects its
    new public key using its previous private key and vice versa. Thus
    when a CA updates its key pair it must generate two extra cACertificate 
    attribute values if certificates are made available using an X.500 directory 
    (for a total of four:  OldWithOld; OldWithNew; NewWithOld; and NewWithNew).
                           --------------------------------------------------
 If the CA operator want to update key for cert b, what does the four certificate mean?
                OldWithOld        OldWithNew        NewWithOld         NewWithNew
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Jul 2002 12:38
Picon
Favicon

I-D ACTION:draft-ietf-pkix-logotypes-03.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 Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-03.txt
	Pages		: 18
	Date		: 28-Jun-02
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the ietf-pkix <at> imc.org
mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-logotypes-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 2 comments |
headers
Internet-Drafts | 1 Jul 2002 12:38
Picon
Favicon

I-D ACTION:draft-ietf-pkix-ldap-pmi-schema-00.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 LDAP Schema 
                          and Syntaxes for PMIs
	Author(s)	: D. Chadwick, S. Legg
	Filename	: draft-ietf-pkix-ldap-pmi-schema-00.txt
	Pages		: 
	Date		: 28-Jun-02
	
This document describes LDAP schema features that are needed to support 
X.509 Privilege Management Infrastructures. Specifically, X.509 
attribute types, object classes, matching rules, attribute value 
syntaxes and attribute value assertion syntaxes needed for PMIs are 
defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pmi-schema-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-pmi-schema-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Jul 2002 12:38
Picon
Favicon

I-D ACTION:draft-ietf-pkix-ldap-pki-schema-00.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 LDAP Schema 
                          and Syntaxes for PKIs
	Author(s)	: D. Chadwick, S. Legg
	Filename	: draft-ietf-pkix-ldap-pki-schema-00.txt
	Pages		: 
	Date		: 28-Jun-02
	
This document describes LDAP schema features that are needed to support 
X.509 Public Key Infrastructures. Specifically, X.509 attribute types, 
object classes, matching rules, attribute value syntaxes and attribute 
value assertion syntaxes needed for PKIs are defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pki-schema-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-pki-schema-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Brauckmann | 1 Jul 2002 14:17
Picon
Favicon

Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt


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 Logotypes in
>                           X.509 certificates
>         Author(s)       : S. Santesson, R. Housley, T. Freeman
>         Filename        : draft-ietf-pkix-logotypes-03.txt
>         Pages           : 18
>         Date            : 28-Jun-02

Hi.

**** Page 6, at the end of chapter 3:
   Applications SHOULD enhance processing and off-line functionality by
   cashing logotype data.
   ^^^^^
Funny typo:-) Who cashes whom?;-)

**** LogotypeImageInfo and LogotypeAudioInfo:
In my opinion these data structures lack something like "descriptiveText
UTF8String OPTIONAL" that could be displayed if the source of the images
or audio data is currently unavailable or the data cannot be retrieved. 

I can imagine many situations where retrieval of data is not possible,
but nevertheless the functionality of community branding is desired. And
in such situations it would be helpful if the application could present
a simple string to the user.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Gindin | 1 Jul 2002 19:33
Picon
Favicon

Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt


      Actually, Juergen, only 3 of the 4 fields get converted to EXPLICIT.
Of course, with only a single IMPLICIT left it would be simpler just to
make that one (otherLogos) IMPLICIT SEQUENCE OF.  I would also suggest that
LogotypeInfo be changed as follows:

      LogotypeInfo ::= CHOICE {
         direct          LogotypeData,
         indirect  [30]  IMPLICIT LogotypeReference }

            Tom Gindin

Juergen Brauckmann <brauckmann <at> trustcenter.de> <at> mail.imc.org on 07/01/2002
08:17:51 AM

Sent by:    owner-ietf-pkix <at> mail.imc.org

To:    ietf-pkix <at> imc.org
cc:
Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt

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
Logotypes in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Housley, Russ | 1 Jul 2002 19:19

Re: draft-ietf-pkix-warranty-extn-01


Denis:

> > > > [REVISED TEXT:]  A relying party may obtain compensation from a CA 
> depending
> > > > on the conditions for such compensation expressed in either the CA's
> > > > Certificate Policy or the CA's insurance policy, or both.
> > >
> > >I believe that Russ said that the CA's insurance policy was included 
> in the
> > >CA's Certificate Policy. The "or" is not appropriate.
> >
> > That depends on the structure of the policy.  The CA might self-insure for
> > small claims, and have an insurance policy for larger ones.
>
>I disagree: what is important is what is visible for the relying parties.
>Self-insurance or back up insurance is a level of detail that is internal to
>the CA. This does not have to be visible to the relying party. The "or" is
>still not appropriate.

I think we are saying the same thing.  The CA might self-insure, get a 
policy from an insurance company, or a combination of the two.  This is of 
no interest to the relying party.  The replying party only cares that 
compensation is available.  If there is a problem, the relying party will 
contact the CA to make her claim.

Russ
Permalink | Reply | 0 comments |
headers
Housley, Russ | 1 Jul 2002 19:00

Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt


Juergen:

Right after sending my last reply, I realized that I was much too hasty in 
my reply to this comment.  Please disregard my previous response.

In general, I do not like EXPLICIT tagging.  But you are correct that there 
is a problem here.  I want to consider alternative solutions and get advice 
from others about how this has been handled in other protocols.  I will 
post a proposed fix soon.

Russ

>**** ASN.1:
>You declare the Module as IMPLICIT TAGS. But the only use of tags is
>LogotypeExtn ::= SEQUENCE {
>          communityLogo  [0] LogotypeInfo OPTIONAL,
>          issuerLogo     [1] LogotypeInfo OPTIONAL,
>          subjectLogo    [2] LogotypeInfo OPTIONAL,
>          otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }
>
>       LogotypeInfo ::= CHOICE {
>          direct          LogotypeData,
>          indirect        LogotypeReference }
>
>Here, the tags are converted silently by clause 30.6 c) of X.680 into
>EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on CHOICEs
>are implicitely EXPLICIT or something like that). In my opinion the
>module would be better readable for implementors if you would declare it
>as EXPLICIT.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane