headers
Kurt D. Zeilenga | 1 Dec 2004 01:48

draft-ietf-pkix-ldap-*: security considerations


The security considerations sections of these documents
are inadequate and seem to nothing more than echo
general security concerns.  Given the nature of the
information being stored, I would suspect there would
be some significant other considerations.  In particular,
I am surprised not to see any discussion (in the security
consideration section or elsewhere) on the impact of
data inconsistencies between user and certificate objects.

Kurt
Permalink | Reply | 2 comments |
headers
Kurt D. Zeilenga | 1 Dec 2004 01:24

draft-ietf-pkix-ldap-* consistency issues


draft-ietf-pkix-ldap-pkc-schema-01 basically proposes to copy certificate
information from the entries representing the entity which possess the
certificate to a separate certificate entry.  I consider relocation not to
be feasible option whatsoever as it will simply break some
existing clients which use basic certificate matching, as well as
existing and future clients which makes component matching with
certificates.  However, the document actually reads as if relocation
of the information is intended.

This text causes me concern:
>   If certificates are stored redundantly in person entries and in      
>   certificate entries below the person entries, maintainers of
>   repositories MUST make sure that the same certificates are stored in
>   the person entry and the respective certificate entries and keep this
>   consistency.  Alternatively, they MUST leave out any certificates in
>   the person entry.

Now, given that maintainers will be hard pressed to ensure
consistency, this specification has stated that the standard
track approach of storing certificates in the person entry
is not to be followed.   This MUST will lead to breakage.

Instead, this document needs to needs to make it clear that
certificates will be stored redundantly, there will be
consistency issues, and then discuss how applications are
to address these consistency issues.

Kurt
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Josefsson | 1 Dec 2004 03:55

Re: Please review X.509 part of RFC 2538bis


"Sean P. Turner" <turners <at> ieca.com> writes:

> Simon Josefsson wrote:
>
>>3.  Appropriate Owner Names for CERT RRs
>>
>>   It is recommended that certificate CERT RRs be stored under a domain
>>   name related to their subject, i.e., the name of the entity intended
>>   to control the private key corresponding to the public key being
>>   certified.  It is recommended that certificate revocation list CERT
>>   RRs be stored under a domain name related to their issuer.
>>
>>  
>>
> Should "recommended" be "RECOMMENDED" in the 1st and 2nd sentences?

Whether to enforce CERT RR owner name with RFC 2119 language appear to
be somewhat of a touchy issue.  Some are suggesting to even use SHOULD
or MUST.  I'm adding this as an open issue.

Thanks,
Simon
Permalink | Reply | 0 comments |
headers
Steven Legg | 1 Dec 2004 05:48

Re: WG Last Call: Certificate Schema


David,

David Chadwick wrote:
> Since that time (Spring 2003) suppliers have not moved that far (if at 
> all) towards supporting component matching. Only Steven Legg's 
> Australian company, which had supported component matching prior to 
> publication of the RFCs, and OpenLDAP which I believe can now support 
> it, have done anything in this direction. Attribute extraction on the 
> other hand has double that amount of supporting implementations, plus 
> all clients can naturally support it without any code change.

So is that four client implementations that have support for adding and
modifying entries with certificates according to the attribute extraction
schema using any LDAP directory, or is that four client implementations
that depend on the XPS server to do the attribute extraction for them ?
Isn't there only one XPS(-like) server implementation ? I'm not sure you are
comparing like with like.

Incidentally, yesterday a colleague of mine configured a third-party
LDAP client with no built-in knowledge of component matching to use
component matches in its filters. No re-coding was necessary. Any client
that is configured with LDAP filters in string format or LDAP URLs is
already able to use component matching or the X.509 matching rules.

Regards,
Steven
Permalink | Reply | 2 comments |
headers
Peter Gietz | 1 Dec 2004 14:20
Picon
Favicon

Re: WG Last Call: Certificate Schema


Kurt,

some more remarks from my side.

Kurt D. Zeilenga wrote:

>David,
>
>While there may have been some in this WG that viewed the
>value extraction approach as a pragmatic solution to various
>specific issues, I believe there are also many, like myself,
>who have never considered the value extraction approach, in
>general, to be practical.  And, as I noted in my previous
>response, I do not consider the value extraction approach
>as applied here to certificates and such to be pragmatic
>as it simply does not address requirements I am faced with.
>  
>
One requirement addressed by value extraction is to return to the client 
only the certificate the client needs.
This requirement is not addressed by Component Matching. Only in 
combination with the return value filter (RFC 3876), which defines an 
LDAP control that again has to be supported by Clients and Servers, such 
a behaviour could be implemented. I guess that vendor's support for this 
is even less than for component matching.

>In particular, how does this approach providing for matching
>upon components of the subject (or other) DNs in the certificate?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gabriel López | 1 Dec 2004 17:37
Picon
Favicon

Attribute Certificates request and response protocol


    Dear all,

    I'm looking for a transport protocol able to encapsulate an AC 
request and response messages.
    The idea es how an entity can requet an user's AC to another entity, 
instead to access directly to a LDAP repository.
    I have saw that CMP (draft-ietf-pkix-rfc2510bis-09.txt) can 
transport a x509v3PKCert object, which could be instantiated like a x509 
certificate, AC, etc..

    There is any other alternative to the use of  LDAP or CMP? TLS/SSL, ...?

     Thanks, Gabi.

--

-- 
Gabriel López Millán (http://pki.dif.um.es)
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
Apartado 4021
30001 Murcia
Telf: +34-968-367645
fax: +34-968-364151
Permalink | Reply | 2 comments |
headers
Kurt D. Zeilenga | 1 Dec 2004 17:57

Re: WG Last Call: Certificate Schema


At 05:20 AM 12/1/2004, Peter Gietz wrote:
>Kurt,
>
>some more remarks from my side.
>
>Kurt D. Zeilenga wrote:
>
>>David,
>>
>>While there may have been some in this WG that viewed the
>>value extraction approach as a pragmatic solution to various
>>specific issues, I believe there are also many, like myself,
>>who have never considered the value extraction approach, in
>>general, to be practical.  And, as I noted in my previous
>>response, I do not consider the value extraction approach
>>as applied here to certificates and such to be pragmatic
>>as it simply does not address requirements I am faced with.
>> 
>One requirement addressed by value extraction is to return to the client only the certificate the client needs.

Which certificate is that?  Maybe what the client wants is all certificates of
the person which holds a certificate whose subject DN contains a CN of X.

This highlights one of the problems with this approach.  It seems to be designed
with a specific subset of PKI applications in mind.  The solution, IMO, is not as
broadly applicable as its being made out to be.

>This requirement is not addressed by Component Matching. Only in combination with the return value
filter (RFC 3876), which defines an LDAP control that again has to be supported by Clients and Servers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Seth Hitchings | 1 Dec 2004 18:29
Favicon

SCVP 16 Comments

Hi all,

My company, CoreStreet Ltd, is currently developing an implementation of SCVP. We've recently updated
our software to reflect the
changes made in draft 16 and have found that there are many ambiguities in the specification, both in the
ASN.1 module and in the
descriptions of how various elements are meant to be used. 

Given the number of changes that will have to be made to draft 16, I wonder if it won't be necessary to permit
another round of
review before submitting the final draft to the RFC editors. I know that there is a lot of pressure for draft
17 to be the final
draft and to get this process completed, but it is in all of our best interest that the final draft be as clear
and usable as
possible.

I have sent most of my feedback on draft 16 directly to the editors, but I have a few questions that I'd like the
entire list
consider.

1) The 'check' for building a certification path to a trusted root has been removed, implying that an SCVP
server can only returns
paths that meet a local validation policy on the server. In a DPD environment, I believe that the client
should be able to control
whether the server performs validation. As such, I would like to see id-stc-build-pkc-path and
id-stc-build-aa-path restored in
draft 17. 

2) The want back for all paths, id-swb-pkc-all-valid-cert-paths, should be changed to
id-swb-pkc-all-cert-paths. The level of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jong-Hyuk | 2 Dec 2004 06:28
Picon
Favicon

Re: WG Last Call: Certificate Schema


> Since that time (Spring 2003) suppliers have not moved that far (if at
> all) towards supporting component matching. Only Steven Legg's Australian
> company, which had supported component matching prior to publication of
> the RFCs, and OpenLDAP which I believe can now support it, have done
> anything in this direction. Attribute extraction on the other hand has
> double that amount of supporting implementations, plus all clients can
> naturally support it without any code change.

Clients can be considered to naturally support Component Matching if they
accept search filters in a text form and they support extensibleMatch. It is
observed that many clients fall into this category. For those clients who
have search filters hard-coded and / or do not support extensibleMatch, the
OpenLDAP implementation of Component Matching further supports attribute and
matching rule aliases. In attribute aliasing, an alias attribute in the
search filter is converted by the server into the predefined aliased
component reference and the assertion value is used as the corresponding
component assertion value. The matching rule alias is used in a similar way.
The aliasing mechanism can also be considered as an optimization which
eliminates the extra processing steps for ComponentFilter parsing. We will
provide performance evaluation results of Component Matching to show that it
can be implemented in LDAP servers without performance degradation and
increase in complexity.
- Jong-Hyuk

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P.O. Box 218, Yorktown Heights, NY 10598
jongchoi <at> watson.ibm.com
(Continue reading)

Permalink | Reply | 501 comments |
headers
Stephen Farrell | 2 Dec 2004 14:47
Picon
Picon

Re: Attribute Certificates request and response protocol


Hi,

Once upon a time we did start work on such a thing [1]. To be
honest, I can't even remember why we stopped - probably due
to lack of interest;-)

Regards,
Stephen.

[1] http://www.netzmafia.de/rfc/internet-drafts/draft-ietf-pkix-laap-01.txt

Gabriel López wrote:

> 
> 
>    Dear all,
> 
>    I'm looking for a transport protocol able to encapsulate an AC 
> request and response messages.
>    The idea es how an entity can requet an user's AC to another entity, 
> instead to access directly to a LDAP repository.
>    I have saw that CMP (draft-ietf-pkix-rfc2510bis-09.txt) can transport 
> a x509v3PKCert object, which could be instantiated like a x509 
> certificate, AC, etc..
> 
>    There is any other alternative to the use of  LDAP or CMP? TLS/SSL, ...?
>  
>     Thanks, Gabi.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane