Nonce encoding (was RE: OCSP response pre-production)

[Tom Gindin <tgindin@xxxxxxxxxx>]

        As far as I can tell, there is no explicit definition of the 
syntax of the nonce in RFC 2560.  If the syntax is actually OCTET STRING, 
we might be able to extend it as follows:
CHOICE  {
        requiredInResp          OCTET STRING,
        optionalInResp  [1]     EXPLICIT OCTET STRING
}
        which might not break existing code.  Or it could be
CHOICE  {
        original                        OCTET STRING,           -- 
undefined as to mandatory vs. optional in response.
        requiredInResp [0]      EXPLICIT OCTET STRING,
        optionalInResp  [1]     EXPLICIT OCTET STRING
}


                Tom Gindin





"Michael Myers" <mmyers@xxxxxxxxx>
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
09/26/2003 06:25 PM

 
        To:     "Deacon, Alex" <alex@xxxxxxxxxxxx>, <ietf-pkix@xxxxxxx>
        cc: 
        Subject:        RE: OCSP response pre-production




Alex,

I will, once I get them all integrated.  Given the volume of
today's discussions, that will likely be sometime early next
week.

Mike



> -----Original Message-----
> From: Deacon, Alex [mailto:alex@xxxxxxxxxxxx]
> Sent: Friday, September 26, 2003 3:13 PM
> To: 'Michael Myers'; Deacon, Alex; ietf-pkix@xxxxxxx
> Subject: RE: OCSP response pre-production
>
>
>
> Mike,
>
> As there has been some suggested changes to the text,
> can you post the most
> recent wording to get everyone back on the same page?
>
> Thanks
> Alex
>
>
> > -----Original Message-----
> > From: Michael Myers [mailto:mmyers@xxxxxxxxx]
> > Sent: Friday, September 26, 2003 2:35 PM
> > To: Deacon, Alex; ietf-pkix@xxxxxxx
> > Subject: RE: OCSP response pre-production
> >
> >
> > Alex,
> >
> > I'm willing to discuss client-side "nonce
> capability discovery"
> > via this mechanism but it's clearly a v2 proposition.
> > Meanwhile, we're working to clarify what we meant
> in v1 when we
> > defined nonces in the first place.  The poll
> clearly establishes
> > a nearly unanimous consensus that the common
> understanding in
> > place at the time found its way into running code
> in all but, to
> > date, one case.  I propose we proceed on this basis.
> >
> > Mike
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Deacon, Alex [mailto:alex@xxxxxxxxxxxx]
> > > Sent: Friday, September 26, 2003 2:09 PM
> > > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > > Myers; David Engberg;
> > > oelmaier@xxxxxxxxxxx; Ambarish Malpani; ietf-pkix@xxxxxxx
> > > Cc: Russ Housley; Stephen Kent; Tim Polk
> > > Subject: RE: OCSP response pre-production
> > >
> > >
> > >
> > > This summary assumes that the OCSP responder has
> > > control of the OCSP clients.  This may not be the
> > > case, especially when responding to OCSP requests
> > > for certs issued from SSL CA's (i.e. every flavor
> > > of browser/ocsp client on earth).  As I stated in
> > > my response to Russ, the responder could reject a
> > > request with a nonce, but why not reply with a
> > > request without a nonce, and let the client decided
> > > if it wants to accept or reject it.  If a client
> > > requires that the nonce in the result, the result
> > > is the same, the response is rejected.
> > >
> > > Alex
> >
> >
>
>