Would like to understand lamps experts insight:
1. If a pledge creates some Certificate Signing Request (CSR - whatever
protocol/mechanism),
and later receives a certificate, and trusts it/the sender (through
whatever means,
like RFC7030 TLS connection):
How reasonable or inappropriate is it for that certificate to not contain
all the
same elements as in the CSR, but for example some additional ones ?
Rephrase:
what are the top reason that a pledge could have problem with such change
(and
any practical example, ideally with rfc7030 would be great).
2. With the common protocols used between registars and CA, (RFC7030, not
really sure
whats most common), how likely would it be acceptable by the CA that the
CSR
received from the registrar was not signed by the pledge, but only by the
registrar ?
Aka: If we had a scheme that would only supply a registrar signed, but not
pledge
signed CSR to the CA, how many deployment would not be able to use this
because
their CA would not permit this ?
Ifyou're interested: Background/explantion:
In BRSKI/ANIMA, the logic is that the registrar is knowledgable of all the
add-on
attribute that domain LDevID need. So it is providing them to a pledge via the
csrattr mechanism of EST, and the pledge can include these attributes into
its CSR, sign it, and a perfect pledge signed CSR will finally get to the CA.
BUT: now we have the use-case of draft-ietf-anima-brski-prm, where the pledge
is more or less offline, and some agent, such as an installer with a notebook
had to travel to the pledge to enroll it.
We did manage to optimize the necessary workflow for these use cases to "two
trips to the pledge".
In the first pledge, the agent discovers pledge and collects requests from
pledge,
such as request for a voucher, and CSR. After the first trip, the agent travels
back to civilization where it talks with the registrar to receive voucher and
certificate.
Alas: with just two trips to a pledge i can not see how we could maintain the
above explained BRSKI logic of having at the CA pledge signed CSR that also
includes
attributess from the domain that only the registrar knows:
On the first trip, it would be a difficult proposition for the agent to
know all the attributes, because they can be pledge-unique - such as
pledge unique additional name/addresses that can reasonably only be assigned
to a pledge once its ownership and presence/ability-to-enroll have been asserted
(but not upfront). So, the agent can not provide such attributes on a first
trip to the pledge, and hence we can not get a pledge signed CSR from the
pledge on a first trip. And of course, it does not help to send the CSR n
the second trip to the pledge - without introducing the need for a third trip.
So, without changing the number of trips, it seems as if for this type of
use-case, we can really only:
- receive CSR from pledge via agent (after first trip) on registrar.
- make registrar modify CSR content, adding the necessary attributes
- registrar sends modified CSR to CA, and can at best sign it itself
(or authenticate it itself). Of course, it could still include for
reference the original pledge signed CSR, but i wouldn't know a CA
protocol that would use such duplicate information.
- Then registrar returns certificate via agent to pledge.
- And pledge MUST suck up the certificate with all its additional attributes
and not wine about it.
Is this reasonable and/or already done in other certificate enrollment
workflows,
so nothing to worry about ??
and of course, this was primarily about draft-ietf-anima-brski-prm, but if
this workflow is acceptable, then it could even eliminate or reduce the need for
use of CSRattr in other BRSKI use-cases as well.
And of course, there may be CSRattr that an agent could reasonably know
upfront, especially when they're not unique to the pledge, such as the
public key parameters given as (currently unfinished) examples in
draft-ietf-lamps-rfc7030-csrattrs-01.
Thanks!
Toerless
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
