headers
Internet-Drafts | 1 May 2008 18:00
Picon
Favicon

I-D ACTION:draft-ietf-pkix-rfc4055-update-01.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		: Update for RSAES-OAEP Algorithm Parameters
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-rfc4055-update-01.txt
	Pages		: 6
	Date		: 2008-5-1
	
This document updates RFC 4055.  It updates the conventions for using 
   the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding 
   (RSAES-OAEP) key transport algorithm with the Public-Key Cryptography 
   Standards (PKCS) #1 version 1.5 signature algorithm in the Internet 
   X.509 Public Key Infrastructure (PKI).  Specifically, it updates the 
   conventions for algorithm parameters in an X.509 certificate's 
   subjectPublicKeyInfo field.

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-pkix-rfc4055-update-01.txt): message/external-body, 68 bytes
(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


rfc-editor
 | 
9 May 2008 01:15






Favicon





RFC 5280 on Internet X.509 Public Key Infrastructure Certificate and	Certificate Revocation List (CRL) Profile



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

        
        RFC 5280

        Title:      Internet X.509 Public Key Infrastructure 
                    Certificate and Certificate Revocation List (CRL) 
                    Profile 
        Author:     D. Cooper, S. Santesson,
                    S. Farrell, S. Boeyen,
                    R. Housley, W. Polk
        Status:     Standards Track
        Date:       May 2008
        Mailbox:    david.cooper <at> nist.gov, stefans <at> microsoft.com, 
                    stephen.farrell <at> cs.tcd.ie, sharon.boeyen <at> entrust.com, 
                    housley <at> vigilsec.com, wpolk <at> nist.gov
        Pages:      151
        Characters: 352580
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-pkix-rfc3280bis-11.txt

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

This memo profiles the X.509 v3 certificate and X.509 v2 certificate
revocation list (CRL) for use in the Internet.  An overview of this
approach and model is provided as an introduction.  The X.509 v3
certificate format is described in detail, with additional information
regarding the format and semantics of Internet name forms.  Standard

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


rfc-editor
 | 
9 May 2008 19:38






Favicon





Corrected Announcement: RFC 5280 on Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile



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

        
        RFC 5280

        Title:      Internet X.509 Public Key Infrastructure 
                    Certificate and Certificate Revocation List (CRL) 
                    Profile 
        Author:     D. Cooper, S. Santesson,
                    S. Farrell, S. Boeyen,
                    R. Housley, W. Polk
        Status:     Standards Track
        Date:       May 2008
        Mailbox:    david.cooper <at> nist.gov, 
                    stefans <at> microsoft.com, 
                    stephen.farrell <at> cs.tcd.ie, sharon.boeyen <at> entrust.com, 
                    housley <at> vigilsec.com, wpolk <at> nist.gov
        Pages:      151
        Characters: 352580
        Obsoletes:  RFC3280, RFC4325, RFC4630

        I-D Tag:    draft-ietf-pkix-rfc3280bis-11.txt

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

This memo profiles the X.509 v3 certificate and X.509 v2 certificate
revocation list (CRL) for use in the Internet.  An overview of this
approach and model is provided as an introduction.  The X.509 v3
certificate format is described in detail, with additional information

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Stefan Santesson
 | 
14 May 2008 23:31






Picon

Favicon





RE: Corrected Announcement: RFC 5280 on Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile



So finally, the successor of RFC 3280 has been published.

I want to extend a thank you to all participants in this work group that helped in the effort to get this
standard published.
A special thanks to David Cooper who has done most of the tracking of issues and document changes throughout
the editorial process.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of rfc-editor <at> rfc-editor.org
> Sent: den 9 maj 2008 19:39
> To: ietf-announce <at> ietf.org; rfc-dist <at> rfc-editor.org
> Cc: rfc-editor <at> rfc-editor.org; ietf-pkix <at> imc.org
> Subject: Corrected Announcement: RFC 5280 on Internet X.509 Public Key
> Infrastructure Certificate and Certificate Revocation List (CRL)
> Profile
>
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 5280
>
>         Title:      Internet X.509 Public Key Infrastructure

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


David A. Cooper
 | 
15 May 2008 22:03






Favicon





Re: RFC 3280 valid_policy_tree clarification sought



Nelson,

The successor to RFC 3280, RFC 5280 has been published, but I do not 
believe that it includes any changes that would be relevant to this 
discussion.

The intention of section 6.1.5, step (g) was for the valid_policy_tree 
to be modified to be the result of computing the intersection.  While 
the wording could have been better, I believe that this is how step (g) 
works.  For the cases covered by steps (i) and (ii), creating the 
intersection of the valid_policy_tree and the user-initial-policy-set 
does not modify the valid_policy_tree.  So, sentences could have been 
added to the ends of steps (i) and (ii) stating:  "So, no changes need 
to be made to the valid_policy_tree."  In step (g)(iii), nodes in the 
valid_policy_tree that are not in the intersection with the 
user-initial-policy-set are deleted from the valid_policy_tree.

In RFC 3280 (and RFC 5280), the decision to output only the intersection 
was based on the assumption that a user specifying a value for 
user-initial-policy-set other than any-policy intends for the 
user-initial-policy-set to be interpreted as a requirement and not just 
a set of preferred policies, in which case the user would have no 
interest in policies that are not in the user-initial-policy-set.  A 
user who would be willing to consider other policies could just always 
set user-initial-policy-set to any-policy, and then do some 
post-processing on the output to determine whether the path was valid 
for any of the "preferred" policies.  In the case of a browser, I would 
guess that it would rarely make sense to use a value for 
user-initial-policy-set other than any-policy.  I would guess that 

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Tom Gindin
 | 
20 May 2008 04:25






Picon

Favicon





Basic Constraints and Key Usage



        I suggest that it is best practice for a CA to include a Key Usage 
extension in any certificates it issues which contain the CA flag in the 
Basic Constraints extension set to true.  RFC 5280 section 4.2.1.3 already 
requires that any certificate used for certificate or CRL signing contain 
KeyUsage.  Section 6.1.4 steps k and n permit the acceptance of a 
certificate with Basic Constraints.CA true but with KeyUsage absent as a 
valid intermediate CA certificate.
        If the private key of such a certificate is later compromised, the 
illegitimate possessor of the private key can issue certificates which 
might pass verification.  If the KeyUsage extension is set in a CMP server 
certificate, such an illegitimate possessor would not be able to issue 
certificates.  It's a smaller exposure than the one where end-entity 
certificates were used as certificate issuers, because there are many 
fewer CMP server certificates and the like than there are end-entity 
certificates, but it's the same kind of exposure.  Not all Relying Party 
software checks revocation on intermediate certificates.

                Tom Gindin







Permalink
| Reply
| 4 comments  
| 



  

  

  





headers


Todd E. Johnson
 | 
21 May 2008 00:37






Picon

Favicon





Re: Basic Constraints and Key Usage



Hello Tom,

I am somewhat confused.  If the private key is compromised, the 
certificate should simply be revoked with the CRLReason of 
keyCompromise.  You simply rekey, move on, and place no trust in 
anything signed by the compromised keys after InvalidityDate.  Perhaps I 
over simplify this in many ways, however, it may be that I completely 
misunderstand your point.

To your last sentence, and the reason I felt compelled to reply:

It appears to me that RFC 5280 section 6.1.3 requires "at the current 
time" revocation checking MUST occur for "certificate i (for all i in 
[1..n])".

I personally feel that Relying Party software that does not perform this 
very basic check is simply a waste of time, since it appears the 
software is only "partially" performing "Basic" certificate processing. 
  I would imagine this would also be considered best practice on the 
part of the relying party.  (I.e., The Issuer can claim "Well, we 
provided the revocation data, the relying party simply didn't check!")

I had to re-word the above sentences quite a few times in order not to 
appear too critical of software developers whom don't check the entire 
path for revocation.

Tom Gindin wrote:
>         I suggest that it is best practice for a CA to include a Key Usage 
> extension in any certificates it issues which contain the CA flag in the 

(Continue reading)






Permalink
| Reply
| 3 comments  
| 



  

  

  





headers


Santosh Chokhani
 | 
21 May 2008 02:08






Favicon





RE: Basic Constraints and Key Usage



I do not have problem with Tom's preference for using key usage.

In personal exchange, I shared the same concern with him.

May be what Tom means is that the CMP Server key may not be as well
protected as certificate signing key and without key usage in it, an
undetected compromise of less protected key can lead to bigger or easier
damage due to lack of key usage limitations in the certificate. 

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
On Behalf Of Todd E. Johnson
Sent: Tuesday, May 20, 2008 6:37 PM
To: Tom Gindin
Cc: pkix
Subject: Re: Basic Constraints and Key Usage

Hello Tom,

I am somewhat confused.  If the private key is compromised, the 
certificate should simply be revoked with the CRLReason of 
keyCompromise.  You simply rekey, move on, and place no trust in 
anything signed by the compromised keys after InvalidityDate.  Perhaps I

over simplify this in many ways, however, it may be that I completely 
misunderstand your point.

To your last sentence, and the reason I felt compelled to reply:


(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Todd E. Johnson
 | 
21 May 2008 04:30






Picon

Favicon





Re: Basic Constraints and Key Usage



Hello,

I assume keyUsage is best practice, perhaps a bit too much since I like 
to ensure it is asserted critical, in every certificate issued by the CA.

However, is this more of an implementation issue?  If the the risk is so 
great, would ephemeral signing keys be too silly?

Santosh Chokhani wrote:
> I do not have problem with Tom's preference for using key usage.
> 
> In personal exchange, I shared the same concern with him.
> 
> May be what Tom means is that the CMP Server key may not be as well
> protected as certificate signing key and without key usage in it, an
> undetected compromise of less protected key can lead to bigger or easier
> damage due to lack of key usage limitations in the certificate. 
> 
> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Todd E. Johnson
> Sent: Tuesday, May 20, 2008 6:37 PM
> To: Tom Gindin
> Cc: pkix
> Subject: Re: Basic Constraints and Key Usage
> 
> 
> Hello Tom,
> 

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Santosh Chokhani
 | 
21 May 2008 13:19






Favicon





RE: Basic Constraints and Key Usage



I agree that this should be treated as an implementation issue.

Thus, a short discussion of this topic is appropriate for the Security
Considerations section of 5280.  The current RFC does not treat this
issue.

Separately, I noted that 5280 sings the virtues of self-issued
certificates in Security Considerations without discussing their
inherent security flaw and mitigation (see my paper in 2005 or so NIST
PKI research conference).  A short treatment of pitfalls of self-issued
is also warranted.

-----Original Message-----
From: Todd E. Johnson [mailto:tejohnson <at> yahoo.com] 
Sent: Tuesday, May 20, 2008 10:30 PM
To: Santosh Chokhani
Cc: Tom Gindin; pkix
Subject: Re: Basic Constraints and Key Usage

Hello,

I assume keyUsage is best practice, perhaps a bit too much since I like 
to ensure it is asserted critical, in every certificate issued by the
CA.

However, is this more of an implementation issue?  If the the risk is so

great, would ephemeral signing keys be too silly?


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane