Hi Fraser,
That sounds good! I just added the following page to document my "quick
test" procedure which I use during development:
https://www.dogtagpki.org/wiki/PKI_10.9_Certificate_Transparency
btw, the verifySCT is currently enabled, but the failure is ignored.
However, you could look in the debug log for "verifySCT" to see relevant
debug messages.
I'll ask Dinesh to add his more comprehensive testing procedure to the page.
thanks!!
Christina
On Thu, Jun 11, 2020 at 5:58 PM Fraser Tweedale wrote:
> Hi Christina,
>
> I will find a day next week to have a close look. Probably Tuesday
> or Wednesday. It will help to have test environment setup
> documentation, i.e. how to set up a log server to test with, how to
> configure Dogtag, etc. If this stuff is already written then you
> just need to tell me where to look :)
>
> Cheers,
> Fraser
>
> On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote:
> > HI Fraser,
> > verifySCT still fails. I still think the fact the rfc does not require
> the
> > signed object to accompany the signature presents undue challenge to the
> > party that needs to verify the signature. Although I understand that
> this
> > is v1, and the issue would not be present in v2 since there will not be
> > poison extension ;-/.
> > I'd appreciate it if you could find time to take a closer look.
> >
> > Here is my latest attempt:
> > https://github.com/dogtagpki/pki/pull/440
> > Since it's a patch against the latest code, for a full view, it would be
> > easier if you just apply the patch and read from "(Certificate
> > Transparency)" in
> > base/ca/src/com/netscape/ca/CAService.java
> > This patch would require JSS change at:
> > https://github.com/dogtagpki/jss/pull/575
> >
> > Code still requires some refinement but I wish to address the
> verification
> > issue before cleaning things up. Of course I still let verifySCT returns
> > success for now just so people could still play with CT.
> > Much appreciated!
> > Christina
> >
> > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu wrote:
> >
> > > Hi Fraser,
> > > Thanks for the response!
> > > Regarding the poison extension, yes I was aware that it needed to be
> > > removed so the code already had it removed. It was the order of things
> > > left inside tbsCert that I was concerned about since I used the
> existing
> > > delete method provided for the Extension class, which I wasn't sure if
> it'd
> > > preserve the order of the remaining extensions. Thanks for confirming
> my
> > > suspicion. I will double-check the order.
> > >
> > > Also thanks for the input on how to handle failed CT log communication
> > > v.s. response verification failure. I will address them separately as
> > > suggested.
> > > Finally, nice catch with the missing data length!! I'll add that and
> go
> > > from there.
> > >
> > > thanks again!
> > > Christina
> > >
> > > On Mon, Jun 1, 2020 at 7:31 PM Fraser Tweedale
> > > wrote:
> > >
> > >> Hi Christina,
> > >>
> > >> Adding pki-devel@ for wider audience. Comments below.
> > >>
> > >> On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
> > >> > Hi Fraser,
> > >> > Do you know how the signature returned in the SCT response could be
> > >> > verified by the CA?
> > >> > My thought is that the CA should somehow verify the CT response
> after
> > >> > sending the add-pre-chain request and before signing the cert.
> Since
> > >> log
> > >> > inclusion verification would not be feasible right after the request
> > >> (the
> > >> > SCT response is supposed to be just a "promise, according to the
> rfc),
> > >> I
> > >> > ruled that out and intend to stay with just the following two
> > >> verifications
> > >> > on the response itself:
> > >> >
> > >> >- checking if log id (CT log signer public key hash) returned in
> the
> > >> CT
> > >> >response is correct
> > >> >- this I have no problem verifying
> > >> > - Verifying if the signature returned in the CT response is
> > >> correct
> > >> > - this I can't seem to get it working.
> > >> >
> > >> > I put the verification work above in the method "verifySCT".
> > >> >
> > >>
> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L1209
> > >> > What I am wondering is how this can be done properly. Since the
> > >> tbsCert is
> > >> > not to contain the poison extension, the poison extension needs to
> be
> > >> > removed by the CT server before it signs. What if the order of the
> > >> > extensions contained in the tbsCert gets changed in the process?
> > >> >
> > >> The poison extension must be removed, and care must be taken to keep
> > >> everything else in the same order, and reserialise the parts in
> > >> exactly the same way.
> > >>
> > >> > It seems that the response should contain the tbsCert that it signs
> > >> (which
> > >> > isn't per the rfc) or I am not sure how the CA could verify the
> > >> signature.
> > >> >
> > >> The response does not contain the
