[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt



Denis Pinkas <Denis.Pinkas@xxxxxxxx> writes:

>- in addition to the current way to define a certificate, two new ways have
>   been defined.
>
>This is fully aligned with the discussion on the list.

Not at all, the CertIdWithSignature is a weird mutation of what was discussed,
because it piles a jumble of bits and pieces into a sequence rather than using
the straightforward IDs like issuerAndSerialNumber.  The rationale for the
different identifiers (e.g. issuerAndSerialNumber, certificate
fingerprint/thumbprint/whatever-you-want-to-call it) is fairly clear, but the
stuff in CertIdWithSignature is just plain strange, and entirely redundant.  I
can probably fix this by using only issuerAndSerialNumber and stuffing dummy
data in the other fields on the assumption that no-one else will be able to
make heads or tails of them either (experience with other PKI procotols has
shown that this works almost all of the time), but why is this stuff needed at
all?  What's wrong with using what was in the original OCSPv2 draft, a simple
cut-and-paste of obvious, sensible cert identifiers?

Peter.