Re: SCVP-22 Open Issue: RFC 3379 Requirement #14

The origin of that point was handled end of 2001 for about 6 months. 
There were many
contributions, and you were actively involved.

I rediscovered that it was me to confirm the requirement for a textual
field following a debate with Denis who interpreted my request for an 
'identifier' as such
whilst I was thinking somthing like expressed in a messagez from Tom:

     Denis, Peter:

     I have one question about this proposal.  Is the object to be placed
into the response a transaction identifier or the RP's identifier?  If it's
the RP's identifier, IMO it should be called something like "requestor's
claimed identity" and it should not be permitted to be altered by the
server, although it might be permitted to be dropped.

           Tom Gindin

And I had this:

I have proposed in a different mail to Russ:
 The protocol MUST provide a means to allow a client and a server
 to indicate the participating entities.
I correct '... to indicate the identities of the entities participating in
the transction'.
and one may add "(depending on policy or application context)".

The discussion was stopped by Steve somehow

additional last call documents

Jim Schaad and Russ Housely reminded me that two other documents also 
were ready for last call as part of the CMC revisions:

draft-ietf-pkix-2797-bis-03

draft-ietf-pkix-cmc-comp-02

Consider these to be part ofg the same last call initiated last week.

Thanks,

Steve

Re: SCVP-22 Open Issue: RFC 3379 Requirement #14

Peter:

I recall your request for requester and responder identities.  I do 
not recall the origin of the text field requirement.

Russ

Re: SCVP-22 Open Issue: RFC 3379 Requirement #14

Russ Housley wrote:
> 
> I would suggest:
>     UTF8String (SIZE (1..256))

+1

Avoid OCTET STRING for textual data (character strings) whenever possible.

Ciao, Michael.

> 
> At 10:28 PM 1/30/2006, Tom Gindin wrote:
> 
>>         Russ:
>>
>>         Although several values of GeneralName are (IA5) text strings,
>> none of them are free-form ones, so they don't really fit this
>> requirement.  The solution given in your note seems better.  I do have
>> one
>> request for clarification, though.  Is the length limit 256 Unicode
>> characters, or 256 octets?  The text suggests Unicode characters, but it
>> isn't absolutely clear.  Given that the string is simply copied, a length
>> limit in octets might make more sense.  Indeed, in view of the fact that
>> the string's internal structure is not important to the server, it might
>> be wiser to encode it as an OCTET STRING.
>>
>>                 Tom Gindin
>>

CFP Third European PKI workshop: theory and practice (EuroPKI'06) -- Deadline extension

** My apologies if you receive multiple copies of this announcement **
-------------------------------------------------------------------
Call for Papers (deadline extension - until 12 February 2006)
EuroPKI 2006, Third European PKI workshop: theory and practice
Organized by: Politecnico di Torino, TORSEC security group
June 19 - 20, 2006   Torino (Italy)
http://security.polito.it/europki2006

The 3rd European PKI workshop: theory and practice is focusing on 
research and applications on all aspects of public-key certificates and 
Public Key Infrastructures. Submitted papers may present theory, 
applications or practical experiences on topics including, but not 
limited to:

- Modelling and Architecture
- Bridge CA
- Cross Certification
- Directories
- Mobile PKI
- Authentication
- Reliability in PKI
- Certificate Policy
- Privacy
- Fault-Tolerance in PKI
- Privilege Management and PMI
- PKI Performance Evaluation
- eCommerce, eBusiness, eGovernment applications
- Key Management and Recovery
- Certificate Status Information

RFC 4334 on Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4334

        Title:      Certificate Extensions and Attributes Supporting 
                    Authentication in Point-to-Point Protocol (PPP) and 
                    Wireless Local Area Networks (WLAN) 
        Author:     R. Housley,  T. Moore
        Status:     Standards Track
        Date:       February 2006
        Mailbox:    housley <at> vigilsec.com, 
                    timmoore <at> microsoft.com
        Pages:      11
        Characters: 20739
        Obsoletes:  RFC3770
        See-Also:   

        I-D Tag:    draft-ietf-pkix-rfc3770bis-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4334.txt

This document defines two Extensible Authentication Protocol (EAP)
extended key usage values and a public key certificate extension to
carry Wireless LAN (WLAN) System Service identifiers (SSIDs).  This
document obsoletes RFC 3770.  [STANDARDS TRACK]

This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF.

This is now a Proposed Standard Protocol.

RFC 4386 on Internet X.509 Public Key Infrastructure Repository Locator Service

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4386

        Title:      Internet X.509 Public Key Infrastructure 
                    Repository Locator Service 
        Author:     S. Boeyen,  P. Hallam-Baker
        Status:     Experimental
        Date:       February 2006
        Mailbox:    sharon.boeyen <at> entrust.com, 
                    pbaker <at> VeriSign.com
        Pages:      6
        Characters: 11330
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-pkix-pkixrep-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4386.txt

This document defines a Public Key Infrastructure (PKI) repository
locator service.  The service makes use of DNS SRV records defined in
accordance with RFC 2782.  The service enables certificate-using
systems to locate PKI repositories.This memo defines an Experimental Protocol for the Internet
community.  

This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. Discussion

OCSP response nextUpdate field

RE: OCSP response nextUpdate field

last call initiated

Folks,

I am initiating a WG last call for the lightweight OCSP profile:

  draft-ietf-pkix-lightweight-ocsp-profile-03.txt

I have provided the authors with an initial set of comments.

Please send your comments to the list by February 17th, 1.5 weeks from today.

Thanks,

Steve