Re: [Pki-devel] DogTag SCEP refresh
by Matthew Harmsen
On 12/5/19 6:42 AM, Martin Slouka wrote:
>
> Hello Matthew,
>
> I am a consultant and I help one of my customers run a Dogtag CA. They
> are missing some SCEP functionality and agreed with a developper to
> add a missing functionality. Is it possible to cooperate somehow so
> that the improvements will be merged into future releases of Dogtag?
>
> Thanks in advance.
>
> Regards,
>
> Martin Slouka
>
Martin,
Yes, I believe that this should be possible.
Please send this information to the Dogtag PKI Development Mailing List
- pki-devel(a)redhat.com (cc'ed on this email reply), so that it may be
reviewed, and hopefully incorporated into the Dogtag source base.
Thank you!
-- Matt
6 years, 8 months
[acme] getOrderByAuthorization() / orders and authorisations
by Fraser Tweedale
Just want to flag something related to ACME orders and
authorisations.
In ACME authorizations can be shared by multiple orders. In fact
you can also "preauthorize" your account for an identifier, so there
can also be a authorizations with no orders attached.
Does the way we have implemented the ACME service ensure that an
authorization has only one order (or at most one order)? If so, do
we want it that way? It entails that every identifier must be
re-authorised upon every order.
Personally I think this is not the way we want to go. Let me
describe a scenario.
Client orders a cert for a.example.com, completes the authorisation
for a.example.com, and gets the cert.
Shortly afterwards, they realise they also need b.example.com on the
certificate. So they make a new order with BOTH identifiers.
Should the client have to complete another authorisation for
a.example.com, while their existing authorisation remains "fresh"
(unexpired)? It is valid to require the client to re-authorise
every identifier for every order. But it is not optimal. Ideally
we should observe that for the account there is already a
non-expired authorisation for "a.example.com", and attach that to
the order (along with the new authorisation for "b.example.com"
which the client must complete).
Anyhow just some ideas as I proceed with implementation of the LDAP
database implement. Let me know your thoughts.
Cheers,
Fraser
6 years, 8 months