It is impossible to write a text that cannot deliberately be misunderstood.
This debate is so full of constructed, non-existent problems.
Nothing has changed for the clients. The client can receive an error, or
they can receive (good, revoked or unknown).
The meaning of those responses are pretty
> It may be useful to keep in mind that the CA may have issued the
"non-issued" certificate
[Piyush]
This is what I think will be confusing to many implementers :), who did not
participate in the WG discussions.
But then, it is an assumption on my part and you for one have proved that
the assumpti
Piyush,
> I think I failed to clarify this in my last message. Let me try again. I
> based my interpretation on the following response from Stefan :
[ ... snip ...]
> The above explanation at the minimum indicates the author's intent that
> clients should treat such certificates as "revoked" and
> I'd rather not try to describe what clients should do or expect in terms
of
> non-issued certificates.
> Clients are really not meant to know anything beyond "revoked" = this cert
> should not be trusted.
[Piyush]
Thanks for clarifying your position on this Stefan.
This is the position I disagre
> I do not see that prohibition in the new text in -16. In the cited email
> message, I do see a disagreement between you and Stefan about what
> implementations are likely to do, but I don't see any text in the draft
that
> dictates that implementations must or must not make that interpretation.
On 4/9/13 2:35 PM, "Black, David" wrote:
>Again speaking for myself, I think the current text in -16 is ok, in that
>I
>don't see the prohibition that Piyush is concerned about there. OTOH,
>I'd also
>be ok with a couple of sentences added to say that (new) clients could use
>that response forma
> I guess it would be okay if you and David make the determination that this
> issue is not worth debating anymore but I would surely have appreciated
> hearing the opinions of a few others.
I'm not sure how much of a say I have in that determination - Sean (as AD)
is absolutely free to acknowledg
> I went back and looked at the WG poll about this issue that you and lot of
> other people participated in (https://www.ietf.org/mail-
> archive/web/pkix/current/msg31906.html). The WG's rough consensus was
> to allow "revoked" to be used for non-issued certificates with the caveat
> thrown in by
On 4/8/13 5:59 PM, Piyush Jain wrote:
Sean,
Thanks for your comments.
There are two points that I would like to cover separately. The first point
is a response to your comments below. The second point is a broader
objection to revoked for issued.
1) The text says - The "revoked" status is still
Sean,
Thanks for your comments.
There are two points that I would like to cover separately. The first point
is a response to your comments below. The second point is a broader
objection to revoked for issued.
1) The text says - The "revoked" status is still optional in this context in
order to ma
Piyush,
(David's on the "to:" line because the text in question showed up as a
result of the gen-art review and it's now in -16)
I've been following this thread trying to figure out what if anything
needs to be changed to address your concerns in -17. (Note the thread
forked later, but I'm
> No, it does not make any sense at all. An error code is unsigned and can
be
> easily inserted into the communication by an attacker.
[Piyush] Funny that you make this argument. How does returning a signed
revoked address this? Attacker can still replace signed revoked with an
UNSIGNED TRY_LATE
I have strong doubts that regurgitating the entire previous
discussion is going to help.
Piyush Jain wrote:
> >
> > If you want to describe "an OCSP responder no longer responding 'good'
> > for certificate serial numbers for which no records of issuance exist"
> > as "breaking compatibility wit
> There is *NO* overloading of a revoked status. The change is making use
of
> an existing temporary revocation status (certificateHold) **EXACTLY** with
> the original semantics for a temporary revocation, originating from X.509
> 08/2005 8.5.2.2 (a):
>
[Piyush] Revokes status is being used to c
Piyush Jain wrote:
>
> The sole reason cited for overloading the meaning of revoked status with
> non-issued was that it allows new servers to interoperate with legacy
> clients.
There is *NO* overloading of a revoked status. The change is making use
of an existing temporary revocation status (c
Agreed.
The text, however incorrectly states
"revoked" status is still optional in this context in order to maintain
backwards compatibility with deployments of RFC 2560.'
Please note the subtle difference between being backward compatible with
deployments and being compliant with standards.
>
Legacy servers would not comply with RFC2560bis IF revoked response for
non issued certs would be required.
/Stefan
On 3/29/13 10:06 PM, "Piyush Jain" wrote:
>Not sure if I understand.
>Are you saying legacy servers won't work with 2560bis clients?
>
>> On 3/29/13 6:12 PM, "Piyush Jain" wrote:
Not sure if I understand.
Are you saying legacy servers won't work with 2560bis clients?
> On 3/29/13 6:12 PM, "Piyush Jain" wrote:
>
> >It is your statement about backward compatibility to justify it that is
> >incorrect.
> >Backward compatibility "with deployments of RFC2560" is not affected i
On 3/29/13 6:12 PM, "Piyush Jain" wrote:
>It is your statement about backward compatibility to justify it that is
>incorrect.
>Backward compatibility "with deployments of RFC2560" is not affected in
>either case. Legacy clients will continue to work whether you make it
>required or optional.
Leg
Hi David,
Your interpretation of the text is right on target.
How, based on the past discussions in this WG, that is not the intent.
The sole reason cited for overloading the meaning of revoked status with
non-issued was that it allows new servers to interoperate with legacy
clients. The WG agree
Hi Piyush,
The usual backwards compatibility concern is mixed new/legacy deployments.
In this case, the specifics appear to be:
New clients with legacy servers cannot expect to see "revoked" in this case.
This matters because a hypothetical client coded to depend on a "revoked"
response in this c
Not arguing that it should be required. I'm with you on keeping it optional.
It is your statement about backward compatibility to justify it that is
incorrect.
Backward compatibility "with deployments of RFC2560" is not affected in
either case. Legacy clients will continue to work whether you make
On 3/29/13 5:17 PM, "Piyush Jain" wrote:
>' "revoked" status is still optional in this context in order to maintain
>backwards compatibility with deployments of RFC 2560.'
>
>I fail to understand this statement about backward compatibility.
>How does "revoked" being "optional/required breaks back
' "revoked" status is still optional in this context in order to maintain
backwards compatibility with deployments of RFC 2560.'
I fail to understand this statement about backward compatibility.
How does "revoked" being "optional/required breaks backward compatibility?
The only reason cited in th
24 matches
Mail list logo
