Subject: RE: WG Last Call Comment for 3280bis

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 14 Dec 2006 18:45:40 -0800

Tim and all,

I am ok with the change.  But, we need to make the RFC consistent with
this change.  Section 6.1.3, item 3.  It says that "At the current time,
the certificate is not revoked and is not on hold status".  I would
think that should be changed to "At the current time, the certificate is
not revoked for the reasons of interest to the relying party".

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Boeyen
Sent: Thursday, December 14, 2006 11:41 AM
To: 'Stefan Santesson'; Tim Polk; [email-masked]
Subject: RE: WG Last Call Comment for 3280bis

I think this is definitely the simplest approach and support it too. 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson 
Sent: Thursday, December 14, 2006 10:36 AM 
To: Tim Polk; [email-masked] 
Subject: RE: WG Last Call Comment for 3280bis 

I'm also fine with this approach. 

Stefan Santesson 
Senior Program Manager 
Windows Security, Standards 

> -----Original Message----- 
> From: [email-masked] [mailto:owner-ietf- 
> [email-masked]] On Behalf Of Tim Polk 
> Sent: den 13 december 2006 23:00 
> To: [email-masked] 
> Subject: RE: WG Last Call Comment for 3280bis 
> 
> 
> 
> Folks, 
> 
> I have some troubles with the direction of the discussion on the 
> certificate hold instruction, but I believe there is a very simple 
> solution. 
> 
> The problem is this: X.509 defined the CRL entry extension but did not

> specify any codes; X9.57 defined the hold instruction codes.  Since 
> the X9 codes are oriented towards the financial services industry, 
> they don't really apply to most Internet applications.  Specifically, 
> I find it hard 
> to imagine a lot of Internet applications where someone calls the 
> issuer to 
> verify the certificate status.  However, redefining the codes is not a

> good 
> solution.  We should not be telling relying parties to process these 
> codes 
> according to an alternative set of rules. 
> 
> Since everyone seems to be uncomfortable with the hold instruction 
> code CRL entry extension, and even more uncomfortable with the only 
> defined hold instruction codes, the solution is straightforward. We 
> should follow the 
> model used with the private key usage period certificate extension.
We 
> should remove the extension from 3280bis in its entirety (as opposed
to 
> including it and deprecating its use.) 
> 
> I can't see a reason that removing this extension would cause 
> problems.  Relying parties that process a CRL containing an 
> unrecognized noncritical extension will ignore it.  Relying parties 
> that support this 
> extension and the X9.57 codes (presumably to support the financial 
> services 
> applications) need to be aware of the semantics for these codes and 
> enforce 
> them.  I admit to some confusion about these semantics myself, but it 
> isn't 
> PKIX's responsibility to clarify these semantics! 
> 
> I think the real problem here is an error of omission in section 
> 5.3.1, reason code.  The description of this CRL entry extension 
> assumes that the names of the reason codes are self explanatory.  The 
> entire text for 5.3.1 
> follows: 
> 
> 
> >The reasonCode is a non-critical CRL entry extension that identifies 
> the 
> >reason for the certificate revocation. CRL issuers are strongly 
> encouraged 
> >to include meaningful reason codes in CRL entries; however, the 
> >reason code CRL entry extension SHOULD be absent instead of using the

> unspecified 
> >(0) reasonCode value. 
> 
> I suggest adding the following text after the current paragraph: 
> 
> >The removeFromCRL (8) reasonCode  value may only appear in delta 
> >CRLs, 
> and 
> >indicates that a certificate is to be removed from a CRL because 
> either 
> >the certificate expired or was removed from hold.  All other reason 
> codes 
> >may appear in any CRL, and indicate that the specified certificate 
> should 
> >be considered revoked.  It is a relying party decision whether a 
> >particular revocation reason precludes acceptance of a revoked 
> certificate. 
> 
> My two cents. 
> 
> Tim Polk

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Dec 2006 14:45:27 -0500

Tim:

I fully support this direction.

Russ

> From:
[email-masked]
[mailto:owner-ietf-

> model used with the private key usage period
certificate extension.  We

> should remove the extension from 3280bis in its
entirety (as opposed to