Tomas Gustavsson wrote:
> The most popular options that I encounter in the wild right now, and
> for the last 10 years or so, for augmenting RA->CA:
> * CMP CRMF requests using raVerified POP (used quite a lot)
understood.
> The drive today is clearly towards using some sort
021 3:09 PM
To: Michael Richardson ; Eliot Lear ; Dan
Harkins ; Owen Friel ; Peter van der
Stok ; max pritikin ; Toerless Eckert
; Esko Dijk ; sp...@ietf.org
; Thomas Werner ; anima@ietf.org
Subject: Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr
CAUTION: External Sender - Be cauti
On 03.09.21 19:35, Dan Harkins wrote:
> On 9/3/21 10:00 AM, Michael Richardson wrote:
>> I'm unclear if CMP allows for a standardized way to override the CSR
>> contents, or if it simply provides more authority for the RA to create a new
>> CSR of its own.
> Well not really override, more like
On 03.09.21 19:00, Michael Richardson wrote:
> I'm unclear if CMP allows for a standardized way to override the CSR
> contents, or if it simply provides more authority for the RA to create a new
> CSR of its own.
CMP does not offer a direct/explicit "override" mechanism for CSRs, but
it is
{Trimming massive CC to just lists}
Dan Harkins wrote:
>> While I would also prefer to enhance the RA/CA protocol, I'm not
>> entirely keen on mechanisms that break the original PoP.
> Agreed, but keep in mind that the CA has no idea whether the
> challengePassword field is
Hello,
On 9/3/21 10:00 AM, Michael Richardson wrote:
I'm unclear if CMP allows for a standardized way to override the CSR
contents, or if it simply provides more authority for the RA to create a new
CSR of its own.
Well not really override, more like augment. As I understand it, the
I'm unclear if CMP allows for a standardized way to override the CSR
contents, or if it simply provides more authority for the RA to create a new
CSR of its own.
While I would also prefer to enhance the RA/CA protocol, I'm not entirely
keen on mechanisms that break the original PoP.
Anyway, we
Hi David,
Good way to have described the situation, and the one comment you added
about e2e validation of EE<->CA to me is something that seems worthy of
discussion.
Eliot
On 01.09.21 15:47, David von Oheimb wrote:
Elliot,
good point that modifying things on the RA-CA channel affects
Elliot,
good point that modifying things on the RA-CA channel affects fewer
implementations/devices than updates on the EE-RA channel.
A further way to avoid opening a second channel between the RA and CA is
not to augment the EE-RA channel
is to improve the existing RA-CA channel in a way that
In my view, the idea recently brought up here (namely, to open a further
channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely
would not
I started a github/kramdown for this work and invited Toerless and Dan.
I think that having a 6-10 examples would be helpful for the document.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description:
David,
I mention that point because we already done this in one case with a CA,
and my concern is that our code will bloat as we have to customize to
other CAs. It's a matter of whether you think you can influence the end
devices or the CAs, and there are a lot more of the former than the
I would suggest that it helps in these cases to back up to the scenarios
we care to address, and the likelihood of success. In some cases, it
will be possible to coordinate development with the endpoints and
sometimes with the CAs. The CAs may not be strongly motivated to
standardize an
On 8/30/21 12:21 AM, Michael Richardson wrote:
Dan Harkins wrote:
> Why can't the RA signal to the CA whatever things it things should
> be included in the CA, in addition to the goo provided in the client's
I don't know. Why can't it? What protocol can it use that is well
Dan Harkins wrote:
> Why can't the RA signal to the CA whatever things it things should
> be included in the CA, in addition to the goo provided in the client's
I don't know. Why can't it? What protocol can it use that is well deployed?
> Why don't you want to define _that_
Hi Michael,
Why can't the RA signal to the CA whatever things it things should
be included in the CA, in addition to the goo provided in the client's
CSR? If the Registrar knows the name then why can't it provide it to
the CA. It will be providing the CSR to the CA, on behalf of the client,
16 matches
Mail list logo
