[cabfpub] Ballot[80] - BR Response for non-issued certificates

[Yngve Nysaeter Pettersen]

This additional requirement will probably become part of the proposed IETF  
Operations Area WebPKI profile work that Tim will be presenting to the  
IETF SAAG next week.

On Tue, 24 Jul 2012 10:01:58 +0200, <y-iida at secom.co.jp> wrote:

> Like Symantec, while we, SECOM Trust Systems, agree the "spirit" of
> this ballot, we will not vote in favor unconditionally.
> We could vote "yes", if this requirement is adopted into the PKIX
> standardized requirement, or at least CABForum encourage PKIX to adopt
> it.

At present it seems that the PKIX WG consensus is not inclined to accept a  
general change in the definition of "good", at least not according to my  
private communications with the WG Chairs. I have been pondering a draft  
to propose such a change anyway, but it is not ready yet, and it may  
belong in the planned OpArea WG instead. It may be, though, that I will  
raise the issue with the WG next week, as part of the 2560bis discussion  
(however, I'd like to point out that if such a change in 2560bis is  
desired by the CABForum members, they will also need to say that in the  
PKIX WG, and help establish a consensus for changing the definition. One  
way to do that is by updating the BR to restrict the kind of "good"  
responses can be sent.) Unfortunately, the voting on this ballot closes  
the day after the PKIX WG meeting in Vancouver, so, in case it is passed,  
it will not be possible to reference a CABForum decision (either way) on  
this matter during the meeting.


> In RFC 2560, it reads:
>    The "good" state indicates a positive response to the status inquiry.
>    At a minimum, this positive response indicates that the certificate
>    is not revoked, but does not necessarily mean that the certificate
>    was ever issued or that the time at which the response was produced
>    is within the certificate's validity interval.
> This ballot seems to expect OCSP responders as validation authorities,
> while RFC 2560 accepts such behavior as one of optional alternatives.
> Members of CABForum do apply and conform to standards, but basic
> requirements should not go too far away from standards.
>
> We agree that the responder SHOULD NOT respond with a "good" status
> for non-issued certificates, but at this moment we think it is
> questionable to say that the responder MUST NOT do so.  It is too far
> away.

The proposed requirement is NOT incompatible with the definition of "good"  
in RFC 2560. IMO it is well within the scope of the definition. The  
proposal says that you can only return "good" for certificates that you  
know you have issued. 2560 says that "good" does not necessarily mean it  
is in the validity period or even issued, but that is a MAY type clause,  
not a SHOULD or MUST type (that is, the definition does not say you  
MUST/SHOULD return "good" for non-issued certs, but you MAY do so, if you  
implicitly don't have any information that can tell you that it does not  
exists; IMO "unknown" is for when you know you don't know anything,  
although RFC 5109 allows "unauthorized" for that). My proposal removes  
that possibility for hierarchies that are issuing certificates according  
to the BR, and the reason for the proposal is that allowing "good" for  
non-issued certificate would leave relying parties wide open to another  
DigiNotar type incident, where the attacker is able to hide the existence  
of the fraudulently issued certificates.

> We also think that it is preferable to make enough time for CA venders
> to develop such products and for CAs to deploy them.

I think six months is among the longest activation delays we've been  
using, except when removing issuing practices that significantly impact  
subscribers.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************